[OT] PaX

[pageexec_(_at_)_freemail_(_dot_)_hu]

> For a start, PAX violates POSIX by breaking mprotect.  By default, it
> runs without ever permitting W | X to exist, which is wrong according
> to standards

http://www.opengroup.org/onlinepubs/007904975/functions/mprotect.html

It's SUSv3, hopefully qualifies as a standard. Among others it says:

-------------------------------------------------------------------
If an implementation cannot support the combination of access types
specified by prot, the call to mprotect() shall fail.
-------------------------------------------------------------------

OpenBSD couldn't support PROT_EXEC until 3.2 on any architecture,
and still cannot on some. Therefore any mprotect() request not
asking for PROT_EXEC shall fail, but they don't. It's also clear
that the standard anticipates implementations that are not able
to provide all possible protection types so it's well within the
spec to not provide them all, just make it clear to userland (by
failing the offending mprotect() call - which PaX does).

Speaking of POSIX compliance, consider checking your own mmap()
implementation for example. The spec says this:

-----------------------------------------------------------
The mmap() function shall fail if:

[EACCES] 
The fildes argument is not open for read, regardless of the
protection specified, or fildes is not open for write and
PROT_WRITE was specified for a MAP_SHARED type mapping. 
-----------------------------------------------------------

Compare this to your code in sys/uvm/uvm_mmap.c (notice the word
'regardless' above):

------------------------------------------------
                /* check read access */
                if (fp->f_flag & FREAD)
                        maxprot |= VM_PROT_READ;
                else if (prot & PROT_READ) {
                        error = EACCES;
                        goto out;
                }
------------------------------------------------

This i got after some 10 seconds of looking at it, feel free
to check the rest of the code.

> expectations of software,

That's when you modify non-compliant software to bring it in line
with what the standard says.

> and quite frankly unreasonable.

Given our attack model, it's required. For details please see the
docs at http://pageexec.virtualave.net/docs/ .

> PAX is also utterly *GLACIAL* because of software tlb
> loading, anyone want a 15% slowdown?  It is not as interesting for us,
> since it is not an OpenBSD-useable technology.

I assume here that you're talking about the i386 support (since we last
talked, we got PaX to work on alpha/parisc/ppc/sparc/sparc64). It may
have missed your attention but on i386 PaX has two different non-exec
implementations. The one you're referring to above is called PAGEEXEC
and is based on the paging logic. Its performance impact is not any
fixed number, it can be anywhere between 0-500%, depending on mainly
how good the given CPU's TLB is and the memory access pattern of a
given application. The other approach is called SEGMEXEC and is based
on the segmentation logic. Its performance impact i don't know exactly
as i never tested it standalone, only with other PaX features enabled,
so the combined effect of randomization (ASLR as we call it) and this
SEGMEXEC is around 1-2% on a kernel compilation 'benchmark' and that's
because it does so many fork()/execve()/mmap(), otherwise the impact
would be closer to 0%.

> W^X is not like no-exec stack.  We had no-exec stack in our previous
> release.  Booooring.  On any i386, anyone can craft their own frame
> and return to libc without executing any of their own code.  No-exec
> stack is completely irrelevant without ProPolice, to canary protect
> the return.

There are bugs other than linear stack overflows which may still
allow a return-to-libc style exploit (and in your case, totally
circumvent W^X), what are you doing about them?

> Yes, other vendors who move to W^X are going to have to change their
> binaries on some architectures.  If they don't change, they might not
> get these protections.  That's a problem of most vendors using ELF
> simply as if it was "a.out with ctor/dtor".

PaX doesn't require changes in (most of) userland to provide all
the protection features.

> PAX, as it is now breaking mprotect

No, PaX does not break mprotect(), it does what the standard allows.
Besides, if an app does need the relaxed behaviour, it can be allowed
by simply setting an ELF header flag on the given binary.

> and doing slow TLB handling,

TLB handling is not slow in PaX per se, it's the CPU/TLB architecture
of IA-32 which makes things slower than necessary (i wish you succeeded
in convincing the IA-32 vendors into adopting true hardware support for
the non-exec flag). Also PAGEEXEC is not even the default non-exec page
implementation, it's SEGMEXEC.

> will never be on by default in RedHat, but ProPolice and W^X are shipping
> in OpenBSD.  Again -- it will never ship on by default in RedHat --
> anyone want to put money on a wager?

PaX is already part of several distros, mostly because they use
grsecurity. One can get it on Mandrake, Debian, Trusted Debian,
Gentoo, etc.

Besides, isn't it a bit unfair to compare the situation of PaX and
RedHat to that of OpenBSD? You realize that you control everything
(kernel+userland) in OpenBSD which is not true in our case.

> We don't break anything that standards or defacto standards require.

You do break POSIX as pointed out above.