binfmt_elf padzero problems
hello. i am seeing a problem(?) with the patch described at: http://marc.theaimsgroup.com/?l=linux-kernel=109865760703851=2 i'm using vanilla 2.6.11 (not .1/.2/.3/.4 ...) the short version: padzero does not alway do the right thing (more correctly, it's caller, load_elf_binary). the longer version: padzero calls clear_user. clear_user first checks if the address passed is writable. if it is not, an error is returned. the problem manifest itself when the area being cleared is not writable... this should not normally happen in the context of load_elf_binary, however it _can_ happen with the following assembly code (intel syntax): section .text global _start _start: mov eax,0x1 mov ebx,0x0 int 0x80 hlt assembled with nasm -f elf, produces a binary with a bss segment of zero size, aligned to 1, and one program header. now, the when calling padzero, elf_bss holds an address which belongs to .text (since no (fake)program header for .bss wad created), i.e; not writable when padzero is called, it tries to clean the rest of the .text section, which clearly results with an error. thus, my (very) small binary always segfaults under 2.6.11+ on the other hand, i can be dead wrong.. if so, id like to know why... p.s. please cc me, im not subscribed, -- = Nir Tzachar. signature.asc Description: This is a digitally signed message part
binfmt_elf padzero problems
hello. i am seeing a problem(?) with the patch described at: http://marc.theaimsgroup.com/?l=linux-kernelm=109865760703851w=2 i'm using vanilla 2.6.11 (not .1/.2/.3/.4 ...) the short version: padzero does not alway do the right thing (more correctly, it's caller, load_elf_binary). the longer version: padzero calls clear_user. clear_user first checks if the address passed is writable. if it is not, an error is returned. the problem manifest itself when the area being cleared is not writable... this should not normally happen in the context of load_elf_binary, however it _can_ happen with the following assembly code (intel syntax): section .text global _start _start: mov eax,0x1 mov ebx,0x0 int 0x80 hlt assembled with nasm -f elf, produces a binary with a bss segment of zero size, aligned to 1, and one program header. now, the when calling padzero, elf_bss holds an address which belongs to .text (since no (fake)program header for .bss wad created), i.e; not writable when padzero is called, it tries to clean the rest of the .text section, which clearly results with an error. thus, my (very) small binary always segfaults under 2.6.11+ on the other hand, i can be dead wrong.. if so, id like to know why... p.s. please cc me, im not subscribed, -- = Nir Tzachar. signature.asc Description: This is a digitally signed message part