From: Arjan van de Ven <arjan@infradead.org>
To: Andi Kleen <ak@suse.de>
Cc: akpm@osdl.org, torvalds@osdl.org, mingo@elte.hu,
linux-kernel@vger.kernel.org, drepper@redhat.com
Subject: Re: [PROPOSAL/PATCH] Remove PT_GNU_STACK support before 2.6.11
Date: Sun, 6 Feb 2005 11:47:59 +0000 [thread overview]
Message-ID: <20050206114758.GA8437@infradead.org> (raw)
In-Reply-To: <20050206113635.GA30109@wotan.suse.de>
On Sun, Feb 06, 2005 at 12:36:35PM +0100, Andi Kleen wrote:
> PT_GNU_STACK assumes that any program with a PT_GNU_STACK header
> always pass correct PROT_EXEC flags to mmap/mprotect etc. before
> allocating mappings.
that is incorrect and was introduced later
> Worse is that even when the program has trampolines and has PT_GNU_STACK
> header with an E bit on the stack it still won't get an executable
> heap by default (this is what broke grub)
this I can fix easy, see the patch below
the problem is in the read_implies_exec() design, it passed in "does it have
a PT_GNU_STACK flag" not the value. Easy fix.
Your main objection is that *incorrect* programs that assume they can
execute malloc() code without PROT_EXEC protection. For legacy binaries
keeping this behavior makes sense, no objection from me.
For newly compiled programs this is just wrong and incorrect.
You mention grub (which has RWE and the patch below thus makes that work)
and mono. mono has patches for this on their mailinglist and bugzilla since
2003 according to google, I'm surprised the novell mono guys haven't fixed
this bug in their code.
FWIW all jvm's don't suffer from this. They are either legacy binaries or
mprotect properly (only i386 traditionally had this behavior, all others
already required PROT_EXEC anyway so any half portable app already did this,
as well as any app portable to BSD since they enforce this on x86 as well)
So I rather see the patch below merged instead; it fixes the worst problems
(RWE not marking the heap executable) while keeping this useful feature
enabled.
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
diff -purN linux-2.6.11-rc2-bk4/fs/binfmt_elf.c linux-foo/fs/binfmt_elf.c
--- linux-2.6.11-rc2-bk4/fs/binfmt_elf.c 2005-01-26 18:24:50.000000000 +0100
+++ linux-foo/fs/binfmt_elf.c 2005-02-06 12:29:02.000000000 +0100
@@ -757,7 +757,7 @@ static int load_elf_binary(struct linux_
/* Do this immediately, since STACK_TOP as used in setup_arg_pages
may depend on the personality. */
SET_PERSONALITY(loc->elf_ex, ibcs2_interpreter);
- if (elf_read_implies_exec(loc->elf_ex, have_pt_gnu_stack))
+ if (elf_read_implies_exec(loc->elf_ex, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
arch_pick_mmap_layout(current->mm);
diff -purN linux-2.6.11-rc2-bk4/include/asm-i386/elf.h linux-foo/include/asm-i386/elf.h
--- linux-2.6.11-rc2-bk4/include/asm-i386/elf.h 2004-12-24 22:35:15.000000000 +0100
+++ linux-foo/include/asm-i386/elf.h 2005-02-06 12:29:55.000000000 +0100
@@ -123,7 +123,7 @@ typedef struct user_fxsr_struct elf_fpxr
* An executable for which elf_read_implies_exec() returns TRUE will
* have the READ_IMPLIES_EXEC personality flag set automatically.
*/
-#define elf_read_implies_exec(ex, have_pt_gnu_stack) (!(have_pt_gnu_stack))
+#define elf_read_implies_exec(ex, executable_stack) (executable_stack != EXSTACK_DISABLE_X)
extern int dump_task_regs (struct task_struct *, elf_gregset_t *);
extern int dump_task_fpu (struct task_struct *, elf_fpregset_t *);
diff -purN linux-2.6.11-rc2-bk4/include/asm-ia64/elf.h linux-foo/include/asm-ia64/elf.h
--- linux-2.6.11-rc2-bk4/include/asm-ia64/elf.h 2004-12-24 22:35:18.000000000 +0100
+++ linux-foo/include/asm-ia64/elf.h 2005-02-06 12:32:47.000000000 +0100
@@ -186,8 +186,8 @@ extern void ia64_elf_core_copy_regs (str
#ifdef __KERNEL__
#define SET_PERSONALITY(ex, ibcs2) set_personality(PER_LINUX)
-#define elf_read_implies_exec(ex, have_pt_gnu_stack) \
- (!(have_pt_gnu_stack) && ((ex).e_flags & EF_IA_64_LINUX_EXECUTABLE_STACK) != 0)
+#define elf_read_implies_exec(ex, executable_stack) \
+ ((executable_stack!=EXSTACK_DISABLE_X) && ((ex).e_flags & EF_IA_64_LINUX_EXECUTABLE_STACK) != 0)
struct task_struct;
diff -purN linux-2.6.11-rc2-bk4/include/asm-x86_64/elf.h linux-foo/include/asm-x86_64/elf.h
--- linux-2.6.11-rc2-bk4/include/asm-x86_64/elf.h 2004-12-24 22:35:24.000000000 +0100
+++ linux-foo/include/asm-x86_64/elf.h 2005-02-06 12:31:39.000000000 +0100
@@ -147,14 +147,7 @@ extern void set_personality_64bit(void);
* An executable for which elf_read_implies_exec() returns TRUE will
* have the READ_IMPLIES_EXEC personality flag set automatically.
*/
-#define elf_read_implies_exec(ex, have_pt_gnu_stack) (!(have_pt_gnu_stack))
-
-/*
- * An executable for which elf_read_implies_exec() returns TRUE will
- * have the READ_IMPLIES_EXEC personality flag set automatically.
- */
-#define elf_read_implies_exec_binary(ex, have_pt_gnu_stack) \
- (!(have_pt_gnu_stack))
+#define elf_read_implies_exec(ex, executable_stack) (executable_stack != EXSTACK_DISABLE_X)
extern int dump_task_regs (struct task_struct *, elf_gregset_t *);
extern int dump_task_fpu (struct task_struct *, elf_fpregset_t *);
next prev parent reply other threads:[~2005-02-06 11:53 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-06 11:36 [PROPOSAL/PATCH] Remove PT_GNU_STACK support before 2.6.11 Andi Kleen
2005-02-06 11:47 ` Arjan van de Ven [this message]
2005-02-06 12:02 ` Ingo Molnar
2005-02-06 12:25 ` Ingo Molnar
2005-02-06 12:36 ` Andi Kleen
2005-02-06 12:45 ` Ingo Molnar
2005-02-06 12:50 ` Andi Kleen
2005-02-06 12:59 ` Arjan van de Ven
2005-02-06 13:01 ` Andi Kleen
2005-02-06 13:04 ` Arjan van de Ven
2005-02-06 13:09 ` Andi Kleen
2005-02-06 13:31 ` Ingo Molnar
2005-02-06 13:43 ` Andi Kleen
2005-02-06 13:06 ` Christoph Hellwig
2005-02-06 13:11 ` Andi Kleen
2005-02-06 13:32 ` Ingo Molnar
2005-02-06 13:46 ` Andi Kleen
2005-02-06 14:08 ` Ingo Molnar
2005-02-06 14:22 ` Ingo Molnar
2005-02-06 14:29 ` Andi Kleen
2005-02-06 17:08 ` Linus Torvalds
2005-02-06 17:13 ` Arjan van de Ven
2005-02-06 17:31 ` Linus Torvalds
2005-02-06 17:39 ` Arjan van de Ven
2005-02-06 18:04 ` Linus Torvalds
2005-02-06 18:08 ` Arjan van de Ven
2005-02-06 17:56 ` Andi Kleen
2005-02-06 12:33 ` Andi Kleen
2005-02-06 12:40 ` Arjan van de Ven
2005-02-06 12:48 ` Andi Kleen
2005-02-06 15:54 ` Andreas Schwab
2005-02-06 17:05 ` Linus Torvalds
2005-02-06 17:58 ` Andi Kleen
2005-02-06 12:11 ` Paweł Sikora
[not found] ` <200502061303.12377.pluto@pld-linux.org>
[not found] ` <20050206124701.GD30109@wotan.suse.de>
2005-02-06 18:07 ` Paweł Sikora
2005-02-06 18:38 ` Andi Kleen
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=20050206114758.GA8437@infradead.org \
--to=arjan@infradead.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@osdl.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