From: "Robert White" <rwhite@casabyte.com>
To: "'Ingo Molnar'" <mingo@elte.hu>, "'Christoph Hellwig'" <hch@infradead.org>,
       "'Mike McCormack'" <mike@codeweavers.com>,
       <linux-kernel@vger.kernel.org>
Subject: RE: WINE + NX (No eXecute) support for x86, 2.6.7-rc2-bk2
Date: Tue, 8 Jun 2004 14:50:43 -0700
Organization: Casabyte, Inc.
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA2ZSI4XW+fk25FhAf9BqjtMKAAAAQAAAAWUyJbbFwtUuY/ZGbgGI8TwEAAAAA@casabyte.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
In-Reply-To: <20040607141903.GA20863@elte.hu>
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2375
Lines: 50

I would think that having an easy call to disable the NX modification would be both
safe and effective.  That is, adding a syscall (or whatever) that would let you mark
your heap and/or stack executable while leaving the new default as NX, is "just as
safe" as flagging the executable in the first place.

-- You would have to turn it on manually (so Wine etc could do this freely.)
-- Nobody who didn't _need_ it on, would leave it off because people are lazy like
that.
-- The execute-arbitrary-code hacks could only execute that arbitrary code to turn
off NX if the hack was already able to execute its arbitrary code... (recurse as
necessary 8-)

Architecturally the easy-application-accessible switch should be something more than
a syscall to prevent a return-address-twiddle invoking the call directly.  I'd make
it a /proc/self something, or put it in a separate include-only-if-used shared
library or something.  If the minimal distance is opening and writing a
normally-untouched file then you get a nice support matrix.  (e.g. no file means no
feature, file plus action means executable stack, no action means system default (old
can, new cannot), hacks would require a variable (fd) and executing arbitrary code to
open and write that file, programs/programmers that want/need the old behavior can
achieve it without having to know how to manipulate their ELF headers or tool-chains,
etc.)

I know that flagging the binary gives new programs control, but to a great extent we
want the old programs to be controlled as-is instead of only-if-recompiled.

But that's just a thought... 8-)

Rob.


-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]
On Behalf Of Ingo Molnar
Sent: Monday, June 07, 2004 7:19 AM
 
Wine is in a really difficult position (due to the complex task it
achieves) and is more sensitive to VM layout changes than other
applications. So lets try to find the solution that preserves the
kernel's ability to further optimize the VM layout, while meeting Wine's
desire to get a simple VM layout that is not mapped in the first 1 GB or
so.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/