Hello
http://isec.pl/vulnerabilities/isec-0021-uselib.txt
[...]
Locally exploitable flaws have been found in the Linux binary format
loaders' uselib() functions that allow local users to gain root
privileges.
[...]
Version: 2.4 up to and including 2.4.29-rc2, 2.6 up to and including 2.6.10
[...]
It's was fixed by Marcelo on 2.4.29-rc1. Thank's :)
What about 2.6.X? Is any patch available? I don't see any changes
around binfmt_elf in 2.6.10-bk10?
--
*[ ?ukasz Tr?bi?ski ]*
On Fri, Jan 07, 2005 at 04:59:22PM +0100, Lukasz Trabinski wrote:
> Hello
>
>
> http://isec.pl/vulnerabilities/isec-0021-uselib.txt
>
> [...]
> Locally exploitable flaws have been found in the Linux binary format
> loaders' uselib() functions that allow local users to gain root
> privileges.
> [...]
> Version: 2.4 up to and including 2.4.29-rc2, 2.6 up to and including 2.6.10
> [...]
>
> It's was fixed by Marcelo on 2.4.29-rc1. Thank's :)
> What about 2.6.X? Is any patch available? I don't see any changes
> around binfmt_elf in 2.6.10-bk10?
2.6.10-ac contains a version of the fix.
Attached is what going to be merged in mainline, most likely.
On Fri, 7 Jan 2005, Marcelo Tosatti wrote:
> On Fri, Jan 07, 2005 at 04:59:22PM +0100, Lukasz Trabinski wrote:
>> Hello
>>
>>
>> http://isec.pl/vulnerabilities/isec-0021-uselib.txt
>>
>> [...]
>> Locally exploitable flaws have been found in the Linux binary format
>> loaders' uselib() functions that allow local users to gain root
>> privileges.
>> [...]
>> Version: 2.4 up to and including 2.4.29-rc2, 2.6 up to and including 2.6.10
>> [...]
>>
>> It's was fixed by Marcelo on 2.4.29-rc1. Thank's :)
>> What about 2.6.X? Is any patch available? I don't see any changes
>> around binfmt_elf in 2.6.10-bk10?
>
> 2.6.10-ac contains a version of the fix.
>
> Attached is what going to be merged in mainline, most likely.
>
>
FYI, the provided source-code won't build with the 2.6.x kernel
because one of the structures is no longer defined. However,
building on 2.4.20 and attempting to exploit the alleged bug
results in:
Script started on Fri 07 Jan 2005 03:22:24 PM EST
LINUX> ./isec
[+] SLAB cleanup
child 1 VMAs 0
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xef800000 - 0xffffd000
[-] FAILED: try again (No such device)
Killed
LINUX> ./isec
[+] SLAB cleanup
child 1 VMAs 0
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xef800000 - 0xffffd000
[-] FAILED: try again (No such device)
Killed
LINUX> exit
Script done on Fri 07 Jan 2005 03:22:45 PM EST
.... Nothing. It just doesn't do what it's claimed to do....
So, maybe the exploit __can__ happen under rare circumstances,
but I wouldn't worry too much about it at the present time.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Fri, Jan 07, 2005 at 03:27:05PM -0500, linux-os wrote:
> On Fri, 7 Jan 2005, Marcelo Tosatti wrote:
> >>Hello
> >>
> >>
> >>http://isec.pl/vulnerabilities/isec-0021-uselib.txt
> >>
> >>[...]
> >>Locally exploitable flaws have been found in the Linux binary format
> >>loaders' uselib() functions that allow local users to gain root
> >>privileges.
> >>[...]
> >>Version: 2.4 up to and including 2.4.29-rc2, 2.6 up to and including
> >>2.6.10
> >>[...]
> >>
> >>It's was fixed by Marcelo on 2.4.29-rc1. Thank's :)
> >>What about 2.6.X? Is any patch available? I don't see any changes
> >>around binfmt_elf in 2.6.10-bk10?
> >
> >2.6.10-ac contains a version of the fix.
> >
> >Attached is what going to be merged in mainline, most likely.
> >
> >
>
> FYI, the provided source-code won't build with the 2.6.x kernel
> because one of the structures is no longer defined. However,
> building on 2.4.20 and attempting to exploit the alleged bug
> results in:
>
> Script started on Fri 07 Jan 2005 03:22:24 PM EST
> LINUX> ./isec
>
> [+] SLAB cleanup
> [+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
> [+] vmalloc area 0xef800000 - 0xffffd000
>
> [-] FAILED: try again (No such device)
It's trying to use /dev/shm/_elf_lib, which doesn't work too well if
you don't have tmpfs/shm support and /dev/shm mounted. Changing this to
a normal filename doesn't get much further in the exploit. It just
repeatedly fails:
22:26:41 0$ ./elflbl_v108
[+] SLAB cleanup
child 1 VMAs 31876
child 2 VMAs 250
[+] moved stack bfffd000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xfec00000 - 0xffffd000
Wait... -
[-] FAILED: 502: try again (Cannot allocate memory)
Killed
Oh, and in 2.6.x it seems struct modify_ldt_ldt_s is now struct
user_desc, not that making that change and running the exploit results
in any further luck.
There are comments in the code about a 'race' though, so I assume it's
a race condition being exploited and it might work eventually if you
loop the thing.
-Ath
--
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
Please don't use that for mainline - do_brk_locked doesn;t follow kernel
convention and in addition you've made every case you miss (eg outside
code) fail insecure. The original patch you did that I used that adds
__do_brk() not only follows kernel convention but means anyone with
external code will end up with it fixed or with a deadlock that is easy
to track if unlucky.
Silent security failure is *bad*
Alan
On Fri, 7 Jan 2005, Alan Cox wrote:
>
> Please don't use that for mainline - do_brk_locked doesn't follow kernel
> convention
I agree, I also find the "do_brk_locked()" naming confusing. To me it
implies that we already _are_ locked, not that we're going to lock.
On the other hand, I think Alan's patch is equally confusing: the calling
rules for "do_brk()" and "do_mmap()" are the same, and they are "caller
takes mmap_sem".
So I think you _both_ broke kernel conventions.
So I'd personally much prefer to just first fix the bug minimally (by just
taking the lock in the two places that need it), and then _separately_ say
"we should warn if anybody ever calls 'do_brk()' without the lock". That's
how we tend to verify locking in other cases, ie we have things like
if (!spin_is_locked(&t->sighand->siglock))
BUG();
to verify the calling conventions. Same would go for mmap_sem (although we
don't seem to have any "sem_is_writelocked()" test - although you can fake
it with
if (down_read_trylock(&mm->mmap_sem))
BUG();
instead.
Now _that_ is a non-silent failure mode. The machine doesn't just silently
deadlock: it tells you exactly what's wrong.
Linus
On Fri, Jan 07, 2005 at 04:15:28PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 7 Jan 2005, Alan Cox wrote:
> >
> > Please don't use that for mainline - do_brk_locked doesn't follow kernel
> > convention
>
> I agree, I also find the "do_brk_locked()" naming confusing. To me it
> implies that we already _are_ locked, not that we're going to lock.
>
> On the other hand, I think Alan's patch is equally confusing: the calling
> rules for "do_brk()" and "do_mmap()" are the same, and they are "caller
> takes mmap_sem".
>
> So I think you _both_ broke kernel conventions.
>
> So I'd personally much prefer to just first fix the bug minimally (by just
> taking the lock in the two places that need it), and then _separately_ say
> "we should warn if anybody ever calls 'do_brk()' without the lock". That's
> how we tend to verify locking in other cases, ie we have things like
>
> if (!spin_is_locked(&t->sighand->siglock))
> BUG();
>
> to verify the calling conventions. Same would go for mmap_sem (although we
> don't seem to have any "sem_is_writelocked()" test - although you can fake
> it with
>
> if (down_read_trylock(&mm->mmap_sem))
> BUG();
>
> instead.
>
> Now _that_ is a non-silent failure mode. The machine doesn't just silently
> deadlock: it tells you exactly what's wrong.
Only problem is that current do_brk() callers dont take the lock - you would
need a version of do_brk() that doesnt warn for them?
But yes, the warning is better than silent failure or security problem for
out-of-the tree users.
On Fri, 7 Jan 2005, Marcelo Tosatti wrote:
>
> Only problem is that current do_brk() callers dont take the lock - you would
> need a version of do_brk() that doesnt warn for them?
No, I'd just fix them up.
They mostly don't _need_ the lock (at least not the binary loader ones),
since at executable loading time you're guaranteed to be the only user
anyway, but hey, we get the lock for do_mmap() there for the same reason:
to just keep things consistent (and I think we used to have a warning in
do_mmap() a long time ago when we were chasing down some other bug, so
doign the same thing for do_brk() is just very consistent).
Another issue is likely that we should make the whole "uselib()"
interfaces configurable. I don't think modern binaries use it (where
"modern" probably means "compiled within the last 8 years" ;).
Linus
Linus Torvalds <[email protected]> writes:
> Another issue is likely that we should make the whole "uselib()"
> interfaces configurable. I don't think modern binaries use it (where
> "modern" probably means "compiled within the last 8 years" ;).
I don't think it was ever being used for anything besides a.out so IMHO it
should depend on BINFMT_AOUT.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sat, Jan 08, 2005 at 10:07:10PM +0100, Andreas Schwab wrote:
> I don't think it was ever being used for anything besides a.out so IMHO it
> should depend on BINFMT_AOUT.
FWIW (I don't know how accurate it is -- it's Slashdot after all -- but
it might be worth reading):
http://linux.slashdot.org/comments.pl?sid=135324&cid=11292046
-Barry K. Nathan <[email protected]>
On Sad, 2005-01-08 at 18:46, Linus Torvalds wrote:
> They mostly don't _need_ the lock (at least not the binary loader ones),
> since at executable loading time you're guaranteed to be the only user
> anyway
Still unconvinced looking in fs/proc.
Andreas Schwab <[email protected]> writes:
> Linus Torvalds <[email protected]> writes:
>
>> Another issue is likely that we should make the whole "uselib()"
>> interfaces configurable. I don't think modern binaries use it (where
>> "modern" probably means "compiled within the last 8 years" ;).
>
> I don't think it was ever being used for anything besides a.out so IMHO it
> should depend on BINFMT_AOUT.
I will disable it from 64bit x86-64. I would recommend that all other
ELF only architectures do the same.
-Andi
On Sad, 2005-01-08 at 23:21, Andi Kleen wrote:
> > I don't think it was ever being used for anything besides a.out so IMHO it
> > should depend on BINFMT_AOUT.
>
> I will disable it from 64bit x86-64. I would recommend that all other
> ELF only architectures do the same.
Presumably x86-64 runs 32bit a.out binaries however ? Disabling it now
is a bit pointless since its finally been audited 8)
On Sat, Jan 08, 2005 at 10:07:10PM +0100, Andreas Schwab wrote:
> Linus Torvalds <[email protected]> writes:
>
> > Another issue is likely that we should make the whole "uselib()"
> > interfaces configurable. I don't think modern binaries use it (where
> > "modern" probably means "compiled within the last 8 years" ;).
>
> I don't think it was ever being used for anything besides a.out so IMHO it
> should depend on BINFMT_AOUT.
Let me contribute a man page. Comments welcome (-> [email protected]).
USELIB(2) Linux Programmer's Manual USELIB(2)
NAME
uselib - load shared library
SYNOPSIS
#include <unistd.h>
int uselib(const char *library);
DESCRIPTION
The system call uselib serves to load a shared library to
be used by the calling process. It is given a pathname.
The address where to load is found in the library itself.
The library can have any recognized binary format.
RETURN VALUE
On success, zero is returned. On error, -1 is returned,
and errno is set appropriately.
ERRORS
In addition to all of the error codes returned by open(2)
and mmap(2), the following may also be returned:
EACCES The library specified by library is not readable,
or the caller does not have search permission for
one of the directories in the path prefix. (See
also path_resolution(2).)
ENFILE The system limit on the total number of open files
has been reached.
ENOEXEC
The file specified by library is not executable, or
does not have the correct magic numbers.
CONFORMING TO
uselib() is Linux specific, and should not be used in pro-
grams intended to be portable.
NOTES
uselib() was used by early libc (up to libc 4.3) startup
code to load the shared libraries with names found in an
array of names in the binary.
Later code tries to prefix these names with "/usr/lib",
"/lib" and "" before giving up. In libc 4.4.1 these names
are looked for in the directories found in
LD_LIBRARY_PATH, and if not found there, prefixes
"/usr/lib", "/lib" and "/" are tried.
From libc 4.4.4 on only the library "/lib/ld.so" is
loaded, so that this dynamic library can load the remain-
ing libraries needed. This is also the state of affairs
in libc5.
glibc2 does not use this call.
SEE ALSO
ar(1), gcc(1), ld(1), ldd(1), mmap(2), open(2), capabil-
ity(7), ld.so(8)
Linux 2.6.10 2005-01-09 USELIB(2)
On Sat, Jan 08, 2005 at 11:30:25PM +0000, Alan Cox wrote:
> On Sad, 2005-01-08 at 23:21, Andi Kleen wrote:
> > > I don't think it was ever being used for anything besides a.out so IMHO it
> > > should depend on BINFMT_AOUT.
> >
> > I will disable it from 64bit x86-64. I would recommend that all other
> > ELF only architectures do the same.
>
> Presumably x86-64 runs 32bit a.out binaries however ? Disabling it now
> is a bit pointless since its finally been audited 8)
Yes. I disabled it only for 64bit programs of course. For 32bit it is
dependent on CONFIG_IA32_AOUT.
Actually you can still call it from 64bit if you really want if you use
int 0x80.
-Andi
On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 7 Jan 2005, Marcelo Tosatti wrote:
> >
> > Only problem is that current do_brk() callers dont take the lock - you would
> > need a version of do_brk() that doesnt warn for them?
>
> No, I'd just fix them up.
What do you mean by "fix them up" ? With your minimal fix the other do_brk() callers
do not have the lock, you dont mean "fix" by grabbing the lock?
> They mostly don't _need_ the lock (at least not the binary loader ones),
> since at executable loading time you're guaranteed to be the only user
> anyway,
OK - the old mappings have been unmapped at this point, correct? There are no
mappings at all?
I think you also need to fix some cases in arch/sparc{64},arch/mips? as Alan said.
> but hey, we get the lock for do_mmap() there for the same reason:
> to just keep things consistent (and I think we used to have a warning in
> do_mmap() a long time ago when we were chasing down some other bug, so
> doign the same thing for do_brk() is just very consistent).
I think the rule "always have mmap_sem locked when calling do_brk()" is simpler and
easier to understand, but hey, you prefer the minimal fix.
I was also not sure if it was safe to NOT have the lock except for execve() as
you mention.
> Another issue is likely that we should make the whole "uselib()"
> interfaces configurable. I don't think modern binaries use it (where
> "modern" probably means "compiled within the last 8 years" ;).
On Sat, 8 Jan 2005, Marcelo Tosatti wrote:
>
> > No, I'd just fix them up.
>
> What do you mean by "fix them up" ? With your minimal fix the other do_brk() callers
> do not have the lock, you dont mean "fix" by grabbing the lock?
I'm saying that if we decide to do the debugging warning (and I think
everybody is agreeing that we should), then we _will_ fix it by just
grabbing the lock in all the paths. That's what we already did with
do_mmap(), after all.
I suspect it's not strictly needed, but as Alan has said, even though
nothing else can chaneg the vma's at the same time, it's the right thing
to do to keep /proc reads happy (which _can_ happen) anyway. And more
importantly, invariants are nice - to the point where it's good to follow
the rules even if it might not be strictly necessary.
I just wanted to keep these two issues separate. I think it's one thing to
fix a known bug, and another thing to add some debug infrastructure to
make sure that it doesn't happen in the future. So I think the WARN_ON() +
adding of extra locking is a separate stage from fixing the known problem.
Linus
On Sun, 9 Jan 2005, Andries Brouwer wrote:
> On Sat, Jan 08, 2005 at 10:07:10PM +0100, Andreas Schwab wrote:
> > Linus Torvalds <[email protected]> writes:
> >
> > > Another issue is likely that we should make the whole "uselib()"
> > > interfaces configurable. I don't think modern binaries use it (where
> > > "modern" probably means "compiled within the last 8 years" ;).
> >
> > I don't think it was ever being used for anything besides a.out so IMHO it
> > should depend on BINFMT_AOUT.
>
> Let me contribute a man page. Comments welcome (-> [email protected]).
>
> USELIB(2) Linux Programmer's Manual USELIB(2)
>
[...]
>
> Later code tries to prefix these names with "/usr/lib",
> "/lib" and "" before giving up. In libc 4.4.1 these names
Don't you mean
"/lib" and "/" before giving up.
??
--
Jesper Juhl
On Sun, Jan 09, 2005 at 03:21:22AM +0100, Jesper Juhl wrote:
> > Later code tries to prefix these names with "/usr/lib",
> > "/lib" and "" before giving up. In libc 4.4.1 these names
>
> Don't you mean
> "/lib" and "/" before giving up.
No.
(But I should have added a reference to dlopen(3).)
Note that not only a.out but also ELF binaries are loaded by uselib.
Andries
On Sat, Jan 08, 2005 at 05:38:50PM -0800, Linus Torvalds wrote:
>
> On Sat, 8 Jan 2005, Marcelo Tosatti wrote:
> >
> > > No, I'd just fix them up.
> >
> > What do you mean by "fix them up" ? With your minimal fix the other do_brk() callers
> > do not have the lock, you dont mean "fix" by grabbing the lock?
>
> I'm saying that if we decide to do the debugging warning (and I think
> everybody is agreeing that we should), then we _will_ fix it by just
> grabbing the lock in all the paths. That's what we already did with
> do_mmap(), after all.
OK - you dont like the idea of having a wrapper to grab the lock and use that ?
> I suspect it's not strictly needed, but as Alan has said, even though
> nothing else can chaneg the vma's at the same time, it's the right thing
> to do to keep /proc reads happy (which _can_ happen) anyway. And more
> importantly, invariants are nice - to the point where it's good to follow
> the rules even if it might not be strictly necessary.
I agree. The chance of getting this wrong in the future is smaller if we use the
the "do_brk requires mmap_sem" rule.
> I just wanted to keep these two issues separate. I think it's one thing to
> fix a known bug, and another thing to add some debug infrastructure to
> make sure that it doesn't happen in the future. So I think the WARN_ON() +
> adding of extra locking is a separate stage from fixing the known problem.
OK - I think v2.4 being consistent wrt function names and calling convetion in
this area is important.
If you don't like the wrapper I'll change all callers do grab the lock accordingly.
And have this warning as you suggested (which makes a hell lot more sense):
--- mm/mmap.c.orig 2005-01-07 09:14:01.000000000 -0200
+++ mm/mmap.c 2005-01-09 08:56:55.521436072 -0200
@@ -1061,6 +1061,13 @@
}
/*
+ * mm->mmap_sem is required to protect against another thread
+ * changing the mappings while we sleep (on kmalloc for one).
+ */
+ if (down_read_trylock(&mm->mmap_sem))
+ BUG();
+
+ /*
* Clear old maps. this also does some error checking for us
*/
munmap_back:
Hi,
sorry, if this is a stupid question, but I now got lost in your discussion:
Is Linus patch at http://linux.bkbits.net:8080/linux-2.6/[email protected]
enough to close the security hole, or do we need more (or wait a little
longer)?
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Mon, Jan 10, 2005 at 09:34:46AM +0100, Frank Steiner wrote:
> Hi,
>
> sorry, if this is a stupid question, but I now got lost in your discussion:
>
> Is Linus patch at http://linux.bkbits.net:8080/linux-2.6/[email protected]
> enough to close the security hole, or do we need more (or wait a little
> longer)?
I dont think this enough - wait a little longer :)
On Llu, 2005-01-10 at 08:34, Frank Steiner wrote:
> Hi,
>
> sorry, if this is a stupid question, but I now got lost in your discussion:
>
> Is Linus patch at http://linux.bkbits.net:8080/linux-2.6/[email protected]
> enough to close the security hole, or do we need more (or wait a little
> longer)?
If you want a patch right now grab the -ac patches (they also fix a pile
of other less holes found including the grsecurity ones). The -ac
version of the fix should be complete but it won't be the final one in
the master tree (I get to nail holes shut Linus has to do the right
engineering for the long term 8))
Thanks Alan, thanks Marcelo!
Alan Cox wrote
> If you want a patch right now grab the -ac patches (they also fix a pile
> of other less holes found including the grsecurity ones). The -ac
> version of the fix should be complete but it won't be the final one in
> the master tree (I get to nail holes shut Linus has to do the right
> engineering for the long term 8))
So I will use -ac until 2.6.11 is out :-)
Thanks!
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote:
> Another issue is likely that we should make the whole "uselib()"
> interfaces configurable. I don't think modern binaries use it (where
> "modern" probably means "compiled within the last 8 years" ;).
Here's an initial stab at such a patch. It adds a new config option,
CONFIG_SYS_USELIB. I wrote the patch against 2.6.10-bk14 but I tested it
against vanilla 2.6.10. Also, it only updates defconfig for i386, as
that's the only platform I can test at the moment.
There's probably plenty to criticize in this patch, but it's a start...
Signed-off-by: Barry K. Nathan <[email protected]>
diff -ruN linux-2.6.10-bk14/arch/i386/defconfig linux-2.6.10-bk14-bkn1/arch/i386/defconfig
--- linux-2.6.10-bk14/arch/i386/defconfig 2005-01-11 09:38:04.847566774 -0800
+++ linux-2.6.10-bk14-bkn1/arch/i386/defconfig 2005-01-11 11:15:02.127586567 -0800
@@ -195,6 +195,7 @@
#
# Executable file formats
#
+CONFIG_SYS_USELIB=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
diff -ruN linux-2.6.10-bk14/fs/exec.c linux-2.6.10-bk14-bkn1/fs/exec.c
--- linux-2.6.10-bk14/fs/exec.c 2005-01-11 09:38:26.215892759 -0800
+++ linux-2.6.10-bk14-bkn1/fs/exec.c 2005-01-11 11:06:19.482007489 -0800
@@ -111,6 +111,7 @@
module_put(fmt->module);
}
+#ifdef CONFIG_SYS_USELIB
/*
* Note that a shared library must be both readable and executable due to
* security reasons.
@@ -167,6 +168,7 @@
path_release(&nd);
goto out;
}
+#endif
/*
* count() counts the number of strings in array ARGV.
diff -ruN linux-2.6.10-bk14/fs/Kconfig.binfmt linux-2.6.10-bk14-bkn1/fs/Kconfig.binfmt
--- linux-2.6.10-bk14/fs/Kconfig.binfmt 2005-01-11 09:38:25.702932946 -0800
+++ linux-2.6.10-bk14-bkn1/fs/Kconfig.binfmt 2005-01-11 11:09:16.873962890 -0800
@@ -1,3 +1,16 @@
+config SYS_USELIB
+ bool "sys_uselib syscall support (needed for old binaries)"
+ ---help---
+ Many old binaries (e.g. dynamically linked a.out binaries, and
+ ELF binaries that are dynamically linked against libc5), require
+ the sys_uselib syscall. However, on the typical Linux system, this
+ code is just old cruft that no longer serves a purpose.
+
+ If you are unsure, say "N" if you care more about security and
+ trimming bloat, or say "Y" if you care more about compatibility
+ with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
+ below, you probably should answer "Y" here.)
+
config BINFMT_ELF
bool "Kernel support for ELF binaries"
depends on MMU
diff -ruN linux-2.6.10-bk14/kernel/sys_ni.c linux-2.6.10-bk14-bkn1/kernel/sys_ni.c
--- linux-2.6.10-bk14/kernel/sys_ni.c 2004-12-14 03:18:07.379372435 -0800
+++ linux-2.6.10-bk14-bkn1/kernel/sys_ni.c 2005-01-11 13:25:38.670751478 -0800
@@ -76,6 +76,7 @@
cond_syscall(sys_keyctl)
cond_syscall(compat_sys_keyctl)
cond_syscall(compat_sys_socketcall)
+cond_syscall(sys_uselib)
/* arch-specific weak syscall entries */
cond_syscall(sys_pciconfig_read)
On Tue, Jan 11, 2005 at 02:51:27PM -0800, Barry K. Nathan wrote:
> On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote:
> > Another issue is likely that we should make the whole "uselib()"
> > interfaces configurable. I don't think modern binaries use it (where
> > "modern" probably means "compiled within the last 8 years" ;).
libc 5.4.46 is from 1998-06-21 or so, glibc 2.0.5 from 1997-08-25 or so.
> +config SYS_USELIB
> + bool "sys_uselib syscall support (needed for old binaries)"
> + ---help---
> + Many old binaries (e.g. dynamically linked a.out binaries, and
> + ELF binaries that are dynamically linked against libc5), require
> + the sys_uselib syscall. However, on the typical Linux system, this
> + code is just old cruft that no longer serves a purpose.
> +
> + If you are unsure, say "N" if you care more about security and
> + trimming bloat, or say "Y" if you care more about compatibility
> + with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
> + below, you probably should answer "Y" here.)
s/sys_uselib/uselib/
The system call is uselib().
Hmm - old cruft.. Why insult your users?
I do not have source for Maple. And my xmaple binary works just fine.
But it is a libc4 binary.
You mean "on the typical recently installed Linux system, with nothing
but the usual Linux utilities".
People always claim that Linux is good in preserving binary compatibility.
Don't know how true that was, but introducing such config options doesnt
help.
Let me also mutter about something else.
In principle configuration options are evil. Nobody wants fifty thousand
configuration options. But I see them multiply like ioctls.
There should be a significant gain in having a config option.
Maybe some argue that there is a gain in security here. Perhaps.
Or a gain in memory. It is negligible.
I see mostly a loss.
There are more ancient system calls, like old_stat and oldolduname.
Do we want separate options for each system call that is obsoleted?
Andries
On Tue, 11 Jan 2005, Barry K. Nathan wrote:
> On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote:
> > Another issue is likely that we should make the whole "uselib()"
> > interfaces configurable. I don't think modern binaries use it (where
> > "modern" probably means "compiled within the last 8 years" ;).
>
> Here's an initial stab at such a patch. It adds a new config option,
[...]
> +config SYS_USELIB
> + bool "sys_uselib syscall support (needed for old binaries)"
> + ---help---
> + Many old binaries (e.g. dynamically linked a.out binaries, and
> + ELF binaries that are dynamically linked against libc5), require
> + the sys_uselib syscall. However, on the typical Linux system, this
> + code is just old cruft that no longer serves a purpose.
> +
> + If you are unsure, say "N" if you care more about security and
> + trimming bloat, or say "Y" if you care more about compatibility
> + with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
> + below, you probably should answer "Y" here.)
> +
This last bit is not too readable IMO. I'd suggest something like this
instead :
If you care mostly about security and trimming bloat, say "N".
If you care more about compatibility with old software (or if
you will answer "Y" or "M" to BINFMT_AOUT below) say "Y".
If unsure, say "Y".
--
Jesper Juhl
On Wed, 12 Jan 2005, Andries Brouwer wrote:
> On Tue, Jan 11, 2005 at 02:51:27PM -0800, Barry K. Nathan wrote:
> > On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote:
> > > Another issue is likely that we should make the whole "uselib()"
> > > interfaces configurable. I don't think modern binaries use it (where
> > > "modern" probably means "compiled within the last 8 years" ;).
>
> libc 5.4.46 is from 1998-06-21 or so, glibc 2.0.5 from 1997-08-25 or so.
>
> > +config SYS_USELIB
> > + bool "sys_uselib syscall support (needed for old binaries)"
> > + ---help---
> > + Many old binaries (e.g. dynamically linked a.out binaries, and
> > + ELF binaries that are dynamically linked against libc5), require
> > + the sys_uselib syscall. However, on the typical Linux system, this
> > + code is just old cruft that no longer serves a purpose.
> > +
> > + If you are unsure, say "N" if you care more about security and
> > + trimming bloat, or say "Y" if you care more about compatibility
> > + with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
> > + below, you probably should answer "Y" here.)
>
> s/sys_uselib/uselib/
> The system call is uselib().
>
> Hmm - old cruft.. Why insult your users?
> I do not have source for Maple. And my xmaple binary works just fine.
> But it is a libc4 binary.
>
> You mean "on the typical recently installed Linux system, with nothing
> but the usual Linux utilities".
>
> People always claim that Linux is good in preserving binary compatibility.
> Don't know how true that was, but introducing such config options doesnt
> help.
>
> Let me also mutter about something else.
> In principle configuration options are evil. Nobody wants fifty thousand
> configuration options. But I see them multiply like ioctls.
> There should be a significant gain in having a config option.
>
I don't have much to say exceppt express my agreement. That is so very
true.
The less config options the user is presented with the better, and for
each config option there should be a very good reason. Very much agreed.
> Maybe some argue that there is a gain in security here. Perhaps.
> Or a gain in memory. It is negligible.
> I see mostly a loss.
>
> There are more ancient system calls, like old_stat and oldolduname.
> Do we want separate options for each system call that is obsoleted?
>
IMO, no, we do not.
--
Jesper Juhl
On Wed, 12 Jan 2005, Jesper Juhl wrote:
> On Wed, 12 Jan 2005, Andries Brouwer wrote:
>
>> On Tue, Jan 11, 2005 at 02:51:27PM -0800, Barry K. Nathan wrote:
>>> On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote:
>>>> Another issue is likely that we should make the whole "uselib()"
>>>> interfaces configurable. I don't think modern binaries use it (where
>>>> "modern" probably means "compiled within the last 8 years" ;).
>>
>> libc 5.4.46 is from 1998-06-21 or so, glibc 2.0.5 from 1997-08-25 or so.
>>
>>> +config SYS_USELIB
>>> + bool "sys_uselib syscall support (needed for old binaries)"
>>> + ---help---
>>> + Many old binaries (e.g. dynamically linked a.out binaries, and
>>> + ELF binaries that are dynamically linked against libc5), require
>>> + the sys_uselib syscall. However, on the typical Linux system, this
>>> + code is just old cruft that no longer serves a purpose.
>>> +
>>> + If you are unsure, say "N" if you care more about security and
>>> + trimming bloat, or say "Y" if you care more about compatibility
>>> + with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
>>> + below, you probably should answer "Y" here.)
>>
>> s/sys_uselib/uselib/
>> The system call is uselib().
>>
>> Hmm - old cruft.. Why insult your users?
>> I do not have source for Maple. And my xmaple binary works just fine.
>> But it is a libc4 binary.
>>
>> You mean "on the typical recently installed Linux system, with nothing
>> but the usual Linux utilities".
>>
>> People always claim that Linux is good in preserving binary compatibility.
>> Don't know how true that was, but introducing such config options doesnt
>> help.
>>
>> Let me also mutter about something else.
>> In principle configuration options are evil. Nobody wants fifty thousand
>> configuration options. But I see them multiply like ioctls.
>> There should be a significant gain in having a config option.
>>
> I don't have much to say exceppt express my agreement. That is so very
> true.
> The less config options the user is presented with the better, and for
> each config option there should be a very good reason. Very much agreed.
>
>
>> Maybe some argue that there is a gain in security here. Perhaps.
>> Or a gain in memory. It is negligible.
>> I see mostly a loss.
>>
>> There are more ancient system calls, like old_stat and oldolduname.
>> Do we want separate options for each system call that is obsoleted?
>>
> IMO, no, we do not.
how about something like the embedded, experimental, and broken options.
that way normal users can disable all of them at a stroke, people who need
them can add them in.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
On Tue, Jan 11, 2005 at 05:18:16PM -0800, David Lang wrote:
> On Wed, 12 Jan 2005, Jesper Juhl wrote:
>
> >On Wed, 12 Jan 2005, Andries Brouwer wrote:
> >
> >>On Tue, Jan 11, 2005 at 02:51:27PM -0800, Barry K. Nathan wrote:
> >>>On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote:
> >>>>Another issue is likely that we should make the whole "uselib()"
> >>>>interfaces configurable. I don't think modern binaries use it (where
> >>>>"modern" probably means "compiled within the last 8 years" ;).
> >>
> >>libc 5.4.46 is from 1998-06-21 or so, glibc 2.0.5 from 1997-08-25 or so.
> >>
> >>>+config SYS_USELIB
> >>>+ bool "sys_uselib syscall support (needed for old binaries)"
> >>>+ ---help---
> >>>+ Many old binaries (e.g. dynamically linked a.out binaries, and
> >>>+ ELF binaries that are dynamically linked against libc5), require
> >>>+ the sys_uselib syscall. However, on the typical Linux system, this
> >>>+ code is just old cruft that no longer serves a purpose.
> >>>+
> >>>+ If you are unsure, say "N" if you care more about security and
> >>>+ trimming bloat, or say "Y" if you care more about compatibility
> >>>+ with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
> >>>+ below, you probably should answer "Y" here.)
> >>
> >>s/sys_uselib/uselib/
> >>The system call is uselib().
> >>
> >>Hmm - old cruft.. Why insult your users?
> >>I do not have source for Maple. And my xmaple binary works just fine.
> >>But it is a libc4 binary.
> >>
> >>You mean "on the typical recently installed Linux system, with nothing
> >>but the usual Linux utilities".
> >>
> >>People always claim that Linux is good in preserving binary compatibility.
> >>Don't know how true that was, but introducing such config options doesnt
> >>help.
> >>
> >>Let me also mutter about something else.
> >>In principle configuration options are evil. Nobody wants fifty thousand
> >>configuration options. But I see them multiply like ioctls.
> >>There should be a significant gain in having a config option.
> >>
> >I don't have much to say exceppt express my agreement. That is so very
> >true.
> >The less config options the user is presented with the better, and for
> >each config option there should be a very good reason. Very much agreed.
> >
> >
> >>Maybe some argue that there is a gain in security here. Perhaps.
> >>Or a gain in memory. It is negligible.
> >>I see mostly a loss.
> >>
> >>There are more ancient system calls, like old_stat and oldolduname.
> >>Do we want separate options for each system call that is obsoleted?
> >>
> >IMO, no, we do not.
>
> how about something like the embedded, experimental, and broken options.
> that way normal users can disable all of them at a stroke, people who need
> them can add them in.
Thats just not an option - you would have zillions of config options.
Moreover this is a system call, and the system call interface is one of the few
supposed to be stable. You shouldnt simply assume that "no one will ever use sys_uselib()" -
there might be programs out there who use it.
I agree with Andries.
On Wed, Jan 12, 2005 at 12:59:07AM +0100, Andries Brouwer wrote:
> > +config SYS_USELIB
> > + bool "sys_uselib syscall support (needed for old binaries)"
> > + ---help---
> > + Many old binaries (e.g. dynamically linked a.out binaries, and
> > + ELF binaries that are dynamically linked against libc5), require
> > + the sys_uselib syscall. However, on the typical Linux system, this
> > + code is just old cruft that no longer serves a purpose.
> > +
> > + If you are unsure, say "N" if you care more about security and
> > + trimming bloat, or say "Y" if you care more about compatibility
> > + with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
> > + below, you probably should answer "Y" here.)
>
> s/sys_uselib/uselib/
> The system call is uselib().
Ok.
> Hmm - old cruft.. Why insult your users?
> I do not have source for Maple. And my xmaple binary works just fine.
> But it is a libc4 binary.
Err... I didn't see it as "insulting [my] users". That was not at all
what I intended. I'll have to rework that...
> You mean "on the typical recently installed Linux system,
> with nothing but the usual Linux utilities".
No, more like, "on the typical Linux system installed since 2000,
running additional 3rd-party software from no earlier than 2001", or
something vaguely like that.
> People always claim that Linux is good in preserving binary compatibility.
> Don't know how true that was, but introducing such config options doesnt
> help.
Binary compatibility is good to have, but it isn't everything in life.
*Optionally* breaking compatibility with certain types of old binaries
doesn't seem so bad to me. People who want binary compatibility can have
it, and people who don't need it can choose to not install the old code
on their systems.
> Let me also mutter about something else.
> In principle configuration options are evil. Nobody wants fifty thousand
> configuration options. But I see them multiply like ioctls.
> There should be a significant gain in having a config option.
>
> Maybe some argue that there is a gain in security here. Perhaps.
> Or a gain in memory. It is negligible.
> I see mostly a loss.
It's probably the case that on millions (and growing) of Linux systems
out there, the one and only possible use of this syscall is as a
security threat. On these systems, with no need for libc4/5 binaries
(and no installed versions of these libraries anyway), there is **NO**
other redeeming use for this syscall.
If removal of this syscall isn't a config option, then the alternatives
are out-of-tree patches, forking 2.7 over this issue alone, or settling
for the status quo. A 3rd-party patch would increase vendor kernel
divergence again (which is also evil), and starting 2.7 just for this
would be overkill. And I'm not the only person who is not satisfied
with the current situation.
> There are more ancient system calls, like old_stat and oldolduname.
> Do we want separate options for each system call that is obsoleted?
A config option for each one would be a bit much, I'll agree. However,
I think having a single config option for the whole bunch would be a
good idea. At the time that I wrote this patch, I was thinking that the
rest of the old syscalls would be a second config option, but now that I
think about it, it makes more sense for it to just be one config option,
not two.
FWIW, my current patch does uselib() alone, because I figured that would
be less controversial than trying to do all of the old syscalls now.
Maybe I'll rethink that decision though.
Thank you for your feedback. It's quite helpful, and I greatly
appreciate it.
-Barry K. Nathan <[email protected]>
On Tue, 11 Jan 2005, Barry K. Nathan wrote:
>> People always claim that Linux is good in preserving binary compatibility.
>> Don't know how true that was, but introducing such config options doesnt
>> help.
>
> Binary compatibility is good to have, but it isn't everything in life.
> *Optionally* breaking compatibility with certain types of old binaries
> doesn't seem so bad to me. People who want binary compatibility can have
> it, and people who don't need it can choose to not install the old code
> on their systems.
we already allow people to not support a.out formats, this breaks binary
compatability (probably much more severely then this does)
however we do need to be very sure that if any call is dropped as being
obsolete it really is not likly to be used (see all the recent flames
about people dropping (or proposing dropping) features out of the kernel
for examples of what not to mark obsolete)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
On Tue, Jan 11, 2005 at 06:12:46PM -0800, Barry K. Nathan wrote:
>...
> > People always claim that Linux is good in preserving binary compatibility.
> > Don't know how true that was, but introducing such config options doesnt
> > help.
>
> Binary compatibility is good to have, but it isn't everything in life.
> *Optionally* breaking compatibility with certain types of old binaries
> doesn't seem so bad to me. People who want binary compatibility can have
> it, and people who don't need it can choose to not install the old code
> on their systems.
>
> > Let me also mutter about something else.
> > In principle configuration options are evil. Nobody wants fifty thousand
> > configuration options. But I see them multiply like ioctls.
> > There should be a significant gain in having a config option.
> >
> > Maybe some argue that there is a gain in security here. Perhaps.
> > Or a gain in memory. It is negligible.
> > I see mostly a loss.
>
> It's probably the case that on millions (and growing) of Linux systems
> out there, the one and only possible use of this syscall is as a
> security threat. On these systems, with no need for libc4/5 binaries
> (and no installed versions of these libraries anyway), there is **NO**
> other redeeming use for this syscall.
>
> If removal of this syscall isn't a config option, then the alternatives
> are out-of-tree patches, forking 2.7 over this issue alone, or settling
> for the status quo. A 3rd-party patch would increase vendor kernel
> divergence again (which is also evil), and starting 2.7 just for this
> would be overkill. And I'm not the only person who is not satisfied
> with the current situation.
uselib() is only one of the zillion places in the Linux kernel where
security vulnerabilities can occur. OK, now one was found there, but
is this enough for changing the status quo if the zillion other places
with possible vulnerabilities are still present and will stay?
If a vendor chooses to diverge from the ftp.kernel.org kernel in this
point, I don't see why this should cause any "evil" problems.
> > There are more ancient system calls, like old_stat and oldolduname.
> > Do we want separate options for each system call that is obsoleted?
>
> A config option for each one would be a bit much, I'll agree. However,
> I think having a single config option for the whole bunch would be a
> good idea. At the time that I wrote this patch, I was thinking that the
> rest of the old syscalls would be a second config option, but now that I
> think about it, it makes more sense for it to just be one config option,
> not two.
>
> FWIW, my current patch does uselib() alone, because I figured that would
> be less controversial than trying to do all of the old syscalls now.
> Maybe I'll rethink that decision though.
>...
A patch for one config option for all pre-libc6 system calls might be
interesting if it allows to disable a serious amount of system calls and
is well-tested to not break any libc6, libc5 or libc4 binaries.
> -Barry K. Nathan <[email protected]>
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Jan 11, 2005 at 08:36:41PM -0200, Marcelo Tosatti wrote:
> On Tue, Jan 11, 2005 at 05:18:16PM -0800, David Lang wrote:
[snip]
> > how about something like the embedded, experimental, and broken options.
> > that way normal users can disable all of them at a stroke, people who need
> > them can add them in.
That is what I had in mind for the longer term. Now that I think about
it, my current patch is probably a bad way to get from here to there --
it adds a config option that would later *need* to be renamed and moved
to a different category.
(To be specific, the concept I have in mind is to have an option that
disables the syscalls that are usually used only by libc5 and earlier.)
> Thats just not an option - you would have zillions of config options.
I don't see how it would be zillions, but it's possible there's
something I'm not yet understanding.
> Moreover this is a system call, and the system call interface is one of the few
> supposed to be stable. You shouldnt simply assume that "no one will ever use sys_uselib()" -
> there might be programs out there who use it.
And if you have programs that need it, you (or your vendor) can set the
config option accordingly.
-Barry K. Nathan <[email protected]>
On Tue, Jan 11, 2005 at 06:32:18PM -0800, Barry K. Nathan wrote:
> On Tue, Jan 11, 2005 at 08:36:41PM -0200, Marcelo Tosatti wrote:
> > On Tue, Jan 11, 2005 at 05:18:16PM -0800, David Lang wrote:
> [snip]
> > > how about something like the embedded, experimental, and broken options.
> > > that way normal users can disable all of them at a stroke, people who need
> > > them can add them in.
>
> That is what I had in mind for the longer term. Now that I think about
> it, my current patch is probably a bad way to get from here to there --
> it adds a config option that would later *need* to be renamed and moved
> to a different category.
>
> (To be specific, the concept I have in mind is to have an option that
> disables the syscalls that are usually used only by libc5 and earlier.)
Out of curiosity do you have a list of such syscalls?
"usually" is the problem - you cannot be sure what syscalls unknown applications are using.
> > Thats just not an option - you would have zillions of config options.
>
> I don't see how it would be zillions, but it's possible there's
> something I'm not yet understanding.
I assumed David was talking about having every different feature as a config
option.
> > Moreover this is a system call, and the system call interface is one of the few
> > supposed to be stable. You shouldnt simply assume that "no one will ever use sys_uselib()" -
> > there might be programs out there who use it.
>
> And if you have programs that need it, you (or your vendor) can set the
> config option accordingly.
The possibility is that there might be unknown applications which use these "obsolete" system
calls.
Vendors who want to support older applications (most distributions) will have to enable all
these option(s), while users who do not need one or a few of them can disable accordingly
("specialized" applications).
One thing is that ordinary users are not supposed to know what system calls his applications
are going to use, most of these users will be running vendor shipped kernels anyway.
I personally dont like the idea of disabling "obsolete" system calls with config options,
but it is useful for specialized applications to save memory.
Are many users going to benefit from it?
On Tue, 2005-01-11 at 18:12, Barry K. Nathan wrote:
> > There are more ancient system calls, like old_stat and oldolduname.
> > Do we want separate options for each system call that is obsoleted?
> A config option for each one would be a bit much, I'll agree. However,
> I think having a single config option for the whole bunch would be a
> good idea.
> less controversial than trying to do all of the old syscalls now.
Well the most controversial one-stop option could be a by date option.
CONFIG_OBSOLETE_TIME could default to 199201 or whatever
then you could then make things obsolete by wrapping them with
#if CONFIG_OBSOLETE_TIME <= 199805
/* old stat stuff */
#endif
#if CONFIG_OBSOLETE_TIME <= 200211
/* old uname stuff */
#endif
#if CONFIG_OBSOLETE_TIME <= 200501
/* uselib */
#endif
Then people could select with one option just to what extent they want
to support old crufty stuff. So one person could go super lean and mean
by choosing 200502 , while another could choose 200000 just to have
things from this century. Most people could just leave it alone.
--
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677
On Tue, Jan 11, 2005 at 10:56:47PM -0200, Marcelo Tosatti wrote:
> Out of curiosity do you have a list of such syscalls?
Not yet. I wasn't expecting to need the list quite this soon.
> "usually" is the problem - you cannot be sure what syscalls unknown
> applications are using.
[snip]
> > And if you have programs that need it, you (or your vendor) can set the
> > config option accordingly.
>
> The possibility is that there might be unknown applications which use
> these "obsolete" system calls.
True, but I would expect to see a strong correlation between the use of
"obsolete" syscalls and the use of "obsolete" libraries (libc4, libc5).
Until there's a list of obsolete syscalls, we can't say for sure,
though.
> Vendors who want to support older applications (most distributions) will
> have to enable all these option(s), while users who do not need one or
> a few of them can disable accordingly ("specialized" applications).
There are at least one or two distributions (I'm thinking of vendors
named after headwear, although there are probably others) that have not
shipped libc5 compat libraries for a long while. IIRC they're also
shipping their kernels with CONFIG_BINFMT_AOUT completely disabled
(not even modular).
So, these vendors at least are (to the best of my knowledge) only
supporting older applications *up to a point*.
> I personally dont like the idea of disabling "obsolete" system calls
> with config options, but it is useful for specialized applications to
> save memory.
>
> Are many users going to benefit from it?
It's going to be hard to tell without full-blown code to examine and
test, but my hope is that it will be able to disable something
substantial for people who have completely abandoned libc4/libc5. And
that's many users.
Even if the final patch is unable to benefit many users, perhaps the
process of creating that patch will still be worth it if it gives us a
better idea of which syscalls are being used and which ones aren't.
-Barry K. Nathan <[email protected]>
On Wed, Jan 12, 2005 at 12:59:07AM +0100, Andries Brouwer wrote:
> s/sys_uselib/uselib/
> The system call is uselib().
>
> Hmm - old cruft.. Why insult your users?
> I do not have source for Maple. And my xmaple binary works just fine.
> But it is a libc4 binary.
>
> You mean "on the typical recently installed Linux system, with nothing
> but the usual Linux utilities".
>
> People always claim that Linux is good in preserving binary compatibility.
> Don't know how true that was, but introducing such config options doesnt
> help.
>
> Let me also mutter about something else.
> In principle configuration options are evil. Nobody wants fifty thousand
> configuration options. But I see them multiply like ioctls.
> There should be a significant gain in having a config option.
>
>
> Maybe some argue that there is a gain in security here. Perhaps.
> Or a gain in memory. It is negligible.
> I see mostly a loss.
>
> There are more ancient system calls, like old_stat and oldolduname.
> Do we want separate options for each system call that is obsoleted?
Agreed to this complaint. I still think it might be a good idea to
allow configuring obsolete syscalls out, but doing that on a per-syscall
basis sounds like a bad idea. I always liked the way FreeBSD one
conditionals for everything that was obsoleted in a release. So by setting
only few options you could select how old binaries you want to support,
defaulting to on for all of them.
On Tue, Jan 11, 2005 at 10:10:43PM -0800, Barry K. Nathan wrote:
> On Tue, Jan 11, 2005 at 10:56:47PM -0200, Marcelo Tosatti wrote:
> > Out of curiosity do you have a list of such syscalls?
>
> Not yet. I wasn't expecting to need the list quite this soon.
>
> > "usually" is the problem - you cannot be sure what syscalls unknown
> > applications are using.
> [snip]
> > > And if you have programs that need it, you (or your vendor) can set the
> > > config option accordingly.
> >
> > The possibility is that there might be unknown applications which use
> > these "obsolete" system calls.
>
> True, but I would expect to see a strong correlation between the use of
> "obsolete" syscalls and the use of "obsolete" libraries (libc4, libc5).
> Until there's a list of obsolete syscalls, we can't say for sure,
> though.
>...
The only interesting correlation are system calls that are _only_ used
by libc4/libc5 applications.
> > I personally dont like the idea of disabling "obsolete" system calls
> > with config options, but it is useful for specialized applications to
> > save memory.
> >
> > Are many users going to benefit from it?
>
> It's going to be hard to tell without full-blown code to examine and
> test, but my hope is that it will be able to disable something
> substantial for people who have completely abandoned libc4/libc5. And
> that's many users.
>
> Even if the final patch is unable to benefit many users, perhaps the
> process of creating that patch will still be worth it if it gives us a
> better idea of which syscalls are being used and which ones aren't.
Make such a patch, test it thoroughly and then send it here for review.
It can't be guaranteed that your patch will be accepted, but as soon as
you'll present the patch the discussion will become more flesh.
> -Barry K. Nathan <[email protected]>
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Jan 11, 2005 at 09:11:40PM -0800, Stephen Pollei wrote:
> On Tue, 2005-01-11 at 18:12, Barry K. Nathan wrote:
> > > There are more ancient system calls, like old_stat and oldolduname.
> > > Do we want separate options for each system call that is obsoleted?
>
> > A config option for each one would be a bit much, I'll agree. However,
> > I think having a single config option for the whole bunch would be a
> > good idea.
>
> > less controversial than trying to do all of the old syscalls now.
> Well the most controversial one-stop option could be a by date option.
> CONFIG_OBSOLETE_TIME could default to 199201 or whatever
>
> then you could then make things obsolete by wrapping them with
> #if CONFIG_OBSOLETE_TIME <= 199805
> /* old stat stuff */
> #endif
> #if CONFIG_OBSOLETE_TIME <= 200211
> /* old uname stuff */
> #endif
> #if CONFIG_OBSOLETE_TIME <= 200501
> /* uselib */
> #endif
>
> Then people could select with one option just to what extent they want
> to support old crufty stuff. So one person could go super lean and mean
> by choosing 200502 , while another could choose 200000 just to have
> things from this century. Most people could just leave it alone.
I don't see much value in this proposal - it would only cause confusion
for users.
Except for some obscure cases, every application compiled with any libc6
version is expected to work with even the most recent libc6.
OTOH, libc4/libc5 <-> libc6 is a natural border since support for older
libc's anyways requires extra support by the distribution.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Jan 12, 2005 at 05:47:29PM +0100, Adrian Bunk wrote:
> The only interesting correlation are system calls that are _only_ used
> by libc4/libc5 applications.
Well, in theory it might be possible to create a sadistic libc6 app that
also uses old system calls anyway. I'm hoping that isn't common.
> Make such a patch, test it thoroughly and then send it here for review.
>
> It can't be guaranteed that your patch will be accepted, but as soon as
> you'll present the patch the discussion will become more flesh.
Right.
I don't want to commit to an exact timeline, but this is something I'm
planning to do soon.
-Barry K. Nathan <[email protected]>
On Tue, Jan 11, 2005 at 08:36:41PM -0200, Marcelo Tosatti wrote:
> > >>There are more ancient system calls, like old_stat and oldolduname.
> > >>Do we want separate options for each system call that is obsoleted?
> > >>
> > >IMO, no, we do not.
> >
> > how about something like the embedded, experimental, and broken options.
> > that way normal users can disable all of them at a stroke, people who need
> > them can add them in.
>
> Thats just not an option - you would have zillions of config options.
>
> Moreover this is a system call, and the system call interface is one of the few
> supposed to be stable. You shouldnt simply assume that "no one will ever use sys_uselib()" -
> there might be programs out there who use it.
>
> I agree with Andries.
In -tiny, I've added config options for disabling _many_ syscalls (but
not this one). They all go under EMBEDDED. And then I changed the
description of EMBEDDED to imply that changing anything takes you into
nonstandard, unsupported territory.
--
Mathematics is the supreme nostalgia of our time.