Linux-Development-Sys Digest #75, Volume #7 Fri, 20 Aug 99 05:14:17 EDT
Contents:
Re: Question about segments (Tristan Wibberley)
Re: Question about segments (Tristan Wibberley)
Re: More kind words from M$. (Tristan Wibberley)
Re: Why so inefficient source RPM's ?? (David Fox)
Re: where's the source to init (John McKown)
Re: where's the source to init (David Fox)
Having a problem loggin in, need help ("Advanced one corporation")
Re: Why so inefficient source RPM's ?? (Bill Anderson)
Re: Why so inefficient source RPM's ?? (Bill Anderson)
Re: Code for security: chroot and child processes ([EMAIL PROTECTED])
Re: why not C++? (David Schwartz)
Re: why not C++? (David Schwartz)
most efficient way to zero out a partition? (Ronald Cole)
Re: Question about segments (Emile van bergen)
Re: Can I compile the kernel using a cc other than gcc? (Kaz Kylheku)
Re: Troll (was: why not C++?) (Stephan Houben)
----------------------------------------------------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Question about segments
Date: Thu, 19 Aug 1999 02:21:55 +0100
Reply-To: [EMAIL PROTECTED]
Bartosz Klimek wrote:
>
> My conclusion is that ds = ss. Is it right?
Yes:
+---------------------+
CS | |
+---------------------+
DS, ES, FS, GS, SS | |
+---------------------+
They all overlap. Unix doesn't need, use or want segments, it uses
paging. Intel forces segmentation, you *must* have a code segment to run
code, you *must* have a stack segment to use the stack, you *must* have
a data segment to use operations that use ds. To have just 32 bit
pointers, the segments must either use the same descriptors, or start at
the same place.
> All these questions came to my mind when I was reading a book on i486
> processor. At first I thought: what a beautiful world. We have cs, ds,
> ss, es, so we can make distinct segments for different kind of data,
> each of them managed in a different way, each of them with different
> protections. When I was already happy, I asked myself: OK, but in C we
> have completely flat pointers! So how can we reach different segments?
> OK, so there's only one segment. But then, instructions do use different
> segment registers. pushl uses ss, movl usually uses ds. And at this
> point I got stuck.
This feature can be useful in embedded applications, but otherwise it
tends to be a hinderance - especially since paging can be more flexible.
There are still uses for it I'm sure.
> > Stack is slightly special, since it has to automatically grown downwards.
> > AFAIR the kernel traps illegal access (i.e. access to a virtual address
> > which is not mapped) and if that would fall within the stack's size, it
> > expands the stack accordingly.
>
> All right, but if the space is so pefectly flat, how does the kernel
> know if we want to access stack or non-stack?
There is 2MB reserved at a particular point in the address space (AFAICR
there is a compile-time option to increase this?).
> What a mess in my mind... I'd rather go to bed... But it's going to be a
> sleepless night. Maybe I should be a philosopher not a philolinuxer.
Think of UNIX as having a flat address space, as if there were no
segmentation.
For interest - does anyone know of anything segmentation can do that
paging can't do better (or neater)?
--
Tristan Wibberley
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Question about segments
Date: Thu, 19 Aug 1999 02:28:24 +0100
Reply-To: [EMAIL PROTECTED]
Emile van bergen wrote:
>
> On Thu, 19 Aug 1999, Bartosz Klimek wrote:
>
> >Hello.
> >
> >There's something I don't understand about process segments. I suppose
> >every process in Linux has a code segment, data segment, const data
> >segment, stack segment. And now, if I have a pointer, e.g. char *p, it
> >is a 32b offset. Look at this:
>
> [SNIP]
>
> >Question: how does the compiler (or whatever) know how to interpret the
> >32b offsets in lines (1), (2), (3)? In each line p points to data in a
> >different segment. Maybe the offsets are something more than just
> >offsets in flat segments?
> >
> >AFAIR, you need an offset and a segment register to reach data in
> >memory. But if you have the offset only, how do you know which segment
> >register to use? Maybe the segments overlap? No, it can't be...
>
> Yes, this is exactly the case. Linux x86 (and most unices on intel) have
> a flat address space, in which all segment descriptors (note: not the
> old real mode segments, protected mode descriptors!) point to the same
> address space. The 32-bit offset allows addressing of all of the 4Gb of
> address space on the 386+ and protection in implemented at the page
> level, not the segment level, so why bother with those clumsy and ugly
> segments?
>
> The Pentium II, however, reintroduces this ugly concept, because offsets
> are still 32-bit, but the CPU allows for a max. of 36 bits of address
> space using the base pointer of the segment descriptor. There's much
> discussion going on if Linux should be changed to support the bigger
> address space, as the whole messy segment model would need to be
> incorporated.
It not really all that messy to do. You just limit it's use to mmapping
(either files or anonymous). You just need to add 3 r/w data segment
descriptors to the descriptor table and make a page directory for them.
It can be used for more things (complex protection inside an app), but
not many people need that - it's real usefulness is for making large
amounts of data available at one time.
--
Tristan Wibberley
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: More kind words from M$.
Date: Thu, 19 Aug 1999 02:46:13 +0100
Reply-To: [EMAIL PROTECTED]
Kaz Kylheku wrote:
>
> On Thu, 19 Aug 1999 22:13:46 -0400, Charles Sullivan <[EMAIL PROTECTED]>
> wrote:
> >
> >Mindspring News wrote in message <7pdve2$6in$[EMAIL PROTECTED]>...
> >>
> >>He's just an AOL employee posing as a microsoft developer to further AOL's
> >>insidious purposes. He used the words "unpleasantly" and "experienced". A
> >>real microsoft programmer can't use words more than 8 letters in length ;)
> >
> >Hah! I like that.
>
> He can cheat by dropping a few vowels and using a three letter extension.
> If he or she has space left over, they might even throw in the digits
> '32'. Thus
>
> unpleasantly
>
> can be quite succinctly expressed as
>
> unplsn32.tly
Alternatively, he can say
unplea~1 . unpleasa. ntly .
and expect you to ignore the first word and concatenate the next two,
dropping the empty extensions (spaces) and dots.
He could also insist that you upgrade to Microsoft Language Centre 4.0
and convert all your paper to NTPaper. You'll then have to run Microsoft
Proof Read to find the errors that the conversion caused (you won't be
able to fix the errors, but can't avoid the test anyway).
--
Tristan Wibberley
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: linux.redhat.misc,linux.redhat.rpm
Subject: Re: Why so inefficient source RPM's ??
Date: 19 Aug 1999 21:50:51 -0700
Peter Mutsaers <[EMAIL PROTECTED]> writes:
> With source RPM's, it seems you have to re-download the whole thing
> (sometimes huge RPM's such as gcc) for every minor tweak.
>
> Am I missing something? Is there a place where Redhat (or contrib)
> source RPM's are located in unpacked form so that I can update without
> downloading the whole original source over and over again?
This is only a problem if you are dealing with a package that is (a)
huge and (b) updated frequently and (c) you need to follow every
little update and (d) you only have a low bandwidth connection to the
net. Furthermore, we are only talking about changes to the RPM
specfile, not to the underlying package. This is such an unusual
situation that it is my opinion that the advantages of the usual
source+specfile RPM packaging method far outweigh the disadvantages.
In the rare case where it is a problem there is a completely standard
RPM feature you can use to build a no source RPM.
I personally find the debian method distasteful, both because of the
many files that are always floating around and because you can only
have a single diff file, whereas in an RPM can have multiple diff
files representing changes to various parts of the system, perhaps
supplied by different people.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: [EMAIL PROTECTED] (John McKown)
Subject: Re: where's the source to init
Date: 20 Aug 1999 05:36:47 GMT
On Thu, 19 Aug 1999 18:54:50 -0700, Eric Hegstrom
<[EMAIL PROTECTED]> wrote:
>OK I feel like an idiot.
>
>I know the source to /sbin/init is somewhere on the second redhat disk
>but which package is it in. Is there an easy way to answer these
>questions myself.
>
>Cheers,
>Linux
>
On a RedHat system, the easiest way to find out which package contains a
particular file is to use the rpm command. In your case:
rpm -qf /sbin/init
Which gets the response (on my system):
SysVinit-2.74-11
So look for SysVinit-2.74-11.src.rpm on the second disk. Your file name
may vary if you are not running RedHat 6.0 . This will work for any
file that is installed via rpm. It does no good for anything installed
from a tarball. But then, if you installed it by hand, I guess you'd
know where you installed it from. Unless, like me, you tend to be
forgetful.
John
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Subject: Re: where's the source to init
Date: 19 Aug 1999 21:52:14 -0700
Eric Hegstrom <[EMAIL PROTECTED]> writes:
> I know the source to /sbin/init is somewhere on the second redhat disk
> but which package is it in. Is there an easy way to answer these
> questions myself.
rpm -q -f /sbin/init
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: "Advanced one corporation" <[EMAIL PROTECTED]>
Subject: Having a problem loggin in, need help
Date: Thu, 19 Aug 1999 23:17:29 +0100
I'm having a problem loggin in. After I have logged in to my localhost by
typing in root and then my password, this message appears:
[root@localhost /root#
What does this message mean and what do I type.
Help is appreciated.
Thanks
[EMAIL PROTECTED]
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.misc,linux.redhat.rpm
Subject: Re: Why so inefficient source RPM's ??
Date: Thu, 19 Aug 1999 10:01:32 -0600
Johan Kullstam wrote:
>
> Bill Anderson <[EMAIL PROTECTED]> writes:
>
> > Johan Kullstam wrote:
> > >
> > > [EMAIL PROTECTED] (Suchandra Thapa) writes:
> > >
> > > > Peter Mutsaers <[EMAIL PROTECTED]> wrote:
...
> > > >
> > > > If you do a rpm -Uvh or rpm -ivh to the source rpm then you
> > > > should get the tar.gz'ed source in the /usr/src/redhat/SOURCE directory
> > > > and the spec in /usr/src/redhat/SPEC directory.
> > >
> > > this presupposes that you already have the old source rpm. if you do
> > > not, you have to 1) download the new source 2) download the old
> > > src-rpm. note that step 2) contains the old sources which are 1)
> > > superceded by the new source and hence superflous and 2) often large.
> >
> > If the builder distributes patches, you only need to download the
> > original src.rpm, and apply patches.
> > Either way, if you do not have the source, you either download a binary,
> > or you download the source.
> > As seen below, this is precisely what the previous poster indicated.
>
> what if the builder doesn't offer a patch. you want to roll up a new
> rpm from the newer sources and wish to borrow from past rpm spec
> files. you have to download the source twice. it's annoying.
And if the maintainer does not distibute patches, and distributes in
tarball, you have to download the news source there to. Same with *any*
system if you don't have patches available, with the exception of CVS.
>
> > > > Just download the patch
> > > > and place it in the SOURCE directory and add the proper lines to the spec
> > > > files (Patch[n]: patch.tar.gz where n is some integer at the top of the
> > > > spec file and a corresponding %patch[n] -your_options_to_patch before the
> > > > %build). Then after a rpm -bb your.spec or rpm -ba your.spec the binary
> > > > rpm should appear in /usr/src/redhat/RPM hierarchy and the source rpm in
> > > > /usr/src/redhat/SRPMS.
> > >
> > > sometimes hacking the spec file is a lot of trouble. i spent a few
> > > hours hacking the egcs-1.1.2 rpm-spec file to make it do gcc-2.95.
> > >
> > > really, it'd be very nice to have no-source rpms with just the spec
> > > file and patches.
> >
> > Complain to the maintainer of the app.
> > RPM is fully capable of these.
>
> it's not.
Yes, it is.
>
> when you build from a spec, rpm makes binarary rpms and source rpms.
> it does not make a package containing spec file and patches *without*
> the main source tarball.
Then perhaps you should tell that to my no-source rpms?
An rpm will distibute whatever you tell it to.
If you want, you can have an *empty* rpm, or an rpm of config files, or
....
>
> > It is up to whomever maintains the rpms (not always the same as whomever
> > maintains the app) to distribute these.
>
> i want a no-source rpm. i want the source-less rpms to be found on
> ftp sites. the application maintainer cannot change this situation
> one way or another. (unless you are talking about the maintainer of
> the rpm application only.)
Whomever is making the rpm for that particular application is who to
talk to about no-source rpms.
RPM *is* fully capable of doing this.
> i really like sources who are kind enough to include an
> rpm spec file within the tarball. this, an application maintainer,
> can do.
Yes, they can. And they can use rpm to do it. It is not always the case
that the person who makes the rpm is the maintainer of the software. In
either event, rpm is fully capable of what you are wanting, and there
are those that *do* do this, myself included. Again, if a particular app
does not, complain to the maintaner of the rpm.
--
Bill Anderson Linux/Unix Administrator, Security
Analyst
ESBU (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.misc,linux.redhat.rpm
Subject: Re: Why so inefficient source RPM's ??
Date: Thu, 19 Aug 1999 10:03:14 -0600
Peter Mutsaers wrote:
>
> >> "ST" == Suchandra Thapa <[EMAIL PROTECTED]> writes:
>
> ST> If you do a rpm -Uvh or rpm -ivh to the source rpm then you
> ST> should get the tar.gz'ed source in the /usr/src/redhat/SOURCE
> ST> directory and the spec in /usr/src/redhat/SPEC directory.
> ST> Just download the patch and place it in the SOURCE directory
> ST> and add the proper lines to the spec files (Patch[n]:
> ST> patch.tar.gz where n is some integer at the top of the spec
> ST> file and a corresponding %patch[n] -your_options_to_patch
> ST> before the
> ST> %build). Then after a rpm -bb your.spec or rpm -ba your.spec
> ST> %the binary
> ST> rpm should appear in /usr/src/redhat/RPM hierarchy and the
> ST> source rpm in /usr/src/redhat/SRPMS.
>
> I know, but to do that you have first to download the whole updated
> RPM. My problem is that the source RPM's aren't distributed as
> separate orig-tarball, spec file, and patches. Thus, for every minor
> update to the patches and/or specfile, you have to download the whole
> SRPM again, which is terribly inefficient and wasteful.
And is not a failing of rpm. As said elsewhere, rpm is fully capable of
doing this.
Do not confuse lack of performance on a maintainer's part with inability
of rpm.
complain to the maintainer of the source or rpm builder, as appropriate.
--
Bill Anderson Linux/Unix Administrator, Security
Analyst
ESBU (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Code for security: chroot and child processes
Crossposted-To: comp.os.linux.security,comp.os.linux.development.apps
Date: 18 Aug 1999 20:25:09 GMT
In comp.os.linux.development.system Chris Butler <[EMAIL PROTECTED]> wrote:
: [comp.os.linux.development.apps - 17 Aug 1999 18:35:26 GMT] * brian wrote *
:> On 12 Aug 1999 02:01:12 GMT,
:> Mike Khalili <[EMAIL PROTECTED]> wrote:
:>> No, it is not. Once you chroot() you're stuck with it.
:> Not entirely true. There are ways to get out of a chroot jail.
: Only if you're still running as root. Since apps that chroot normally set
: their UID to something other than root, this is unlikely.
Huh? About the only thing a chroot `jail'
does for security is it prevents you from
exploiting setuid programs which aren't
inside the jail itself. You can still use the
full range of exploits against daemon processes,
make and receive connections over the network
and exploit local/remote machines that way,
and exploit setuid processes which happen to
be inside the jail. You can still download and
run arbitrary code inside the jail.
As root it's trivially simple (just create
device nodes, for example). As non-root, you
still have about 90% of the local exploits
available to you.
Rich.
--
[EMAIL PROTECTED] | Free email for life at: http://www.postmaster.co.uk/
BiblioTech Ltd, Unit 2 Piper Centre, 50 Carnwath Road, London, SW6 3EG.
+44 171 384 6917 | Click here to play XRacer: http://xracer.annexia.org/
--- Original message content Copyright � 1999 Richard Jones ---
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Fri, 20 Aug 1999 00:45:04 -0700
Cocheese wrote:
> Again I admit it would take a little extra work and put a minor set
>
> back in the evolution for a month or 2, but if C++ is so much faster,
>
> easier, and stable- WHY NOT?
C++ may have some advantages over C, but "faster", "easier" and
"stabler" are NOT them!
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Fri, 20 Aug 1999 00:56:16 -0700
Phil Howard wrote:
>
> On Mon, 16 Aug 1999 19:56:20 -0700 Randall Parker ([EMAIL PROTECTED]) wrote:
> | I think the real problem with C++ and heap memory is that too many
> | programmers who use C++ do not understand how much all the stuff they are
> | writing is fragmenting the heap.
>
> Of course. They tend to be abstraction oriented applications programmers.
> Details? We don't need no steenkin details! :-)
This is the penalty you take everytime your language takes you further
from the hardware.
I remember way back in my microcontroller days, dealing with a chip
that had no hardware capability to do signed arithmetic. So when people
had:
int i;
for(i=0; i<10; i++) { something(i); }
I changed it to:
unsigned int i;
for(i=0; i<10; i++) { something(i); }
And things got much faster. Then I remembered that the chip had a
'decrement and jump if not zero' instruction. So we next went to:
unsigned int i;
for(i=10; i!=0; i--) { something(i); }
And things got much faster again.
You always have to look at what your code is making the machine
actually _do_.
DS
------------------------------
From: Ronald Cole <[EMAIL PROTECTED]>
Subject: most efficient way to zero out a partition?
Date: 18 Aug 1999 12:44:14 -0700
I feel the need to zero out my /dev/sda10. It's a bit over 1-gig
and so:
dd if=/dev/zero of=/dev/sda10
takes a *long* time. How would I figure out the optimal block size
to get the job done in the shortest amount of time without resorting
to trial-and-error?
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My PGP fingerprint: 15 6E C7 91 5F AF 17 C4 24 93 CB 6B EB 38 B5 E5
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: Question about segments
Date: Fri, 20 Aug 1999 08:37:49 +0000
On Fri, 20 Aug 1999, Bartosz Klimek wrote:
[SNIP]
>So all such things like read-only protection (const data) and automatic
>resizing of the stack is done at the page level?
Yes.
>p contains offset relative to the start of the segment pointed to by the
>descriptor pointed to by ss. Is it so?
Yes. But the start of this segment is zero. Just as the start of the
data segment.
[SNIP]
>The offset in p goes to eax. The second of the above instructions uses
>ds segment register. My conclusion is that ds = ss. Is it right?
It might be, but in reality, it doesn't matter if the _selectors_
(pointing to the descriptors) are the same, as long as the base address
is the same! And that's the case.
For example, the kernel CS selector is 0x10, the DS selector 0x18, so
they have different descriptors from the GDT. It needs to be, because a
code segment descriptor needs other flags than a data segment
descriptor. But the base address for both is 0xc0000000, so it really
doesn't matter anymore which one is used. The offset refers to the same
address in virtual memory.
Answering your question, on Linux 2.0.31 (just checked
arch/i386/kernel/head.S), indeed ds == ss.
>All these questions came to my mind when I was reading a book on i486
>processor. At first I thought: what a beautiful world. We have cs, ds,
>ss, es, so we can make distinct segments for different kind of data,
>each of them managed in a different way, each of them with different
>protections. When I was already happy, I asked myself: OK, but in C we
>have completely flat pointers! So how can we reach different segments?
>OK, so there's only one segment. But then, instructions do use different
>segment registers. pushl uses ss, movl usually uses ds. And at this
>point I got stuck.
This is correct, and still the case. But the auto-expand feature of the
stack isn't done by setting a limit + a 'grows down' bit in the ss
descriptor, but using paging (the PTE for the page below the stack has
the 'not there' bit set, so if the program accesses it, it is trapped).
Everything is done using paging. Remember, Linux is portable, and most
CPU's don't have this segment scheme. Also, a flat space tends to be
more efficient, as there's no need for loading / remembering segment
descriptors or addressing prefixes.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.portable
Subject: Re: Can I compile the kernel using a cc other than gcc?
Date: Wed, 18 Aug 1999 21:07:48 GMT
On Wed, 18 Aug 1999 20:30:51 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>I just started working on a LinuxCE project. At first I need to choose a
>compiler, and I do not want to change any architecture-independent parts
>in the kernel source. My question is, do I have to use gcc to compile
>the kernel? Could other compilers work? Thanks in advance.
You have to use GCC because the kernel is written using the extensions of GNU
C. Taking out those extensions would be a major undertaking.
------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Date: 20 Aug 1999 08:59:59 +0200
[EMAIL PROTECTED] (Rainer Joswig) writes:
> A Lisp system is the ultimate in dynamic changeability
> and debuggability. Unless you have **live** debugged stuff
> like NFS mounts, you won't hardly understand what
> this stuff is about. It is the ultimate hacker's machine.
> All code a keypress away, tools tightly integrated,
> excellent integrated documentation facilities, not the multitude of
> stupid scripting languages, a real graphical and
> mousable command interpreter, reusable OS facilities,
> on the fly compilation, on the fly updating of change
> objects, ...
OK, you have me convinced. I want it.
Is anyone working on a new Lisp OS nowadays?
Greetings,
Stephan
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
