* uselib() & 2.6.X? @ 2005-01-07 15:59 Lukasz Trabinski 2005-01-07 17:07 ` Marcelo Tosatti 0 siblings, 1 reply; 42+ messages in thread From: Lukasz Trabinski @ 2005-01-07 15:59 UTC (permalink / raw) To: linux-kernel 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 ]* ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-07 15:59 uselib() & 2.6.X? Lukasz Trabinski @ 2005-01-07 17:07 ` Marcelo Tosatti 2005-01-07 20:27 ` linux-os 2005-01-07 22:49 ` Alan Cox 0 siblings, 2 replies; 42+ messages in thread From: Marcelo Tosatti @ 2005-01-07 17:07 UTC (permalink / raw) To: Lukasz Trabinski; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 672 bytes --] 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. [-- Attachment #2: 2.6.10-mm1-brk-locked.patch --] [-- Type: text/plain, Size: 7230 bytes --] diff -Nur linux-2.6.10.orig/arch/mips/kernel/irixelf.c linux-2.6.10/arch/mips/kernel/irixelf.c --- linux-2.6.10.orig/arch/mips/kernel/irixelf.c 2005-01-03 16:17:00.000000000 -0200 +++ linux-2.6.10/arch/mips/kernel/irixelf.c 2005-01-03 16:44:59.909144520 -0200 @@ -127,7 +127,7 @@ end = PAGE_ALIGN(end); if (end <= start) return; - do_brk(start, end - start); + do_brk_locked(start, end - start); } diff -Nur linux-2.6.10.orig/arch/x86_64/ia32/ia32_aout.c linux-2.6.10/arch/x86_64/ia32/ia32_aout.c --- linux-2.6.10.orig/arch/x86_64/ia32/ia32_aout.c 2005-01-03 16:17:04.000000000 -0200 +++ linux-2.6.10/arch/x86_64/ia32/ia32_aout.c 2005-01-03 16:46:53.846823360 -0200 @@ -115,7 +115,7 @@ end = PAGE_ALIGN(end); if (end <= start) return; - do_brk(start, end - start); + do_brk_locked(start, end - start); } #if CORE_DUMP @@ -325,7 +325,7 @@ pos = 32; map_size = ex.a_text+ex.a_data; - error = do_brk(text_addr & PAGE_MASK, map_size); + error = do_brk_locked(text_addr & PAGE_MASK, map_size); if (error != (text_addr & PAGE_MASK)) { send_sig(SIGKILL, current, 0); return error; @@ -361,7 +361,7 @@ if (!bprm->file->f_op->mmap||((fd_offset & ~PAGE_MASK) != 0)) { loff_t pos = fd_offset; - do_brk(N_TXTADDR(ex), ex.a_text+ex.a_data); + do_brk_locked(N_TXTADDR(ex), ex.a_text+ex.a_data); bprm->file->f_op->read(bprm->file,(char *)N_TXTADDR(ex), ex.a_text+ex.a_data, &pos); flush_icache_range((unsigned long) N_TXTADDR(ex), @@ -470,7 +470,7 @@ } #endif - do_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss); + do_brk_locked(start_addr, ex.a_text + ex.a_data + ex.a_bss); file->f_op->read(file, (char *)start_addr, ex.a_text + ex.a_data, &pos); @@ -494,7 +494,7 @@ len = PAGE_ALIGN(ex.a_text + ex.a_data); bss = ex.a_text + ex.a_data + ex.a_bss; if (bss > len) { - error = do_brk(start_addr + len, bss - len); + error = do_brk_locked(start_addr + len, bss - len); retval = error; if (error != start_addr + len) goto out; diff -Nur linux-2.6.10.orig/fs/binfmt_aout.c linux-2.6.10/fs/binfmt_aout.c --- linux-2.6.10.orig/fs/binfmt_aout.c 2005-01-03 16:17:07.000000000 -0200 +++ linux-2.6.10/fs/binfmt_aout.c 2005-01-03 16:42:25.212661960 -0200 @@ -50,7 +50,7 @@ start = PAGE_ALIGN(start); end = PAGE_ALIGN(end); if (end > start) { - unsigned long addr = do_brk(start, end - start); + unsigned long addr = do_brk_locked(start, end - start); if (BAD_ADDR(addr)) return addr; } @@ -323,10 +323,10 @@ loff_t pos = fd_offset; /* Fuck me plenty... */ /* <AOL></AOL> */ - error = do_brk(N_TXTADDR(ex), ex.a_text); + error = do_brk_locked(N_TXTADDR(ex), ex.a_text); bprm->file->f_op->read(bprm->file, (char *) N_TXTADDR(ex), ex.a_text, &pos); - error = do_brk(N_DATADDR(ex), ex.a_data); + error = do_brk_locked(N_DATADDR(ex), ex.a_data); bprm->file->f_op->read(bprm->file, (char *) N_DATADDR(ex), ex.a_data, &pos); goto beyond_if; @@ -347,7 +347,7 @@ map_size = ex.a_text+ex.a_data; #endif - error = do_brk(text_addr & PAGE_MASK, map_size); + error = do_brk_locked(text_addr & PAGE_MASK, map_size); if (error != (text_addr & PAGE_MASK)) { send_sig(SIGKILL, current, 0); return error; @@ -382,7 +382,7 @@ if (!bprm->file->f_op->mmap||((fd_offset & ~PAGE_MASK) != 0)) { loff_t pos = fd_offset; - do_brk(N_TXTADDR(ex), ex.a_text+ex.a_data); + do_brk_locked(N_TXTADDR(ex), ex.a_text+ex.a_data); bprm->file->f_op->read(bprm->file, (char __user *)N_TXTADDR(ex), ex.a_text+ex.a_data, &pos); @@ -488,7 +488,7 @@ error_time = jiffies; } - do_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss); + do_brk_locked(start_addr, ex.a_text + ex.a_data + ex.a_bss); file->f_op->read(file, (char __user *)start_addr, ex.a_text + ex.a_data, &pos); @@ -512,7 +512,7 @@ len = PAGE_ALIGN(ex.a_text + ex.a_data); bss = ex.a_text + ex.a_data + ex.a_bss; if (bss > len) { - error = do_brk(start_addr + len, bss - len); + error = do_brk_locked(start_addr + len, bss - len); retval = error; if (error != start_addr + len) goto out; diff -Nur linux-2.6.10.orig/fs/binfmt_elf.c linux-2.6.10/fs/binfmt_elf.c --- linux-2.6.10.orig/fs/binfmt_elf.c 2005-01-03 16:17:07.000000000 -0200 +++ linux-2.6.10/fs/binfmt_elf.c 2005-01-03 16:43:03.265876992 -0200 @@ -88,7 +88,7 @@ start = ELF_PAGEALIGN(start); end = ELF_PAGEALIGN(end); if (end > start) { - unsigned long addr = do_brk(start, end - start); + unsigned long addr = do_brk_locked(start, end - start); if (BAD_ADDR(addr)) return addr; } @@ -408,7 +408,7 @@ /* Map the last of the bss segment */ if (last_bss > elf_bss) { - error = do_brk(elf_bss, last_bss - elf_bss); + error = do_brk_locked(elf_bss, last_bss - elf_bss); if (BAD_ADDR(error)) goto out_close; } @@ -448,7 +448,7 @@ goto out; } - do_brk(0, text_data); + do_brk_locked(0, text_data); if (!interpreter->f_op || !interpreter->f_op->read) goto out; if (interpreter->f_op->read(interpreter, addr, text_data, &offset) < 0) @@ -456,7 +456,7 @@ flush_icache_range((unsigned long)addr, (unsigned long)addr + text_data); - do_brk(ELF_PAGESTART(text_data + ELF_MIN_ALIGN - 1), + do_brk_locked(ELF_PAGESTART(text_data + ELF_MIN_ALIGN - 1), interp_ex->a_bss); elf_entry = interp_ex->a_entry; @@ -1025,7 +1025,7 @@ len = ELF_PAGESTART(elf_phdata->p_filesz + elf_phdata->p_vaddr + ELF_MIN_ALIGN - 1); bss = elf_phdata->p_memsz + elf_phdata->p_vaddr; if (bss > len) - do_brk(len, bss - len); + do_brk_locked(len, bss - len); error = 0; out_free_ph: diff -Nur linux-2.6.10.orig/include/linux/mm.h linux-2.6.10/include/linux/mm.h --- linux-2.6.10.orig/include/linux/mm.h 2005-01-03 16:17:05.000000000 -0200 +++ linux-2.6.10/include/linux/mm.h 2005-01-03 16:51:55.686936688 -0200 @@ -751,6 +751,7 @@ extern int do_munmap(struct mm_struct *, unsigned long, size_t); extern unsigned long do_brk(unsigned long, unsigned long); +extern unsigned long do_brk_locked(unsigned long, unsigned long); /* filemap.c */ extern unsigned long page_unuse(struct page *); diff -Nur linux-2.6.10.orig/mm/mmap.c linux-2.6.10/mm/mmap.c --- linux-2.6.10.orig/mm/mmap.c 2005-01-03 16:17:07.000000000 -0200 +++ linux-2.6.10/mm/mmap.c 2005-01-03 16:51:17.000000000 -0200 @@ -1859,6 +1859,20 @@ EXPORT_SYMBOL(do_brk); +/* locking version of do_brk. */ +unsigned long do_brk_locked(unsigned long addr, unsigned long len) +{ + unsigned long ret; + + down_write(¤t->mm->mmap_sem); + ret = do_brk(addr, len); + up_write(¤t->mm->mmap_sem); + + return ret; +} + +EXPORT_SYMBOL(do_brk_locked); + /* Release all mmaps. */ void exit_mmap(struct mm_struct *mm) { diff -Nur linux-2.6.10.orig/mm/nommu.c linux-2.6.10/mm/nommu.c --- linux-2.6.10.orig/mm/nommu.c 2005-01-03 16:17:07.000000000 -0200 +++ linux-2.6.10/mm/nommu.c 2005-01-03 16:52:31.000000000 -0200 @@ -857,6 +857,11 @@ return -ENOMEM; } +unsigned long do_brk_locked(unsigned long addr, unsigned long len) +{ + return -ENOMEM; +} + /* * Expand (or shrink) an existing mapping, potentially moving it at the * same time (controlled by the MREMAP_MAYMOVE flag and available VM space) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-07 17:07 ` Marcelo Tosatti @ 2005-01-07 20:27 ` linux-os 2005-01-07 22:29 ` Athanasius 2005-01-07 22:49 ` Alan Cox 1 sibling, 1 reply; 42+ messages in thread From: linux-os @ 2005-01-07 20:27 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: Lukasz Trabinski, Linux kernel 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\r 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\r 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-07 20:27 ` linux-os @ 2005-01-07 22:29 ` Athanasius 0 siblings, 0 replies; 42+ messages in thread From: Athanasius @ 2005-01-07 22:29 UTC (permalink / raw) To: linux-os, linux-kernel; +Cc: Marcelo Tosatti, Lukasz Trabinski [-- Attachment #1: Type: text/plain, Size: 2370 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-07 17:07 ` Marcelo Tosatti 2005-01-07 20:27 ` linux-os @ 2005-01-07 22:49 ` Alan Cox 2005-01-08 0:15 ` Linus Torvalds 1 sibling, 1 reply; 42+ messages in thread From: Alan Cox @ 2005-01-07 22:49 UTC (permalink / raw) To: Marcelo Tosatti, torvalds; +Cc: Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-07 22:49 ` Alan Cox @ 2005-01-08 0:15 ` Linus Torvalds 2005-01-07 22:12 ` Marcelo Tosatti 0 siblings, 1 reply; 42+ messages in thread From: Linus Torvalds @ 2005-01-08 0:15 UTC (permalink / raw) To: Alan Cox; +Cc: Marcelo Tosatti, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 0:15 ` Linus Torvalds @ 2005-01-07 22:12 ` Marcelo Tosatti 2005-01-08 18:46 ` Linus Torvalds 0 siblings, 1 reply; 42+ messages in thread From: Marcelo Tosatti @ 2005-01-07 22:12 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-07 22:12 ` Marcelo Tosatti @ 2005-01-08 18:46 ` Linus Torvalds 2005-01-08 18:28 ` Marcelo Tosatti ` (3 more replies) 0 siblings, 4 replies; 42+ messages in thread From: Linus Torvalds @ 2005-01-08 18:46 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 18:46 ` Linus Torvalds @ 2005-01-08 18:28 ` Marcelo Tosatti 2005-01-09 1:38 ` Linus Torvalds 2005-01-08 21:07 ` Andreas Schwab ` (2 subsequent siblings) 3 siblings, 1 reply; 42+ messages in thread From: Marcelo Tosatti @ 2005-01-08 18:28 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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" ;). ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 18:28 ` Marcelo Tosatti @ 2005-01-09 1:38 ` Linus Torvalds 2005-01-09 11:06 ` Marcelo Tosatti 0 siblings, 1 reply; 42+ messages in thread From: Linus Torvalds @ 2005-01-09 1:38 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-09 1:38 ` Linus Torvalds @ 2005-01-09 11:06 ` Marcelo Tosatti 2005-01-10 8:34 ` Frank Steiner 0 siblings, 1 reply; 42+ messages in thread From: Marcelo Tosatti @ 2005-01-09 11:06 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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: ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-09 11:06 ` Marcelo Tosatti @ 2005-01-10 8:34 ` Frank Steiner 2005-01-10 16:51 ` Marcelo Tosatti 2005-01-10 18:28 ` Alan Cox 0 siblings, 2 replies; 42+ messages in thread From: Frank Steiner @ 2005-01-10 8:34 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: Linus Torvalds, Linux Kernel Mailing List 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/cset@1.2247.2.4 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. * ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-10 8:34 ` Frank Steiner @ 2005-01-10 16:51 ` Marcelo Tosatti 2005-01-10 18:28 ` Alan Cox 1 sibling, 0 replies; 42+ messages in thread From: Marcelo Tosatti @ 2005-01-10 16:51 UTC (permalink / raw) To: Frank Steiner; +Cc: Linus Torvalds, Linux Kernel Mailing List 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/cset@1.2247.2.4 > 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 :) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-10 8:34 ` Frank Steiner 2005-01-10 16:51 ` Marcelo Tosatti @ 2005-01-10 18:28 ` Alan Cox 2005-01-11 7:49 ` Frank Steiner 1 sibling, 1 reply; 42+ messages in thread From: Alan Cox @ 2005-01-10 18:28 UTC (permalink / raw) To: Frank Steiner; +Cc: Marcelo Tosatti, Linus Torvalds, Linux Kernel Mailing List 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/cset@1.2247.2.4 > 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)) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-10 18:28 ` Alan Cox @ 2005-01-11 7:49 ` Frank Steiner 0 siblings, 0 replies; 42+ messages in thread From: Frank Steiner @ 2005-01-11 7:49 UTC (permalink / raw) To: Alan Cox; +Cc: Marcelo Tosatti, Linus Torvalds, Linux Kernel Mailing List 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. * ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 18:46 ` Linus Torvalds 2005-01-08 18:28 ` Marcelo Tosatti @ 2005-01-08 21:07 ` Andreas Schwab 2005-01-08 22:30 ` Barry K. Nathan ` (2 more replies) 2005-01-08 21:47 ` Alan Cox 2005-01-11 22:51 ` [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) Barry K. Nathan 3 siblings, 3 replies; 42+ messages in thread From: Andreas Schwab @ 2005-01-08 21:07 UTC (permalink / raw) To: Linus Torvalds Cc: Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List Linus Torvalds <torvalds@osdl.org> 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, schwab@suse.de 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." ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 21:07 ` Andreas Schwab @ 2005-01-08 22:30 ` Barry K. Nathan 2005-01-08 23:21 ` Andi Kleen 2005-01-09 0:49 ` Andries Brouwer 2 siblings, 0 replies; 42+ messages in thread From: Barry K. Nathan @ 2005-01-08 22:30 UTC (permalink / raw) To: Andreas Schwab Cc: Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 <barryn@pobox.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 21:07 ` Andreas Schwab 2005-01-08 22:30 ` Barry K. Nathan @ 2005-01-08 23:21 ` Andi Kleen 2005-01-08 23:30 ` Alan Cox 2005-01-09 0:49 ` Andries Brouwer 2 siblings, 1 reply; 42+ messages in thread From: Andi Kleen @ 2005-01-08 23:21 UTC (permalink / raw) To: Andreas Schwab Cc: Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List Andreas Schwab <schwab@suse.de> writes: > Linus Torvalds <torvalds@osdl.org> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 23:21 ` Andi Kleen @ 2005-01-08 23:30 ` Alan Cox 2005-01-09 0:57 ` Andi Kleen 0 siblings, 1 reply; 42+ messages in thread From: Alan Cox @ 2005-01-08 23:30 UTC (permalink / raw) To: Andi Kleen Cc: Andreas Schwab, Marcelo Tosatti, Lukasz Trabinski, Linux Kernel Mailing List 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) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 23:30 ` Alan Cox @ 2005-01-09 0:57 ` Andi Kleen 0 siblings, 0 replies; 42+ messages in thread From: Andi Kleen @ 2005-01-09 0:57 UTC (permalink / raw) To: Alan Cox Cc: Andreas Schwab, Marcelo Tosatti, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 21:07 ` Andreas Schwab 2005-01-08 22:30 ` Barry K. Nathan 2005-01-08 23:21 ` Andi Kleen @ 2005-01-09 0:49 ` Andries Brouwer 2005-01-09 2:21 ` Jesper Juhl 2 siblings, 1 reply; 42+ messages in thread From: Andries Brouwer @ 2005-01-09 0:49 UTC (permalink / raw) To: Andreas Schwab Cc: Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List On Sat, Jan 08, 2005 at 10:07:10PM +0100, Andreas Schwab wrote: > Linus Torvalds <torvalds@osdl.org> 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 (-> aeb@cwi.nl). 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) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-09 0:49 ` Andries Brouwer @ 2005-01-09 2:21 ` Jesper Juhl 2005-01-09 2:17 ` Andries Brouwer 0 siblings, 1 reply; 42+ messages in thread From: Jesper Juhl @ 2005-01-09 2:21 UTC (permalink / raw) To: Andries Brouwer Cc: Andreas Schwab, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List On Sun, 9 Jan 2005, Andries Brouwer wrote: > On Sat, Jan 08, 2005 at 10:07:10PM +0100, Andreas Schwab wrote: > > Linus Torvalds <torvalds@osdl.org> 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 (-> aeb@cwi.nl). > > 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-09 2:21 ` Jesper Juhl @ 2005-01-09 2:17 ` Andries Brouwer 0 siblings, 0 replies; 42+ messages in thread From: Andries Brouwer @ 2005-01-09 2:17 UTC (permalink / raw) To: Jesper Juhl Cc: Andries Brouwer, Andreas Schwab, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: uselib() & 2.6.X? 2005-01-08 18:46 ` Linus Torvalds 2005-01-08 18:28 ` Marcelo Tosatti 2005-01-08 21:07 ` Andreas Schwab @ 2005-01-08 21:47 ` Alan Cox 2005-01-11 22:51 ` [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) Barry K. Nathan 3 siblings, 0 replies; 42+ messages in thread From: Alan Cox @ 2005-01-08 21:47 UTC (permalink / raw) To: Linus Torvalds Cc: Marcelo Tosatti, Lukasz Trabinski, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-08 18:46 ` Linus Torvalds ` (2 preceding siblings ...) 2005-01-08 21:47 ` Alan Cox @ 2005-01-11 22:51 ` Barry K. Nathan 2005-01-11 23:42 ` Jesper Juhl 2005-01-11 23:59 ` Andries Brouwer 3 siblings, 2 replies; 42+ messages in thread From: Barry K. Nathan @ 2005-01-11 22:51 UTC (permalink / raw) To: Linus Torvalds Cc: Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 <barryn@pobox.com> 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) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-11 22:51 ` [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) Barry K. Nathan @ 2005-01-11 23:42 ` Jesper Juhl 2005-01-11 23:59 ` Andries Brouwer 1 sibling, 0 replies; 42+ messages in thread From: Jesper Juhl @ 2005-01-11 23:42 UTC (permalink / raw) To: Barry K. Nathan Cc: Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-11 22:51 ` [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) Barry K. Nathan 2005-01-11 23:42 ` Jesper Juhl @ 2005-01-11 23:59 ` Andries Brouwer 2005-01-12 1:06 ` Jesper Juhl ` (2 more replies) 1 sibling, 3 replies; 42+ messages in thread From: Andries Brouwer @ 2005-01-11 23:59 UTC (permalink / raw) To: Barry K. Nathan Cc: Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-11 23:59 ` Andries Brouwer @ 2005-01-12 1:06 ` Jesper Juhl 2005-01-12 1:18 ` David Lang 2005-01-12 2:12 ` Barry K. Nathan 2005-01-12 7:58 ` Christoph Hellwig 2 siblings, 1 reply; 42+ messages in thread From: Jesper Juhl @ 2005-01-12 1:06 UTC (permalink / raw) To: Andries Brouwer Cc: Barry K. Nathan, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 1:06 ` Jesper Juhl @ 2005-01-12 1:18 ` David Lang 2005-01-11 22:36 ` Marcelo Tosatti 0 siblings, 1 reply; 42+ messages in thread From: David Lang @ 2005-01-12 1:18 UTC (permalink / raw) To: Jesper Juhl Cc: Andries Brouwer, Barry K. Nathan, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 1:18 ` David Lang @ 2005-01-11 22:36 ` Marcelo Tosatti 2005-01-12 2:32 ` Barry K. Nathan 2005-01-12 20:16 ` Matt Mackall 0 siblings, 2 replies; 42+ messages in thread From: Marcelo Tosatti @ 2005-01-11 22:36 UTC (permalink / raw) To: David Lang Cc: Jesper Juhl, Andries Brouwer, Barry K. Nathan, Linus Torvalds, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-11 22:36 ` Marcelo Tosatti @ 2005-01-12 2:32 ` Barry K. Nathan 2005-01-12 0:56 ` Marcelo Tosatti 2005-01-12 20:16 ` Matt Mackall 1 sibling, 1 reply; 42+ messages in thread From: Barry K. Nathan @ 2005-01-12 2:32 UTC (permalink / raw) To: Marcelo Tosatti Cc: David Lang, Jesper Juhl, Andries Brouwer, Barry K. Nathan, Linus Torvalds, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 <barryn@pobox.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 2:32 ` Barry K. Nathan @ 2005-01-12 0:56 ` Marcelo Tosatti 2005-01-12 6:10 ` Barry K. Nathan 0 siblings, 1 reply; 42+ messages in thread From: Marcelo Tosatti @ 2005-01-12 0:56 UTC (permalink / raw) To: Barry K. Nathan Cc: David Lang, Jesper Juhl, Andries Brouwer, Linus Torvalds, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 0:56 ` Marcelo Tosatti @ 2005-01-12 6:10 ` Barry K. Nathan 2005-01-12 16:47 ` Adrian Bunk 0 siblings, 1 reply; 42+ messages in thread From: Barry K. Nathan @ 2005-01-12 6:10 UTC (permalink / raw) To: Marcelo Tosatti Cc: Barry K. Nathan, David Lang, Jesper Juhl, Andries Brouwer, Linus Torvalds, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 <barryn@pobox.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 6:10 ` Barry K. Nathan @ 2005-01-12 16:47 ` Adrian Bunk 2005-01-12 17:10 ` Barry K. Nathan 0 siblings, 1 reply; 42+ messages in thread From: Adrian Bunk @ 2005-01-12 16:47 UTC (permalink / raw) To: Barry K. Nathan Cc: Marcelo Tosatti, David Lang, Jesper Juhl, Andries Brouwer, Linus Torvalds, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 <barryn@pobox.com> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 16:47 ` Adrian Bunk @ 2005-01-12 17:10 ` Barry K. Nathan 0 siblings, 0 replies; 42+ messages in thread From: Barry K. Nathan @ 2005-01-12 17:10 UTC (permalink / raw) To: Adrian Bunk Cc: Barry K. Nathan, Marcelo Tosatti, David Lang, Jesper Juhl, Andries Brouwer, Linus Torvalds, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 <barryn@pobox.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-11 22:36 ` Marcelo Tosatti 2005-01-12 2:32 ` Barry K. Nathan @ 2005-01-12 20:16 ` Matt Mackall 1 sibling, 0 replies; 42+ messages in thread From: Matt Mackall @ 2005-01-12 20:16 UTC (permalink / raw) To: Marcelo Tosatti Cc: David Lang, Jesper Juhl, Andries Brouwer, Barry K. Nathan, Linus Torvalds, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-11 23:59 ` Andries Brouwer 2005-01-12 1:06 ` Jesper Juhl @ 2005-01-12 2:12 ` Barry K. Nathan 2005-01-12 2:23 ` David Lang ` (2 more replies) 2005-01-12 7:58 ` Christoph Hellwig 2 siblings, 3 replies; 42+ messages in thread From: Barry K. Nathan @ 2005-01-12 2:12 UTC (permalink / raw) To: Andries Brouwer Cc: Barry K. Nathan, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 <barryn@pobox.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 2:12 ` Barry K. Nathan @ 2005-01-12 2:23 ` David Lang 2005-01-12 2:30 ` Adrian Bunk 2005-01-12 5:11 ` Stephen Pollei 2 siblings, 0 replies; 42+ messages in thread From: David Lang @ 2005-01-12 2:23 UTC (permalink / raw) To: Barry K. Nathan Cc: Andries Brouwer, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 2:12 ` Barry K. Nathan 2005-01-12 2:23 ` David Lang @ 2005-01-12 2:30 ` Adrian Bunk 2005-01-12 5:11 ` Stephen Pollei 2 siblings, 0 replies; 42+ messages in thread From: Adrian Bunk @ 2005-01-12 2:30 UTC (permalink / raw) To: Barry K. Nathan Cc: Andries Brouwer, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 <barryn@pobox.com> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 2:12 ` Barry K. Nathan 2005-01-12 2:23 ` David Lang 2005-01-12 2:30 ` Adrian Bunk @ 2005-01-12 5:11 ` Stephen Pollei 2005-01-12 16:54 ` Adrian Bunk 2 siblings, 1 reply; 42+ messages in thread From: Stephen Pollei @ 2005-01-12 5:11 UTC (permalink / raw) To: Barry K. Nathan Cc: Andries Brouwer, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1373 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-12 5:11 ` Stephen Pollei @ 2005-01-12 16:54 ` Adrian Bunk 0 siblings, 0 replies; 42+ messages in thread From: Adrian Bunk @ 2005-01-12 16:54 UTC (permalink / raw) To: Stephen Pollei Cc: Barry K. Nathan, Andries Brouwer, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) 2005-01-11 23:59 ` Andries Brouwer 2005-01-12 1:06 ` Jesper Juhl 2005-01-12 2:12 ` Barry K. Nathan @ 2005-01-12 7:58 ` Christoph Hellwig 2 siblings, 0 replies; 42+ messages in thread From: Christoph Hellwig @ 2005-01-12 7:58 UTC (permalink / raw) To: Andries Brouwer Cc: Barry K. Nathan, Linus Torvalds, Marcelo Tosatti, Alan Cox, Lukasz Trabinski, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2005-01-12 20:25 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-07 15:59 uselib() & 2.6.X? Lukasz Trabinski 2005-01-07 17:07 ` Marcelo Tosatti 2005-01-07 20:27 ` linux-os 2005-01-07 22:29 ` Athanasius 2005-01-07 22:49 ` Alan Cox 2005-01-08 0:15 ` Linus Torvalds 2005-01-07 22:12 ` Marcelo Tosatti 2005-01-08 18:46 ` Linus Torvalds 2005-01-08 18:28 ` Marcelo Tosatti 2005-01-09 1:38 ` Linus Torvalds 2005-01-09 11:06 ` Marcelo Tosatti 2005-01-10 8:34 ` Frank Steiner 2005-01-10 16:51 ` Marcelo Tosatti 2005-01-10 18:28 ` Alan Cox 2005-01-11 7:49 ` Frank Steiner 2005-01-08 21:07 ` Andreas Schwab 2005-01-08 22:30 ` Barry K. Nathan 2005-01-08 23:21 ` Andi Kleen 2005-01-08 23:30 ` Alan Cox 2005-01-09 0:57 ` Andi Kleen 2005-01-09 0:49 ` Andries Brouwer 2005-01-09 2:21 ` Jesper Juhl 2005-01-09 2:17 ` Andries Brouwer 2005-01-08 21:47 ` Alan Cox 2005-01-11 22:51 ` [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?) Barry K. Nathan 2005-01-11 23:42 ` Jesper Juhl 2005-01-11 23:59 ` Andries Brouwer 2005-01-12 1:06 ` Jesper Juhl 2005-01-12 1:18 ` David Lang 2005-01-11 22:36 ` Marcelo Tosatti 2005-01-12 2:32 ` Barry K. Nathan 2005-01-12 0:56 ` Marcelo Tosatti 2005-01-12 6:10 ` Barry K. Nathan 2005-01-12 16:47 ` Adrian Bunk 2005-01-12 17:10 ` Barry K. Nathan 2005-01-12 20:16 ` Matt Mackall 2005-01-12 2:12 ` Barry K. Nathan 2005-01-12 2:23 ` David Lang 2005-01-12 2:30 ` Adrian Bunk 2005-01-12 5:11 ` Stephen Pollei 2005-01-12 16:54 ` Adrian Bunk 2005-01-12 7:58 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).