At 09:11 AM 10/15/2004, Tim Kelly wrote:
>Hi All,
>I've been researching some aspects of the PowerPC chip with respect to
>W^X (write xor execute). I have some questions that I could discuss
>offline or leave open to the general list.
>
>In looking over the Programming Environment Manual for 32 bit
>Microprocessors, there are specific references to being able to set
>segments to read, read-write, and executable-only (Chapter 7).
>Additionally, it appears that the PPC can handle segments combined with
>paging. I found a discuss at
>
>http://www.pantek.com/library/general/lists/openbsd.org/tech/msg00718.html

Not quite accurate.   read & read/write and independent of executable &
non-executable.

>where this was discussed on an OpenBSD mailing list. I don't fully
>follow the conclusion, which is that because the segments have to be
>256MB each, W^X can't be done on PPC. Part of that also had to do with
>certain sections of ELF executables, which I am not knowledgeable
>enough to fully grok.

Part of the problem is that a proper implementation of the SVR4 ELF ABI
for PowerPC thwarts any attempt to make use of NX segments.  This is due
to completely idiotic way the Procedure Linkage Table is handled.  AIX's
XCOFF and its descendents are designed to avoid these problems.

>My immediate question is: would it be possible to set certain
>256M segments(via BATS?) to be read-write and other segments to
>executable-only, and during the loading of an executable image place the
>.text section in the latter and the .data and .bss in the former (using
>xcoff terminology)? I know that this would require the kernel to alter
>the priviledges of the executable during image loading, but it would
>ideally limit the damage of user-land buffer overflows because those
>overflows would write into a no-execute segment.

Possible?  Yes.  Practical?  No.  However, even if you put the text
segment and the data psections in separate segments, it's difficult
to properly the manage the mapping of such libraries.  This is due to
the fact they conceptually overlap each other.

>Would the bulk of the issue reside in the ld linker, or in the memory
>management? Would the ld linker need to be rewired? If so, and I would
>guess that this would break existing compiled applications, is achieving
>this worth the loss of backwards compatibility?

The MMU and the pmap implementation fully supports NX.  The problem is in
the ELF32 ABI we use.

>Is it written somewhere that in segment page combinations all parts must
>be within the same segment?

Yes.  The SVR4 ABI for PPC.

>I know that 4.4BSD is purely paged. However, would it be possible to
>shim prior to pmap such that pmap gets fooled into thinking it is purely
>paged? Can pmap differentiate between one virtual address space and
>another if both are established prior to pmap? Would it be possible at
>the page level to exclude two processes in the same segment from seeing
>each other?

Huh?  Each process has its own 4GB virtual address space.  Completely
independent of every other process.

>Although OpenBSD explored this issue, I have perceived a bias against
>the PowerPC CPU and I wonder if the problems are not because of the cpu
>but because of the specific, immutable approach they wanted to take.
>Given that there is a bit more room to branch within NetBSD, I wondered
>if there may be a higher chance for success in doing this here.

As long as we use the SVR4 ABI, we are unable to do anything.  ELF64,
an XCOFF descendent, does allow better use for NX.


-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.