> [1] glibc-2.3.4 kill buggy bins at the load time.
> (please look into: elf/dl-load.c, elf/dl-support.c, elf/rtld.c)
I don't see how that can work for arbitary code executed in some
arbitary mmap.
Please explain.
> This works on i386/PaX systems too (hardware NX isn't required).
But i
On Sun, 2005-02-06 at 10:04 -0800, Linus Torvalds wrote:
> > Ok so what to do for 2.6.11... the setarch workaround is there; that
> > works. My patch patches the worst issues and is quite minimal. What you
> > propose will be more invasive and more suitable for 2.6.11-bk1...
> > I can do such a pa
On Sunday 06 of February 2005 13:47, you wrote:
> On Sun, Feb 06, 2005 at 01:03:11PM +0100, Pawel Sikora wrote:
> > On Sunday 06 of February 2005 12:36, you wrote:
> > > 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 g
On Sun, 6 Feb 2005, Arjan van de Ven wrote:
> >
> > And if you want to split things up, there's at least three flags there:
> > "stack" vs "file mapping" vs "anonymous mapping". For example, it might
>
> lets add "brk" as 4th I guess.
I thought about that, but no normal user program uses brk
On Sun, Feb 06, 2005 at 09:05:05AM -0800, Linus Torvalds wrote:
>
>
> On Sun, 6 Feb 2005, Andi Kleen wrote:
> >
> > There are probably more.
>
> So? Do you expect to never fix them, or what?
Someone will fix them, but it's not the job of the 32bit emulation
of x86-64 to break compatibility. It
On Sun, Feb 06, 2005 at 09:08:47AM -0800, Linus Torvalds wrote:
>
>
> On Sun, 6 Feb 2005, Andi Kleen wrote:
> >
> > Force READ_IMPLIES_EXEC for all 32bit processes to fix
> > the 32bit source compatibility.
>
> Andi, stop this. We're _not_ going to say "32-bit executables don't need
> PROT_EXE
On Sun, 2005-02-06 at 09:31 -0800, Linus Torvalds wrote:
>
> On Sun, 6 Feb 2005, Arjan van de Ven wrote:
> >
> > Note that these techniques all exist today. The only issue is that the
> > current code doesn't do the RWE->READIMPLIESEXEC binding, which my patch
> > fixed.
>
> My main objection t
On Sun, 6 Feb 2005, Arjan van de Ven wrote:
>
> Note that these techniques all exist today. The only issue is that the
> current code doesn't do the RWE->READIMPLIESEXEC binding, which my patch
> fixed.
My main objection to your patch is the naming. If 'executable_stack'
affects the heap, the
On Sun, 2005-02-06 at 09:08 -0800, Linus Torvalds wrote:
>
> On Sun, 6 Feb 2005, Andi Kleen wrote:
> >
> > Force READ_IMPLIES_EXEC for all 32bit processes to fix
> > the 32bit source compatibility.
>
> Andi, stop this. We're _not_ going to say "32-bit executables don't need
> PROT_EXEC. The exe
On Sun, 6 Feb 2005, Andi Kleen wrote:
>
> Force READ_IMPLIES_EXEC for all 32bit processes to fix
> the 32bit source compatibility.
Andi, stop this. We're _not_ going to say "32-bit executables don't need
PROT_EXEC. The executables would need to be marked broken per-executable,
not some kind o
On Sun, 6 Feb 2005, Andi Kleen wrote:
>
> There are probably more.
So? Do you expect to never fix them, or what?
The fact is, a program that tries to execute without using PROT_EXEC is a
buggy program.
Are there buggy programs out there? Yes. We should fix them.
Linus
-
To
Andi Kleen <[EMAIL PROTECTED]> writes:
> They worked fine forever - and suddenly you define them as buggy.
Working fine does not imply non-buggy, never has, never will.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
K
On Sun, Feb 06, 2005 at 03:08:02PM +0100, Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > RWE. But if it triggers it shows up immediately so it's not like you
> > > have no sign that something wrong is going on. Only grub-install
> > > triggers it and no boot/install kernel i
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Last summer nobody did change the 32bit ABI on x86-64.
> >
> > I only started it because the bug reports are appearing now and it's
> > clear now that we have a problem.
>
> the vanilla 2.6.10 x64 kernel, using 32-bit fedora userland boots fine
> he
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > RWE. But if it triggers it shows up immediately so it's not like you
> > have no sign that something wrong is going on. Only grub-install
> > triggers it and no boot/install kernel i know of defaults to
> > PAE-enabled, that's what caused grub-install be
> fortunately there's this 'NX-emulation' thing called exec-shield which
> is part of Fedora (and has been part of it for almost 2 years) and did
> all the testing for you on all x86 hardware, on thousands of packages
> and on over a ten thousand binaries, well in advance of this going
> upstream.
On Sun, Feb 06, 2005 at 02:31:33PM +0100, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Feb 06, 2005 at 02:04:57PM +0100, Arjan van de Ven wrote:
> > >
> > > > Hmm, I got a report that it doesn't work anymore with
> > > > 2.6.11rcs on x86-64. I haven't looked clo
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 06, 2005 at 01:06:50PM +, Christoph Hellwig wrote:
> > On Sun, Feb 06, 2005 at 02:01:52PM +0100, Andi Kleen wrote:
> > > > correct,
> > > > http://lists.ximian.com/archives/public/mono-list/2004-June/021592.html
> > > >
> > > > that fixes
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 06, 2005 at 02:04:57PM +0100, Arjan van de Ven wrote:
> >
> > > Hmm, I got a report that it doesn't work anymore with
> > > 2.6.11rcs on x86-64. I haven't looked closely yet,
> > > but it wouldn't surprise me if this change isn't also invol
On Sun, Feb 06, 2005 at 01:06:50PM +, Christoph Hellwig wrote:
> On Sun, Feb 06, 2005 at 02:01:52PM +0100, Andi Kleen wrote:
> > > correct,
> > > http://lists.ximian.com/archives/public/mono-list/2004-June/021592.html
> > >
> > > that fixes mono instead
> >
> > Silent breakage => bad.
>
> si
On Sun, Feb 06, 2005 at 02:04:57PM +0100, Arjan van de Ven wrote:
>
> > Hmm, I got a report that it doesn't work anymore with
> > 2.6.11rcs on x86-64. I haven't looked closely yet,
> > but it wouldn't surprise me if this change isn't also involved.
>
> PT_GNU_STACK change is there since like 2.
On Sun, Feb 06, 2005 at 02:01:52PM +0100, Andi Kleen wrote:
> > correct,
> > http://lists.ximian.com/archives/public/mono-list/2004-June/021592.html
> >
> > that fixes mono instead
>
> Silent breakage => bad.
silent breakage for newly compiled buggty and non-portable code.
Still not nice but ce
> Hmm, I got a report that it doesn't work anymore with
> 2.6.11rcs on x86-64. I haven't looked closely yet,
> but it wouldn't surprise me if this change isn't also involved.
PT_GNU_STACK change is there since like 2.6.6 (and was put in by a suse person)
To me that is a strong indication that y
> correct,
> http://lists.ximian.com/archives/public/mono-list/2004-June/021592.html
>
> that fixes mono instead
Silent breakage => bad.
>
> > (and i suspect wine) and the others
>
> wine is ok, it uses PROT_EXEC correctly for things it's not sure about.
Hmm, I got a report that it doesn't w
On Sun, 2005-02-06 at 13:50 +0100, Andi Kleen wrote:
> > i.e. all mappings are executable (i.e. READ_IMPLIES_EXEC effect) - the
> > intended change. (although i dont fully agree with PT_GNU_STACK being
> > about something else than the stack, from a security POV if the stack is
> > executable then
> i.e. all mappings are executable (i.e. READ_IMPLIES_EXEC effect) - the
> intended change. (although i dont fully agree with PT_GNU_STACK being
> about something else than the stack, from a security POV if the stack is
> executable then all bets are off anyway. The heap and all mmaps being
> execu
On Sun, Feb 06, 2005 at 01:40:22PM +0100, Arjan van de Ven wrote:
> On Sun, 2005-02-06 at 13:33 +0100, Andi Kleen wrote:
> > > Your main objection is that *incorrect* programs that assume they can
> > > execute malloc() code without PROT_EXEC protection. For legacy binaries
> > > keeping this behav
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > 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
On Sun, 2005-02-06 at 13:33 +0100, Andi Kleen wrote:
> > 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 program
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
>
> (I'd like to stress that this problem only affects packages _recompiled_
> with new gcc, running on NX capable CPUs - legacy apps or CPUs are in no
Yeah, but who did the auditing of all user land packages if they
don't need changes? And who to
> 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.
That's not true as the gru
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > [...] 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)
> > So I rather see the patch below merged instead; it fixes the wo
My proposal is to recompile broken software with cflags += -Wa,--noexecstack.
This works fine with e.g. 2.6.10+pax/i386.
--
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */
#define say(x) lie(x)
-
To unsubscribe from this list: send the line
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > [...] 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
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 prog
Hallo,
I'm getting more and more reports that the PT_GNU_STACK change breaks
a lot of programs. In particular it breaks grub which implies that nobody
could have really tested it. Mono seems to break too, there are undoubtedly
others. There are some reports of Wine breaking too, I suspect
they ar
36 matches
Mail list logo
