Matt Thomas wrote:

> Some architectures (powerpc) have ABIs that mandate executable bss/data.
> There is no way to turn that off.

True, but two things:

  1. How many of our users run i386, amd64, sparc, sparc64? how many of
     them run powerpc?
  2. We are already providing this feature where we can, so it's not
     this that is up for discussion. :)

> If you have textrel relocations, you have to allow this. 

True. However, PaX is aware of text relocations, and addresses them.

> I think the
> right way to have add a PROT_LOCKED that mprotect can understand.  If
> this is supplied, the protection on such pages can't be downgraded.
> munmap would still be allowed (it might be advisable to make munmap
> change the region to PROT_NONE but leave it in place so it can't be
> remapped.)

We should look at the two solutions and decide which fits best; or
maybe combine them.

> The program itself is linked at a base address.  the libraries and stacks
> could be vary but on machines with virtual caches, that might be very painful.

Like I said, let's leave the choice to the user. I'm sure there are
plenty of people with 3ghz machines that will be happy to have this
feature at the given cost...

> So you are saying that most libraries should be mapped at < 16MB? 

No, I'm saying that SSP (in gcc 4.1) should address both problems in
a more elegant manner than a NULL byte in the return address. This is
also why I didn't ask this feature to be discussed in the mail.

> That's
> just not practical for most architectures.  I suppose that libraries with
> <= 64KB of text can just be mapped on a 16MB boundary.  On LP64 you can map
> libraries into the first 16MB of each 4GB region.  Of course, you'll fragment
> your memory space that way.

It's also a very ugly solution. It's not up for discussion. :)

> I don't think that really practical for most platforms.

This mail has two intentions:

  1. Present the paxtest tool and provide some explanantion about its
     tests.
  2. Ask to discuss the importing of two features from PaX: ASLR
     (Address Space Layout Randomization) and MPROTECT (the mprotect()
     restrictions).

ASLR is practical. It may add a performance hit, but like I already
said, let's leave that choice to the user. MPROTECT is also practical
but needs special care.

-e.

-- 
Elad Efrat