public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: arjanv@redhat.com, luto@myrealbox.com, mingo@elte.hu,
	linux-kernel@vger.kernel.org, akpm@osdl.org,
	suresh.b.siddha@intel.com, jun.nakajima@intel.com
Subject: Re: [announce] [patch] NX (No eXecute) support for x86,   2.6.7-rc2-bk2
Date: Fri, 4 Jun 2004 18:13:04 +0200	[thread overview]
Message-ID: <20040604181304.325000cb.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0406040856100.7010@ppc970.osdl.org>

On Fri, 4 Jun 2004 09:02:26 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:

> 
> 
> On Fri, 4 Jun 2004, Arjan van de Ven wrote:
> > 
> > I know that in a FC1 full install there are less than 5 binaries that don't
> > run with NX. (one uses nested functions in C and passes function pointers to
> > the inner function around which causes gcc to emit a stack trampoline, and
> > gcc then marks the binary as non-NX, the others have asm in them that we
> > didn't fix in time to be properly marked).
> 
> If things are really that good, why are we even worrying about this?

It's only that good because gcc handles it transparently.

Also more weird exe
 
> So instead of having complex things to try to turn NX on for suid, we 
> should aim to turn ot on as widely as possible, _even_if_ that means that 
> people who upgrade hardware might have to do some trivial MIS stuff.

That is what is currently done on x86-64 in the major distributions
(SUSE,RedHat) at least.

Anything compiled with the new gcc is marked NX on unless
it has a trampoline. Old executables are run with NX off.

I would keep the default for old executables off, because
the applications which need the gcc trampolines are more
widely spread that one first things (e.g. most Ada programs
compiled by GNAT and GNAT itself require this and we 
got a few other reports of third party programs breaking)
But that's handled by the policy of only doing it for programs
compiled by the new gcc.

Of course that is only for the stack. Making the heap non executable
is another can of worms. I don't know if Fedora does that
too, SUSE and mainline x86-64 doesn't.

 
> Make a kernel bootup option to default to legacy mode if somebody
> literally has trouble booting and fixing their thing due to "init" or
> similar being one of the problematic cases. Together with a printk() that 
> says which executable triggered, it should be trivial to clean up a 
> system.

That exists too on x86-64:

/* noexec32=opt{,opt} 

Control the no exec default for 32bit processes. Can be also overwritten
per executable using ELF header flags (e.g. needed for the X server)
Requires noexec=on or noexec=noforce to be effective.

Valid options: 
   all,on    Heap,stack,data is non executable.         
   off       (default) Heap,stack,data is executable
   stack     Stack is non executable, heap/data is.
   force     Don't imply PROT_EXEC for PROT_READ 
   compat    (default) Imply PROT_EXEC for PROT_READ

*/

and the same for 64bit processes:

/* noexec=on|off
Control non executable mappings for 64bit processes.

on      Enable
off     Disable
noforce (default) Don't enable by default for heap/stack/data, 
        but allow PROT_EXEC to be effective

*/ 

BTW 64bit processes mostly have the same problem - there are some
that break since the first x86-64 distributions didn't use NX.

-Andi

  reply	other threads:[~2004-06-04 16:18 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-02 20:50 [announce] [patch] NX (No eXecute) support for x86, 2.6.7-rc2-bk2 Ingo Molnar
2004-06-02 21:00 ` Christoph Hellwig
2004-06-02 21:07   ` Ingo Molnar
2004-06-02 21:13 ` Linus Torvalds
2004-06-02 21:17   ` Arjan van de Ven
2004-06-02 21:31     ` Doug McNaught
2004-06-08  8:46       ` Jakub Jelinek
2004-06-03  1:12     ` Joel Becker
2004-06-03  1:27       ` Andi Kleen
2004-06-03  6:24       ` Arjan van de Ven
2004-06-03 20:37     ` jlnance
2004-06-03  7:21   ` Ingo Molnar
2004-06-03 12:44     ` Ingo Molnar
2004-06-03 15:54       ` Andi Kleen
2004-06-03 23:01         ` Andy Lutomirski
2004-06-03 23:08           ` Andi Kleen
2004-06-03 23:54             ` Andy Lutomirski
2004-06-04  0:05               ` Andy Lutomirski
2004-06-04  9:25             ` Ingo Molnar
2004-06-04 15:26               ` Andy Lutomirski
2004-06-04 15:36                 ` Linus Torvalds
2004-06-04 15:41                   ` Arjan van de Ven
2004-06-04 15:47                     ` Linus Torvalds
2004-06-04 15:51                       ` Arjan van de Ven
2004-06-04 16:02                         ` Linus Torvalds
2004-06-04 16:13                           ` Andi Kleen [this message]
2004-06-04 16:37                             ` Arjan van de Ven
2004-06-04 16:40                               ` Christoph Hellwig
2004-06-04 17:27                                 ` David Mosberger
2004-06-04 17:30                                 ` Andi Kleen
2004-06-08  9:07                             ` Jakub Jelinek
2004-06-08  9:14                               ` Andi Kleen
2004-06-08  9:19                                 ` Arjan van de Ven
2004-06-04 16:51                           ` Ulrich Drepper
2004-06-08 17:15                             ` Bill Davidsen
2004-06-04 18:11                         ` Gerhard Mack
2004-06-04 18:12                           ` Arjan van de Ven
2004-06-04 16:06                   ` Ingo Molnar
2004-06-04 17:20                     ` Ingo Molnar
2004-06-04 17:22                       ` Ingo Molnar
2004-06-04 17:32                         ` Ingo Molnar
2004-06-03 19:24       ` Suresh Siddha
2004-06-03 20:37         ` Andi Kleen
2004-06-03 22:58           ` Suresh Siddha
2004-06-03 23:06             ` Andi Kleen
2004-06-04  9:30             ` Ingo Molnar
2004-06-03 12:57     ` Brian Gerst
2004-06-04  9:39       ` Ingo Molnar
2004-06-04 10:41         ` Christoph Hellwig
2004-06-04 10:48           ` William Lee Irwin III
2004-06-03 16:21     ` Ulrich Drepper
2004-06-03 19:30   ` Kurt Garloff
2004-06-02 21:43 ` Andi Kleen
2004-06-03  0:11 ` Rusty Russell
2004-06-03  0:17   ` Jeff Garzik
2004-06-03  7:24   ` Ingo Molnar
2004-06-03  8:47   ` Ingo Molnar
2004-06-03  8:53   ` Ingo Molnar
2004-06-04  0:04     ` Rusty Russell
2004-06-03  9:07 ` Ingo Molnar
2004-06-03 14:36 ` Gerhard Mack
2004-06-03 16:22   ` Arjan van de Ven
2004-06-04  9:36   ` Ingo Molnar
2004-06-04 11:59     ` Stephen Wille Padnos
     [not found] <22L0f-5Ci-11@gated-at.bofh.it>
     [not found] ` <22O7J-8dw-11@gated-at.bofh.it>
     [not found]   ` <22Wf4-5Xv-23@gated-at.bofh.it>
2004-06-03  9:43     ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2004-06-04 18:01 Nakajima, Jun

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=20040604181304.325000cb.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=arjanv@redhat.com \
    --cc=jun.nakajima@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@myrealbox.com \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --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