uselib() & 2.6.X?

uselib() & 2.6.X?

[Lukasz Trabinski]

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 ]*

Re: uselib() & 2.6.X?

[Marcelo Tosatti]

[-- 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(&current->mm->mmap_sem);
+	ret = do_brk(addr, len);
+	up_write(&current->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)

Re: uselib() & 2.6.X?

[linux-os]

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.

Re: uselib() & 2.6.X?

[Athanasius]

[-- 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 --]

Re: uselib() & 2.6.X?

[Alan Cox]

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
 

Re: uselib() & 2.6.X?

[Linus Torvalds]

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

Re: uselib() & 2.6.X?

[Marcelo Tosatti]

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.

Re: uselib() & 2.6.X?

[Linus Torvalds]

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

Re: uselib() & 2.6.X?

[Marcelo Tosatti]

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" ;).

Re: uselib() & 2.6.X?

[Linus Torvalds]

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

Re: uselib() & 2.6.X?

[Marcelo Tosatti]

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:

Re: uselib() & 2.6.X?

[Frank Steiner]

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. *

Re: uselib() & 2.6.X?

[Marcelo Tosatti]

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 :)

Re: uselib() & 2.6.X?

[Alan Cox]

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))

Re: uselib() & 2.6.X?

[Frank Steiner]

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. *

Re: uselib() & 2.6.X?

[Andreas Schwab]

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."

Re: uselib() & 2.6.X?

[Barry K. Nathan]

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>

Re: uselib() & 2.6.X?

[Andi Kleen]

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

Re: uselib() & 2.6.X?

[Alan Cox]

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)

Re: uselib() & 2.6.X?

[Andi Kleen]

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

Re: uselib() & 2.6.X?

[Andries Brouwer]

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)

Re: uselib() & 2.6.X?

[Jesper Juhl]

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

Re: uselib() & 2.6.X?

[Andries Brouwer]

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

Re: uselib() & 2.6.X?

[Alan Cox]

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. 

[PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Barry K. Nathan]

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)

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Jesper Juhl]

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

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Andries Brouwer]

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

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[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

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[David Lang]

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

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Marcelo Tosatti]

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.

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Barry K. Nathan]

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>

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Marcelo Tosatti]

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?

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Barry K. Nathan]

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>

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Adrian Bunk]

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

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Barry K. Nathan]

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>

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Matt Mackall]

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.

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Barry K. Nathan]

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>

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[David Lang]

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

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Adrian Bunk]

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

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Stephen Pollei]

[-- 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 --]

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Adrian Bunk]

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

Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Christoph Hellwig]

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.