> > W^X is more than just stack protection. It means that all pages that
> > are writeable are also marked as not executable. At least, it means
> > this is how the system by default operates, until some process asks
> > for something that has both write and execute permission.
> >
> > On some architectures W^X is easy, since the native architecture has a
> > execute-permitted bit per page (sparc, sparc64, alpha, hppa, m88k).
> > On other architectures, it is difficult and various hacks have to be
> > done to make it work (i386, powerpc).
>
> It's not difficult at all on x86, but having non-overlapping Segments
> for Code and Data/Stack would limit the virtual address space.

I am not sure if you have heard of this neat technology called "shared
libraries". Either you have never heard of them, or you are unaware
of they work on an x86. Let me be completely blunt. What you are
suggesting is unfeasable. Please go do some learning before making
any more utterly ridiculous proposals.

> This
> doesn't matter if your machine is equipped with 2 GB (RAM+Pagefile) or
> less, because all pages of those 2 GB can completely be mapped to linear
> addresses in either the code or data/stack segment. As soon as there's
> more memory available, you have to decide how large the code and
> data/stack segment should be.

Ridiculous.

> Adressing more than 4 GB on x86 is an ugly hack anyways -PSE as well as
> PAE.

Yet more dribble which is unrelated to the issue at hand.

Anyways, on an i386 you can do W^X somewhat. Not as perfectly as you
can on cpus that have a per-page X bit... Let me try to summarize the
options.

1) Configure the i386 CS code segment limit register so that it cannot
reach into the stack area at the end of memory.

Hence, you can have code below, and your stack above. This only
protects your stack. As many have pointed out, doing so is useless,
unless other protection techologies such as ProPolice are used to
suppliment the protection.

2) Furthermore, try to make the CS code segment limit register reach only
to the end of the data segment.

But then a problem shows up. When you use shared libraries, you end
up with code followed by data followed by code followed by data etc.
Since you only have one line you can draw in the address space,
clearly you can't make this work!

3) To resolve this, we made modifications to ld.so and to the base ELF
binaries and shared library files that are produced. The idea is to
map all CODE from the program, ld.so, and from each of the shared
libraries low in memory, and then to map their respective DATA segments
HIGHER in memory.

We must remember one thing. Each ELF module is internally pre-linked.
This means that the code of a module use relative addressing to access
the data. Or, put another way, the code and data must remain a FIXED
distance from each other in memory; that distance is determined at
link time. You cannot change it at run time without significant
performance problems and other difficulties.

4) So, now that all the code is down below, and all the data is above we
have something like this

stack

gap
gap
gap

libm data
libc data
ld.so data
program data

gap
gap
gap <----

libm code
libc code
ld.so code
0: program code

5) If we are clever, we can now change our kernel to put the CS limit
register at where the arrow is. If new objects are mapped or unmapped
into the address space with X permission, the CS limit register can
change up or down.

No objects above that line can be executed.

In OpenBSD, we've done steps up to 4. We've not done step 5 perfectly
yet (we use a "fixed" line).

Finally, another option:

As an alternative to all this complicated stuff, it is my
understanding that some 32-bit x86 cpus in PAE (64 bit PTEs) mode
honour the highest bit of the PTE as a NX (non-executable) bit. This
would give per-page execution stuff like we have on better cpus.
We've not worked on this yet; it is less valuable since I think it is
only newer Xeons and high-end AMD cpus which support this. And we've
never found documentation for it either :)

[ reply ]