Re: [PATCH] Longstanding elf fix (2.4.3 fix)
Ion Badulescu <[EMAIL PROTECTED]> writes: > On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > > I'll include it again. I had it attached as a plain text attachment, > > I don't know if that is a problem or not. > > Actually it was attached as text/x-patch, not as text/plain... so > pine certainly refused to display it inline. Interesting I'll have to play with that some time. I really think for basic display it should only care about the text part. But oh well. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > I'll include it again. I had it attached as a plain text attachment, > I don't know if that is a problem or not. Actually it was attached as text/x-patch, not as text/plain... so pine certainly refused to display it inline. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
"Manfred Spraul" <[EMAIL PROTECTED]> writes: > > Well looking a little more closely than I did last night it looks like > > access_process_vm (called from ptrace) can cause what amounts to a > > page fault at pretty arbitrary times. > > It's also used for several /proc/ files. > > I remember that I got crashes with concurrent exec+cat > /proc//cmdline until down(mmap_sem) was added into > setup_arg_pages(). O.k. Then the race I'm catching is real though because it is confined to bss sections, we are quite unlikely to trigger it. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
> Well looking a little more closely than I did last night it looks like > access_process_vm (called from ptrace) can cause what amounts to a > page fault at pretty arbitrary times. It's also used for several /proc/ files. I remember that I got crashes with concurrent exec+cat /proc//cmdline until down(mmap_sem) was added into setup_arg_pages(). > I'm actually a little curious what the big kernel lock in ptrace buys > us. I suspect it could be a performance issue with user mode linux. > Where you have multiple processes being ptraced at the same time. I checked it a few months ago, and the lock is only required to prevent multiple concurrent attaches to the same process and concorrent ptrace/suid exec (in fs/exec.c, compute_creds) -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
Linus Torvalds <[EMAIL PROTECTED]> writes: > On 23 Apr 2001, Eric W. Biederman wrote: > > > > ptrace is protected by the big kernel lock, but exec isn't so that > > doesn't help. Hmm. ptrace does require that the process be stopped > > in all cases > > Right. Ptrace definitely cannot access a process at "arbitrary" times. In > fact, it is very serialized indeed, in that it can only access a process > at "signal points", ie effectively when it is returning to user space. > > With threads, of course, that doesn't help us. But with threads, the other > threads could have caused the same page faults, so ptrace() isn't actually > adding any "new" cases in that sense. > > I'd be a lot more worried about /proc accesses. access_process_vm is also called from /proc to get the environment and the command line. I don't know if it has other locks it might serialize on, probably not. With execve it's a very small window... > execve() doesn't really need the mm semaphore, but on the other hand it > would be cleaner to get it, and it won't really hurt (there can not be any > real contention on it anyway - the only contention might come through > /proc, and I haven't looked at what that might imply). > > load-library should definitely get it. I thought it did already, but.. > > Did you have a patch? Maybe I missed it. I'll include it again. I had it attached as a plain text attachment, I don't know if that is a problem or not. The case I spotted it we were getting the mm semaphore for do_mmap but not for do_brk. So we only get it 50% of the time... The other thing my patch does is update elf_map so we now handles elf files with multiple bss sections. Eric diff -uNrX linux-exclude-files linux-2.4.3/arch/mips/kernel/irixelf.c linux-2.4.3.elf-fix2/arch/mips/kernel/irixelf.c --- linux-2.4.3/arch/mips/kernel/irixelf.c Fri Apr 20 12:06:40 2001 +++ linux-2.4.3.elf-fix2/arch/mips/kernel/irixelf.c Sun Apr 22 17:00:28 2001 @@ -130,7 +130,9 @@ end = PAGE_ALIGN(end); if (end <= start) return; + down_write(¤t->mm->mmap_sem); do_brk(start, end - start); + up_write(¤t->mm->mmap_sem); } @@ -379,7 +381,9 @@ /* Map the last of the bss segment */ if (last_bss > len) { + down_write(¤t->mm->mmap_sem); do_brk(len, (last_bss - len)); + up_write(¤t->mm->mmap_sem); } kfree(elf_phdata); @@ -567,8 +571,10 @@ unsigned long v; struct prda *pp; + down_write(¤t->mm->mmap_sem); v = do_brk (PRDA_ADDRESS, PAGE_SIZE); - + up_write(¤t->mm->mmap_sem); + if (v < 0) return; @@ -858,8 +864,11 @@ len = (elf_phdata->p_filesz + elf_phdata->p_vaddr+ 0xfff) & 0xf000; bss = elf_phdata->p_memsz + elf_phdata->p_vaddr; - if (bss > len) - do_brk(len, bss-len); + if (bss > len) { + down_write(¤t->mm->mmap_sem); + do_brk(len, bss-len); + up_write(¤t->mm->mmap_sem); + } kfree(elf_phdata); return 0; } diff -uNrX linux-exclude-files linux-2.4.3/arch/s390x/kernel/binfmt_elf32.c linux-2.4.3.elf-fix2/arch/s390x/kernel/binfmt_elf32.c --- linux-2.4.3/arch/s390x/kernel/binfmt_elf32.cFri Apr 20 12:06:43 2001 +++ linux-2.4.3.elf-fix2/arch/s390x/kernel/binfmt_elf32.c Sun Apr 22 17:00:28 +2001 @@ -188,16 +188,29 @@ static unsigned long elf_map32 (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int prot, int type) { + unsigned long start, data_len, mem_len, offset; unsigned long map_addr; if(!addr) addr = 0x4000; - down_write(¤t->mm->mmap_sem); - map_addr = do_mmap(filep, ELF_PAGESTART(addr), - eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr), prot, type, - eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr)); - up_write(¤t->mm->mmap_sem); + start = ELF_PAGESTART(addr); + data_len = ELF_PAGEALIGN(eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr)); + mem_len = ELF_PAGEALIGN(eppnt->p_memsz + ELF_PAGEOFFSET(eppnt->p_vaddr)); + offset = eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr); + + if (eppnt->p_filesz) { + down_write(¤t->mm->mmap_sem); + map_addr = do_mmap(filep, start, data_len, prot, type, offset); + do_mmap(NULL, map_addr + data_len, mem_len - data_len, prot, + MAP_FIXED | MAP_PRIVATE, 0); + up_write(¤t->mm->mmap_sem); + padzero(map_addr + eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr)); + } else { + down_write(¤t->mm->mmap_sem); + map_addr = do_mmap(NULL, start, mem_len, prot, MAP_PRIVATE, 0); + up_write(¤t->mm->mmap_sem); + } return(map_addr); } diff -uNrX linux-exclude-files linux-2.4.3/ar
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
On 23 Apr 2001, Eric W. Biederman wrote: > > ptrace is protected by the big kernel lock, but exec isn't so that > doesn't help. Hmm. ptrace does require that the process be stopped > in all cases Right. Ptrace definitely cannot access a process at "arbitrary" times. In fact, it is very serialized indeed, in that it can only access a process at "signal points", ie effectively when it is returning to user space. With threads, of course, that doesn't help us. But with threads, the other threads could have caused the same page faults, so ptrace() isn't actually adding any "new" cases in that sense. I'd be a lot more worried about /proc accesses. execve() doesn't really need the mm semaphore, but on the other hand it would be cleaner to get it, and it won't really hurt (there can not be any real contention on it anyway - the only contention might come through /proc, and I haven't looked at what that might imply). load-library should definitely get it. I thought it did already, but.. Did you have a patch? Maybe I missed it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
"David S. Miller" <[EMAIL PROTECTED]> writes: > Eric W. Biederman writes: > > In building a patch for 2.4.3 I also discovered that we are not taking > > the mmap_sem around do_brk in the exec paths. > > Does that really matter? Who else can get at the address space? We > are a singly referenced address space at that point... perhaps ptrace? Well looking a little more closely than I did last night it looks like access_process_vm (called from ptrace) can cause what amounts to a page fault at pretty arbitrary times. ptrace is protected by the big kernel lock, but exec isn't so that doesn't help. Hmm. ptrace does require that the process be stopped in all cases, before it does anything and that probably saves us. This is subtle enough I'd rather be locally correct, and not have to worry about someone enhancing ptrace... I'm actually a little curious what the big kernel lock in ptrace buys us. I suspect it could be a performance issue with user mode linux. Where you have multiple processes being ptraced at the same time. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
>And of course since much of the code in the kernel is built on the >copy a good example neglecting the locking without a big comment, >invites trouble elsewhere like in elf_load_library. Where we could >have multiple threads running. Out of interest: does anything, anywhere, actually use elf_load_library any more? p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
"David S. Miller" <[EMAIL PROTECTED]> writes: > Eric W. Biederman writes: > > In building a patch for 2.4.3 I also discovered that we are not taking > > the mmap_sem around do_brk in the exec paths. > > Does that really matter? In the library loader I can certainly see it making a difference. > Who else can get at the address space? > We are a singly referenced address space at that point... perhaps ptrace? In practice I don't see it being a big deal. But reliable code is made by closing all of the little loop holes. It also improves consistency as all of the calls to do_mmap are already protected in the exec paths. And of course since much of the code in the kernel is built on the copy a good example neglecting the locking without a big comment, invites trouble elsewhere like in elf_load_library. Where we could have multiple threads running. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
Eric W. Biederman writes: > In building a patch for 2.4.3 I also discovered that we are not taking > the mmap_sem around do_brk in the exec paths. Does that really matter? Who else can get at the address space? We are a singly referenced address space at that point... perhaps ptrace? Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Longstanding elf fix (2.4.3 fix)
A little while ago I was playing with building an elf self extracting binary. In doing so I discovered that the linux kernel does not handle elf program headers with multiple BSS segments. In building a patch for 2.4.3 I also discovered that we are not taking the mmap_sem around do_brk in the exec paths. Attached is a patch that corrects, both of these problems. Eric diff -uNrX linux-exclude-files linux-2.4.3/arch/mips/kernel/irixelf.c linux-2.4.3.elf-fix2/arch/mips/kernel/irixelf.c --- linux-2.4.3/arch/mips/kernel/irixelf.c Fri Apr 20 12:06:40 2001 +++ linux-2.4.3.elf-fix2/arch/mips/kernel/irixelf.c Sun Apr 22 17:00:28 2001 @@ -130,7 +130,9 @@ end = PAGE_ALIGN(end); if (end <= start) return; + down_write(¤t->mm->mmap_sem); do_brk(start, end - start); + up_write(¤t->mm->mmap_sem); } @@ -379,7 +381,9 @@ /* Map the last of the bss segment */ if (last_bss > len) { + down_write(¤t->mm->mmap_sem); do_brk(len, (last_bss - len)); + up_write(¤t->mm->mmap_sem); } kfree(elf_phdata); @@ -567,8 +571,10 @@ unsigned long v; struct prda *pp; + down_write(¤t->mm->mmap_sem); v = do_brk (PRDA_ADDRESS, PAGE_SIZE); - + up_write(¤t->mm->mmap_sem); + if (v < 0) return; @@ -858,8 +864,11 @@ len = (elf_phdata->p_filesz + elf_phdata->p_vaddr+ 0xfff) & 0xf000; bss = elf_phdata->p_memsz + elf_phdata->p_vaddr; - if (bss > len) - do_brk(len, bss-len); + if (bss > len) { + down_write(¤t->mm->mmap_sem); + do_brk(len, bss-len); + up_write(¤t->mm->mmap_sem); + } kfree(elf_phdata); return 0; } diff -uNrX linux-exclude-files linux-2.4.3/arch/s390x/kernel/binfmt_elf32.c linux-2.4.3.elf-fix2/arch/s390x/kernel/binfmt_elf32.c --- linux-2.4.3/arch/s390x/kernel/binfmt_elf32.c Fri Apr 20 12:06:43 2001 +++ linux-2.4.3.elf-fix2/arch/s390x/kernel/binfmt_elf32.c Sun Apr 22 17:00:28 2001 @@ -188,16 +188,29 @@ static unsigned long elf_map32 (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int prot, int type) { + unsigned long start, data_len, mem_len, offset; unsigned long map_addr; if(!addr) addr = 0x4000; - down_write(¤t->mm->mmap_sem); - map_addr = do_mmap(filep, ELF_PAGESTART(addr), - eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr), prot, type, - eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr)); - up_write(¤t->mm->mmap_sem); + start = ELF_PAGESTART(addr); + data_len = ELF_PAGEALIGN(eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr)); + mem_len = ELF_PAGEALIGN(eppnt->p_memsz + ELF_PAGEOFFSET(eppnt->p_vaddr)); + offset = eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr); + + if (eppnt->p_filesz) { + down_write(¤t->mm->mmap_sem); + map_addr = do_mmap(filep, start, data_len, prot, type, offset); + do_mmap(NULL, map_addr + data_len, mem_len - data_len, prot, + MAP_FIXED | MAP_PRIVATE, 0); + up_write(¤t->mm->mmap_sem); + padzero(map_addr + eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr)); + } else { + down_write(¤t->mm->mmap_sem); + map_addr = do_mmap(NULL, start, mem_len, prot, MAP_PRIVATE, 0); + up_write(¤t->mm->mmap_sem); + } return(map_addr); } diff -uNrX linux-exclude-files linux-2.4.3/arch/sparc64/kernel/binfmt_aout32.c linux-2.4.3.elf-fix2/arch/sparc64/kernel/binfmt_aout32.c --- linux-2.4.3/arch/sparc64/kernel/binfmt_aout32.c Fri Apr 20 12:06:44 2001 +++ linux-2.4.3.elf-fix2/arch/sparc64/kernel/binfmt_aout32.c Sun Apr 22 17:00:28 2001 @@ -49,7 +49,9 @@ end = PAGE_ALIGN(end); if (end <= start) return; + down_write(¤t->mm->mmap_sem); do_brk(start, end - start); + up_write(¤t->mm->mmap_sem); } /* @@ -245,10 +247,17 @@ if (N_MAGIC(ex) == NMAGIC) { loff_t pos = fd_offset; /* Fuck me plenty... */ + down_write(¤t->mm->mmap_sem); error = do_brk(N_TXTADDR(ex), ex.a_text); + up_write(¤t->mm->mmap_sem); + bprm->file->f_op->read(bprm->file, (char *) N_TXTADDR(ex), ex.a_text, &pos); + + down_write(¤t->mm->mmap_sem); error = do_brk(N_DATADDR(ex), ex.a_data); + up_write(¤t->mm->mmap_sem); + bprm->file->f_op->read(bprm->file, (char *) N_DATADDR(ex), ex.a_data, &pos); goto beyond_if; @@ -256,8 +265,10 @@ if (N_MAGIC(ex) == OMAGIC) { loff_t pos = fd_offset; + down_write(¤t->mm->mmap_sem); do_brk(N_TXTADDR(ex) & PAGE_MASK, ex.a_text+ex.a_data + PAGE_SIZE - 1); + up_write(¤t->mm->mmap_sem); bprm->file->f_op->read(bprm->file, (char *) N_TXTADDR(ex), ex.a_text+ex.a_data, &pos); } else { @@ -271,7 +282,9 @@ if (!bprm->file->f_op->mmap) { loff_t pos = fd_offset; + down_write(¤t->mm->mmap_sem); do_brk(0, ex.a_text+ex.a_data); + up_write(¤t->mm->mmap_sem); bprm->file->f_op->read(bprm->file,(char *)N_TXTADDR(ex), ex.a_text+ex.a_data, &pos); goto beyond_if; @@ -382,7 +395,9 @@ len = PAGE_ALIGN(ex.a_text + ex.a_data); bss = ex.a_text + ex.a_data + ex.a_bss; if (bss > len) { + down_write(¤t->mm->mmap_sem); error = do_brk(start_addr + len, bss - len); + up_write(¤t->mm->mmap_sem); retval = error; if (error != start_