Why is my nasm program killing itself?
in [ASM]
|
Prev: Sudoku
Next: Linux distro request
From: Chuck Crayne on 4 Apr 2008 19:11 On Fri, 04 Apr 2008 20:51:55 GMT Frank Kotler <fbkotler(a)verizon.net> wrote: > That's what it sounds like to me... Looking at 2.6.23.9, I see: Pack-rat that I am, I found this snippet in my archives, which I believe was from the kernel version just before the bug was introduced. if (clear_user((void __user *)elf_bss + load_bias, nbyte)) { /* * This bss-zeroing can fail if the ELF * file specifies odd protections. So * we don't check the return value */ The problem started when (in the name of security) someone ignored this warning, and changed the code to check the return value. Of course, that doesn't mean that some other call isn't the culprit this time. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Frank Kotler on 4 Apr 2008 20:35 Chuck Crayne wrote: > On Fri, 04 Apr 2008 20:51:55 GMT > Frank Kotler <fbkotler(a)verizon.net> wrote: > > >>That's what it sounds like to me... Looking at 2.6.23.9, I see: > > > Pack-rat that I am, I found this snippet in my archives, which I > believe was from the kernel version just before the bug was introduced. > > if (clear_user((void __user *)elf_bss + > load_bias, nbyte)) { > /* > * This bss-zeroing can fail if the ELF > * file specifies odd protections. So > * we don't check the return value > */ > > The problem started when (in the name of security) someone ignored > this warning, and changed the code to check the return value. > > Of course, that doesn't mean that some other call isn't the culprit > this time. > I should have quoted a little more... That call, unchecked, is still in there... if (unlikely (elf_brk > elf_bss)) { unsigned long nbyte; /* There was a PT_LOAD segment with p_memsz > p_filesz before this one. Map anonymous pages, if needed, and clear the area. */ retval = set_brk (elf_bss + load_bias, elf_brk + load_bias); if (retval) { send_sig(SIGKILL, current, 0); goto out_free_dentry; } nbyte = ELF_PAGEOFFSET(elf_bss); if (nbyte) { nbyte = ELF_MIN_ALIGN - nbyte; if (nbyte > elf_brk - elf_bss) nbyte = elf_brk - elf_bss; if (clear_user((void __user *)elf_bss + load_bias, nbyte)) { /* * This bss-zeroing can fail if the ELF * file specifies odd protections. So * we don't check the return value */ } } } .... which is why I guessed we might be failing before getting there. I can't see why "set_brk" should fail, though... #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE) static int set_brk(unsigned long start, unsigned long end) { start = ELF_PAGEALIGN(start); end = ELF_PAGEALIGN(end); if (end > start) { unsigned long addr; down_write(¤t->mm->mmap_sem); addr = do_brk(start, end - start); up_write(¤t->mm->mmap_sem); if (BAD_ADDR(addr)) return addr; } current->mm->start_brk = current->mm->brk = end; return 0; } .... and we're still not checking the return from "clear_user"... That's funny, 'cause I remember that the "must have a writeable section last" problem was from changing (pre 2.6.10?) code so it *did* check that return value. IIRC, we were doing it to ".text" if that's all there was, in that case... I can only tolerate this easy-to-read C in small doses - we oughtta make Herbert look at it! :) I have to be careful. You saw what happened to Konstantin! Got started poking around the kernel, and now he's looking for a new maintainer for the linuxassembly site! Best, Frank
From: Chuck Crayne on 5 Apr 2008 00:38 On Sat, 05 Apr 2008 00:35:30 GMT Frank Kotler <fbkotler(a)verizon.net> wrote: > ... and we're still not checking the return from "clear_user"... > That's funny, 'cause I remember that the "must have a writeable > section last" problem was from changing (pre 2.6.10?) code so it > *did* check that return value. IIRC, we were doing it to ".text" if > that's all there was, in that case... That is my recollection as well. The issue with ".text" was that the loader's definition of bss did not require an actual ".bss" section, but assumed that everything after the last section until the end of the page was an undeclared ".bss" section. > I have to be careful. You saw what happened to Konstantin! Got > started poking around the kernel, and now he's looking for a new > maintainer for the linuxassembly site! Yes, this is a clear and present danger. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Herbert Kleebauer on 5 Apr 2008 13:33 Frank Kotler wrote: > There are a number of places where we could be killed... this one > attracts me because it appears to involve ".bss". Haven't chased down > what "unlikely" does, nor "set_brk". The latter presumably zeros the > page(?)... I don't know if that's the right "kill", or what the > workaround is for Ivan to avoid it... besides eliminating .bss > altogether, or upgrading the kernel. > > I noticed another one I'm "suspicious" of, in "the other weirdness": I think it's very unlikely that this is a kernel problem. NASM is the standard assembler for LINUX (for the assembly programmer, not for the C programmer). And I can't believe that there are three kernel versions > Frank, I've tried that source on several machines and it gets killed > on both of them. These include kernel versions: > 2.6.23.9 > 2.6.21.5 > 2.6.12.4 which have this problem (and the OP uses exactly this three versions). If this would be true and nobody else had this problem, then assembly programming really would be dead. That's so unlikely, that it's even more probably that it is a virus which has problems to infect such small programs. Okaay, what is wrong with that: mov al, 10 This gets the program (another one) killed. If I change it into this: mov ax, 10 it is working! It doesn't make much sense to speculate about the reason for this problem as long as the OP doesn't post his binary for the "mov al, 10" and the "mov ax, 10" version. I already asked him for the binary but there was no reply. > "out:" just returns ret_val. Possibly why this kernel's giving "can't > execute binary file" for "Herbert's version"??? This header is in accordance with the elf specification and should be executable on any kernel version which supports elf binaries. The last section is also writeable (even if it's size can be zero), so also the kernels versions which don't like programs with only readonly sections shouldn't have any problem.
From: Chuck Crayne on 5 Apr 2008 20:35
On Sun, 06 Apr 2008 00:14:18 GMT Frank Kotler <fbkotler(a)verizon.net> wrote: > When/if I find "likely()" and or "unlikely()", I'll run the > idea through 'em. :) "likely" and "unlikely" are not functions, but branch prediction macros to give hints to the compiler. From the standpoint of figuring out what the code is trying to do, they can be (and should be) ignored. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html |