From: Nir Tzachar <tzachar@cs.bgu.ac.il>
To: linux-kernel@vger.kernel.org
Cc: juhl-lkml@dif.dk, akpm@osdl.org
Subject: binfmt_elf padzero problems
Date: Thu, 17 Mar 2005 21:10:09 +0200 [thread overview]
Message-ID: <1111086609.12193.27.camel@nexus.cs.bgu.ac.il> (raw)
[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]
hello.
i am seeing a problem(?) with the patch described at:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109865760703851&w=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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2005-03-17 19:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-17 19:10 Nir Tzachar [this message]
2005-03-17 22:49 ` Andrew Morton
2005-03-18 2:47 ` Paul Mackerras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1111086609.12193.27.camel@nexus.cs.bgu.ac.il \
--to=tzachar@cs.bgu.ac.il \
--cc=akpm@osdl.org \
--cc=juhl-lkml@dif.dk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®