PowerPC paxtest results w/ gcc-4.1

PowerPC paxtest results w/ gcc-4.1

[Albert Cahalan]

I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful.
Does nobody care to fix this? (well heck, the patched firefox isn't
showing up via aptitude yet, and my browser just died a horrible
and unexpected death involving a pop-up ad, so I guess not!)

I suppose part of the problem is that paxtest requires serious
hacking to work right on PowerPC. Critical fixes are:

1. unnest the dummy() function (PaX marketing bullshit)
2. change the return opcode (see code below)
3. flush the cache as needed (see code below)
4. use the Makefile-portable that Gentoo has
5. compile with "-W -Wall -fno-strict-aliasing" and fix warnings

With all that done, gasp in horror at the truth:

Linux cube 2.6.17-rc5 #1 PREEMPT Sat May 27 20:35:12 EDT 2006 ppc GNU/Linux
Executable anonymous mapping             : Vulnerable
Executable bss                           : Vulnerable
Executable data                          : Vulnerable
Executable heap                          : Vulnerable
Executable stack                         : Vulnerable
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable stack (mprotect)              : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments                   : Vulnerable
Anonymous mapping randomisation test     : No randomisation
Heap randomisation test (ET_EXEC)        : No randomisation
Heap randomisation test (ET_DYN)         : No randomisation
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : No randomisation
Shared library randomisation test        : No randomisation
Stack randomisation test (SEGMEXEC)      : 11 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 11 bits (guessed)
Return to function (strcpy)              : paxtest: bad luck
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : paxtest: bad luck
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Vulnerable
Executable shared library data           : Vulnerable

About the only saving grace is that the attacker would have
to get lucky with the cache if they need code executed.

Look, it's not as if we get closed-source binaries on PowerPC
anyway. Non-free isn't the Debian way either. Screw the ABI.
We need a fail-safe (enabled by default) fix for this.

///////// code added to the top of paxtest body.h //////////
// use this code in the obvious way
#if defined(__ppc__) || defined(__powerpc__)
#define RET 0x4e800020     // "blr" or "bclr 20,0"
#define FLUSH(x) __asm__ __volatile__(\
  "dcbf 0,%0  ;  sync  ; icbi 0,%0  ; sync  ;  isync  ; sync" \
  :                        \
  : "r" (x)                \
  : "memory"              \
)
#endif

#if defined(__i386__) || defined(__x86_64__)
#define RET 0xc3c3c3c3     // ret ret ret ret
#define FLUSH(x)
#endif

#include <string.h>
///////////////////////////////////////////////////////////

Re: PowerPC paxtest results w/ gcc-4.1

[Paul Mackerras]

Albert Cahalan writes:

> I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful.

What gcc version, what binutils version, what kernel version?

Paul.

Re: PowerPC paxtest results w/ gcc-4.1

[Albert Cahalan]

On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful.
>
> What gcc version, what binutils version, what kernel version?

My gcc claims to be:

Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre
--enable-mpfr --disable-softfloat
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--enable-checking=release powerpc-linux-gnu
Thread model: posix
gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)

I suppose binutils can be determined by ld:

GNU ld version 2.16.91 20060413 Debian GNU/Linux

The kernel version was reported:

Linux cube 2.6.17-rc5 #1 PREEMPT Sat May 27 20:35:12 EDT 2006 ppc GNU/Linux

Re: PowerPC paxtest results w/ gcc-4.1

[Paul Mackerras]

Albert Cahalan writes:

> gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)

OK, so I think that version should have the new -msecure-plt flag,
which changes the ppc32 ABI so that the PLT no longer has to be
writable and executable.  Previously the dynamic linker would rewrite
each PLT entry, the first time it is used, to jump directly to the
target routine.  That was the reason why the heap had to be
executable.

To get the full benefit of -msecure-plt, every object file in your
executable has to be compiled with it, and I think every shared
library the program uses has to be compiled with it too.  On a system
where everything has been compiled with -msecure-plt, I believe the
heap and stack will automatically be made non-executable.

Of course, that won't make all that much difference on your Cube,
because the G4 CPU doesn't have hardware support for non-executable
pages (any readable page is executable).  The G5 does, as do the 4xx
and Book E 32-bit CPUs, and any 64-bit CPU from POWER4 on.

As for the randomization, I'm surprised we got no stack randomization,
since that appears to be handled generically (randomize_stack_stop()
in fs/binfmt_elf.c).  What does cat /proc/sys/kernel/randomize_va_space
give you?  (i386 also does arch-specific randomization of some low
bits of the stack pointer, which we could do too.)

Shared library randomization is a glibc thing, I assume.  (It is
incompatible with prelink, of course.)  I don't believe we can do
ET_EXEC address randomization, and I don't think x86 can do it either.

Paul.

Re: PowerPC paxtest results w/ gcc-4.1

[Albert Cahalan]

On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
>
> OK, so I think that version should have the new -msecure-plt flag,

The flag matters not, even with the very latest binutils
that Debian offers, version 2.17-2:

$ md5sum default m*
5f8398f47793ae0eee635989825c8e6b  default
5f8398f47793ae0eee635989825c8e6b  mbss-plt
5f8398f47793ae0eee635989825c8e6b  msecure-plt

(the default needs to be secure of course, so that
all the Debian packages get it)

> To get the full benefit of -msecure-plt, every object file in your
> executable has to be compiled with it, and I think every shared
> library the program uses has to be compiled with it too.  On a system
> where everything has been compiled with -msecure-plt, I believe the
> heap and stack will automatically be made non-executable.

VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
default is important for security. If gcc on PowerPC ever
does generate code which puts trampolines on the stack,
then that can be fixed by converting to legal C code or
by adding the fragile marking to the defective executables.
Did gcc ever generate such code on PowerPC? If not,
then there is no reason to ever allow an executable stack.

In any case, I see no markings:

$ eu-readelf -n /lib/libc-2.3.6.so

Note segment of 32 bytes at offset 0x174:
  Owner          Data size  Type
  GNU                   16  VERSION
    OS: Linux, ABI: 2.4.1

$ eu-readelf -n a.out

Note segment of 32 bytes at offset 0x124:
  Owner          Data size  Type
  GNU                   16  VERSION
    OS: Linux, ABI: 2.4.1

> Of course, that won't make all that much difference on your Cube,
> because the G4 CPU doesn't have hardware support for non-executable
> pages (any readable page is executable).

No. Look in the segment registers. The granularity
isn't great, but the stack can be protected at least.
With a decent memory layout, as is done for using
the CS segment limit on i386, all but the bottom
256 MiB should be non-execute.

Counting executable pages per segment is reasonable.
I believe this is what OpenBSD does.

A better way would be to frequently mark the segments
as non-execute. (upon every context switch, mapping
change, or sleep) Then, upon taking a fault, only enable
execute in the segment if the instruction pointer is in an
area which is really supposed to be executable.

> As for the randomization, I'm surprised we got no stack randomization,
> since that appears to be handled generically (randomize_stack_stop()
> in fs/binfmt_elf.c).  What does cat /proc/sys/kernel/randomize_va_space
> give you?  (i386 also does arch-specific randomization of some low
> bits of the stack pointer, which we could do too.)

I get a 1.

> Shared library randomization is a glibc thing, I assume.  (It is
> incompatible with prelink, of course.)

It seems that glibc often asks for specific addresses,
which is bad. The rest of the time this is a kernel issue.

> I don't believe we can do
> ET_EXEC address randomization, and I don't think x86 can do it either.

Sure, but I just tried the other type (should be default)
and didn't get any improvement.

Re: PowerPC paxtest results w/ gcc-4.1

[Paul Mackerras]

Albert Cahalan writes:

> VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> default is important for security. If gcc on PowerPC ever
> does generate code which puts trampolines on the stack,
> then that can be fixed by converting to legal C code or
> by adding the fragile marking to the defective executables.
> Did gcc ever generate such code on PowerPC? If not,
> then there is no reason to ever allow an executable stack.

I believe it did for nested procedures in C.

Now that we have the VDSO and use it for signal trampolines, we
probably could change the default stack protections.

> No. Look in the segment registers. The granularity
> isn't great, but the stack can be protected at least.

No, ld.so tends to go just below the stack:

f7fe6000-f7fff000 r-xp 00000000 08:05 17069          /lib/ld-2.3.6.so
f800e000-f800f000 r--p 00018000 08:05 17069          /lib/ld-2.3.6.so
f800f000-f8010000 rwxp 00019000 08:05 17069          /lib/ld-2.3.6.so
ffe67000-ffe7c000 rw-p ffe67000 00:00 0              [stack]

Paul.

Re: PowerPC paxtest results w/ gcc-4.1

[Alan Modra]

On Sun, Aug 13, 2006 at 09:54:14AM +1000, Paul Mackerras wrote:
> To get the full benefit of -msecure-plt, every object file in your
> executable has to be compiled with it

Yes.  In particular, glibc startup files need to be compiled with
-msecure-plt.  If ld links any object file that uses the old scheme
requiring an executable .got into the executable, then the old layout is
forced.

>, and I think every shared
> library the program uses has to be compiled with it too.

No, this isn't necessary.

>  On a system
> where everything has been compiled with -msecure-plt, I believe the
> heap and stack will automatically be made non-executable.

Exec stack is a separate issue from the plt/got layout.  You need a
kernel that sets non-exec stack by default and respects PT_GNU_STACK
program header.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: PowerPC paxtest results w/ gcc-4.1

[Albert Cahalan]

On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> > default is important for security. If gcc on PowerPC ever
> > does generate code which puts trampolines on the stack,
> > then that can be fixed by converting to legal C code or
> > by adding the fragile marking to the defective executables.
> > Did gcc ever generate such code on PowerPC? If not,
> > then there is no reason to ever allow an executable stack.
>
> I believe it did for nested procedures in C.

I just disassembled libgcc. You're right. Eeeeeew.
I filed a bug describing two better methods for this.

> Now that we have the VDSO and use it for signal trampolines, we
> probably could change the default stack protections.

Heh. I though i386 was the only one to ever do that.
The obvious method is to set the return address to
be a special value which will fault, like -3.

> > No. Look in the segment registers. The granularity
> > isn't great, but the stack can be protected at least.
>
> No, ld.so tends to go just below the stack:
>
> f7fe6000-f7fff000 r-xp 00000000 08:05 17069          /lib/ld-2.3.6.so
> f800e000-f800f000 r--p 00018000 08:05 17069          /lib/ld-2.3.6.so
> f800f000-f8010000 rwxp 00019000 08:05 17069          /lib/ld-2.3.6.so
> ffe67000-ffe7c000 rw-p ffe67000 00:00 0              [stack]

That looks like a 64-bit system, which doesn't have
the granularity problem anyway. 32-bit powerpc seems
to be decent. The heap shares with the executable
itself, and of course there is the yucky 2 GB limit.

$ cat /proc/self/maps
00100000-00103000 r-xp 00100000 00:00 0
0fe8b000-0ffd4000 r-xp 00000000 03:0d 2081203    /lib/tls/libc-2.3.6.so
0ffd4000-0ffe3000 ---p 00149000 03:0d 2081203    /lib/tls/libc-2.3.6.so
0ffe3000-0ffea000 r--p 00148000 03:0d 2081203    /lib/tls/libc-2.3.6.so
0ffea000-0ffee000 rwxp 0014f000 03:0d 2081203    /lib/tls/libc-2.3.6.so
0ffee000-0fff0000 rwxp 0ffee000 00:00 0
10000000-10005000 r-xp 00000000 03:0d 1327891    /bin/cat
10014000-10015000 rwxp 00004000 03:0d 1327891    /bin/cat
10015000-10036000 rwxp 10015000 00:00 0          [heap]
30000000-30019000 r-xp 00000000 03:0d 2080939    /lib/ld-2.3.6.so
30019000-3001b000 rw-p 30019000 00:00 0
30028000-30029000 r--p 00018000 03:0d 2080939    /lib/ld-2.3.6.so
30029000-3002a000 rwxp 00019000 03:0d 2080939    /lib/ld-2.3.6.so
7fa45000-7fa5a000 rw-p 7fa45000 00:00 0          [stack]

Re: PowerPC paxtest results w/ gcc-4.1

[Hollis Blanchard]

On Sun, 2006-08-13 at 00:11 -0400, Albert Cahalan wrote:
> 
> On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> > Albert Cahalan writes:
> >
> > > VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> > > default is important for security. If gcc on PowerPC ever
> > > does generate code which puts trampolines on the stack,
> > > then that can be fixed by converting to legal C code or
> > > by adding the fragile marking to the defective executables.
> > > Did gcc ever generate such code on PowerPC? If not,
> > > then there is no reason to ever allow an executable stack.
> >
> > I believe it did for nested procedures in C.
> 
> I just disassembled libgcc. You're right. Eeeeeew.
> I filed a bug describing two better methods for this.

URL?

-Hollis

Re: PowerPC paxtest results w/ gcc-4.1

[Albert Cahalan]

On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> Of course, that won't make all that much difference on your Cube,
> because the G4 CPU doesn't have hardware support for non-executable
> pages (any readable page is executable).

I now have an evil grin, and a kernel that prevents
execution from the stack. It passes that one part
of paxtest now.

If the -msecure-plt actually did something (it's a nop
according to md5sum) and the executable mappings
didn't share with other ones, I'd have it all protected.

Signed-off-by: Albert Cahalan

---------

--- linux-2.6.17-rc5/arch/powerpc/kernel/head_32.S      2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/arch/powerpc/kernel/head_32.S    2006-08-13
10:48:38.000000000 -0400
@@ -1182,7 +1182,7 @@
 _GLOBAL(set_context)
        mulli   r3,r3,897       /* multiply context by skew factor */
        rlwinm  r3,r3,4,8,27    /* VSID = (context & 0xfffff) << 4 */
-       addis   r3,r3,0x6000    /* Set Ks, Ku bits */
+       addis   r3,r3,0x7000    /* Set Ks, Ku, N bits */
        li      r0,NUM_USER_SEGMENTS
        mtctr   r0

--- linux-2.6.17-rc5/arch/powerpc/mm/fault.c    2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/arch/powerpc/mm/fault.c  2006-08-13
19:17:22.000000000 -0400
@@ -134,8 +134,8 @@
         * bits we are interested in.  But there are some bits which
         * indicate errors in DSISR but can validly be set in SRR1.
         */
-       if (trap == 0x400)
-               error_code &= 0x48200000;
+       if (is_exec)
+               error_code &= 0x58200000;
        else
                is_write = error_code & DSISR_ISSTORE;
 #else
@@ -242,7 +242,7 @@
 good_area:
        code = SEGV_ACCERR;
 #if defined(CONFIG_6xx)
-       if (error_code & 0x95700000)
+       if (error_code & 0x85700000)
                /* an error such as lwarx to I/O controller space,
                   address matching DABR, eciwx, etc. */
                goto bad_area;
@@ -258,12 +258,24 @@
 #endif /* CONFIG_8xx */

        if (is_exec) {
+               if (!(vma->vm_flags & VM_EXEC)) {
+#if 0
+                       static __typeof__(jiffies) oldjif;
+                       static int count;
+                       if(count++ < 5)
+                       printk(KERN_CRIT "fuckup @ %08lx with trap
0x%x code %08lx by %s\n",
+                               address, trap, error_code, current->comm);
+                       if(jiffies/(HZ*15) != oldjif/(HZ*15)) {
+                               oldjif = jiffies;
+                               count = 0;
+                       }
+#endif
+                       goto bad_area;
+               }
 #ifdef CONFIG_PPC64
                /* protection fault */
                if (error_code & DSISR_PROTFAULT)
                        goto bad_area;
-               if (!(vma->vm_flags & VM_EXEC))
-                       goto bad_area;
 #endif
 #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
                pte_t *ptep;
@@ -291,6 +303,27 @@
                        pte_unmap_unlock(ptep, ptl);
                }
 #endif
+#if !defined(CONFIG_4xx) && !defined(CONFIG_BOOKE) && !defined(CONFIG_PPC64)
+               if (!(error_code & 0x10000000))
+                       goto survive;
+               /* It was an ISI exception with SRR1 bit 3 set.
+                * We have no-execute bits in the 256 MiB segments.
+                * We sometimes take faults to turn the bits on.
+                * Faults happen when the user executes from guarded mem,
+                * no-execute segment, or (extinct) direct-store segment.
+                * The segment-related faults happen first. */
+               unsigned segreg;
+               __asm__ __volatile__("mfsrin %0,%1":"=r"(segreg):"r"(address));
+               /* if current segment is no-execute but not direct-store */
+               if (segreg>>28==7) {
+                       /* clear the N bit to make it executable */
+                       segreg &= 0x6fffffff;
+                       __asm__ __volatile__("mtsrin
%0,%1"::"r"(segreg),"r"(address));
+                       /* TODO: as this one goes executable, make
other segments not */
+                       up_read(&mm->mmap_sem);
+                       return 0;
+               }
+#endif
        /* a write */
        } else if (is_write) {
                if (!(vma->vm_flags & VM_WRITE))
@@ -300,7 +333,7 @@
                /* protection fault */
                if (error_code & 0x08000000)
                        goto bad_area;
-               if (!(vma->vm_flags & (VM_READ | VM_EXEC)))
+               if (!(vma->vm_flags & (VM_READ | VM_EXEC))) /* VM_EXEC
wrong for ppc32? */
                        goto bad_area;
        }

--- linux-2.6.17-rc5/include/asm-powerpc/page.h 2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/include/asm-powerpc/page.h       2006-08-13
11:58:25.000000000 -0400
@@ -90,6 +90,9 @@
 #define VM_DATA_DEFAULT_FLAGS64        (VM_READ | VM_WRITE | \
                                 VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)

+#define VM_STACK_DEFAULT_FLAGS (VM_READ | VM_WRITE | \
+                                VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+
 #ifdef __powerpc64__
 #include <asm/page_64.h>
 #else

Re: PowerPC paxtest results w/ gcc-4.1

[Albert Cahalan]

On 8/13/06, Hollis Blanchard <hollis@penguinppc.org> wrote:
> On Sun, 2006-08-13 at 00:11 -0400, Albert Cahalan wrote:
> >
> > On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> > > Albert Cahalan writes:
> > >
> > > > VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> > > > default is important for security. If gcc on PowerPC ever
> > > > does generate code which puts trampolines on the stack,
> > > > then that can be fixed by converting to legal C code or
> > > > by adding the fragile marking to the defective executables.
> > > > Did gcc ever generate such code on PowerPC? If not,
> > > > then there is no reason to ever allow an executable stack.
> > >
> > > I believe it did for nested procedures in C.
> >
> > I just disassembled libgcc. You're right. Eeeeeew.
> > I filed a bug describing two better methods for this.
>
> URL?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382746

RE: PowerPC paxtest results w/ gcc-4.1

[Matt Sealey]

> Of course, that won't make all that much difference on your 
> Cube, because the G4 CPU doesn't have hardware support for 
> non-executable pages (any readable page is executable)

I don't think this is true?

Book I compatible PowerPC's have had a "no-executable" bit in
the page protection flags since the dark ages.. see page 7-38
and 7-39 of the 'Programming Environments Manual for 32-Bit
Microprocessors'.. this document predates even the G3.

As far as the documentation goes, you can make the page
readable and writable to the LSU, but the N bit causes the
instruction fetch to cause a machine check. That's pretty
"not-executable" to me at least :)

-- 
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations

RE: PowerPC paxtest results w/ gcc-4.1

[Matt Sealey]

> That looks like a 64-bit system, which doesn't have the 
> granularity problem anyway. 32-bit powerpc seems to be 
> decent. The heap shares with the executable itself, and of 
> course there is the yucky 2 GB limit.

One thing I'm curious about, has anyone EVER made a system which
actually used the 36-bit addressing on the G4?

I always wondered why such support was never in Linux but then
again if nobody connected the other 4 address lines on any PowerPC
board ever made that ran Linux, there's nothing ever to test it
on anyway. It wouldn't be any more problematic (same way as the NX
bit..) than Intel PAE support, right?

-- 
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations

Re: PowerPC paxtest results w/ gcc-4.1

[Kumar Gala]

On Aug 14, 2006, at 7:17 AM, Matt Sealey wrote:

>
>
>> That looks like a 64-bit system, which doesn't have the
>> granularity problem anyway. 32-bit powerpc seems to be
>> decent. The heap shares with the executable itself, and of
>> course there is the yucky 2 GB limit.
>
> One thing I'm curious about, has anyone EVER made a system which
> actually used the 36-bit addressing on the G4?

I believe Marvell was the only one that had chipsets that supported  
the larger addressing.  Looks like the TSI 108 does as well.

The 44x has some "hacks" to allow support for larger pages for IO  
operations.  Having struct resource now be 64-bits and some of the  
page mapping functions takes pfn's make it easier to support 36-bit  
physical.

> I always wondered why such support was never in Linux but then
> again if nobody connected the other 4 address lines on any PowerPC
> board ever made that ran Linux, there's nothing ever to test it
> on anyway. It wouldn't be any more problematic (same way as the NX
> bit..) than Intel PAE support, right?

True, there is more infrastructure now to support it better.  I'm not  
sure how well PAE is supported in stock kernels.  Go look for  
discussions on the 4G/4G patches.

- kumar

RE: PowerPC paxtest results w/ gcc-4.1

[Paul Mackerras]

Matt Sealey writes:

> Book I compatible PowerPC's have had a "no-executable" bit in
> the page protection flags since the dark ages.. see page 7-38
> and 7-39 of the 'Programming Environments Manual for 32-Bit
> Microprocessors'.. this document predates even the G3.

What are you referring to?  I have a copy of the PEM from pre-G3 days,
and a copy that I downloaded just now, and neither of them have an N
bit in the PTE (and yes I just looked carefully through pages 7-38 and
7-39).

There is an N bit in the segment register format, and that's what
Albert is using.

> As far as the documentation goes, you can make the page
> readable and writable to the LSU, but the N bit causes the
> instruction fetch to cause a machine check. That's pretty
> "not-executable" to me at least :)

A machine check is nasty, because it may not be recoverable...

Paul.

Re: PowerPC paxtest results w/ gcc-4.1

[Gabriel Paubert]

On Tue, Aug 15, 2006 at 01:59:05PM +1000, Paul Mackerras wrote:
> Matt Sealey writes:
> 
> > Book I compatible PowerPC's have had a "no-executable" bit in
> > the page protection flags since the dark ages.. see page 7-38
> > and 7-39 of the 'Programming Environments Manual for 32-Bit
> > Microprocessors'.. this document predates even the G3.
> 
> What are you referring to?  I have a copy of the PEM from pre-G3 days,
> and a copy that I downloaded just now, and neither of them have an N
> bit in the PTE (and yes I just looked carefully through pages 7-38 and
> 7-39).
> 
> There is an N bit in the segment register format, and that's what
> Albert is using.
> 
> > As far as the documentation goes, you can make the page
> > readable and writable to the LSU, but the N bit causes the
> > instruction fetch to cause a machine check. That's pretty
> > "not-executable" to me at least :)
> 
> A machine check is nasty, because it may not be recoverable...

I agree, but I don't know why you believe it would cause 
a machine check (0x200): from my docs, it is an ISI (0x400). 

BTW, there is one way to make pages non executable: mark
them as guarded, but it will have a significant cost in
terms of performance. 

I never understood why PTE entries waste 4 bits (WIMG)
for effectively very few valid combinations.

	Regards,
	Gabriel

Re: PowerPC paxtest results w/ gcc-4.1

[Paul Mackerras]

Gabriel Paubert writes:

> I agree, but I don't know why you believe it would cause 
> a machine check (0x200): from my docs, it is an ISI (0x400). 

I don't believe it would cause a machine check either, but that is
what Matt Sealey was saying.  I don't know where he got that idea.

> BTW, there is one way to make pages non executable: mark
> them as guarded, but it will have a significant cost in
> terms of performance. 

Indeed.  I guess we could do that as a config option for machines that
really want maximum security at the expense of performance, but I
don't think all users would want that.

Paul.

Re: PowerPC paxtest results w/ gcc-4.1

[Albert Cahalan]

On 8/16/06, Paul Mackerras <paulus@samba.org> wrote:
> Gabriel Paubert writes:

> > BTW, there is one way to make pages non executable: mark
> > them as guarded, but it will have a significant cost in
> > terms of performance.
>
> Indeed.  I guess we could do that as a config option for machines that
> really want maximum security at the expense of performance, but I
> don't think all users would want that.

On the other hand, if you want to squeeze some performance
out of the chip, turn off coherency. (probably not for SMP)

I've done it before, with a non-Linux OS. It does help.

Other tricks are to map userspace via BATs and, on the 7410
at least, to map half or all of the outermost cache memory as
a special block of high-speed memory.

Re: PowerPC paxtest results w/ gcc-4.1

[Segher Boessenkool]

> I never understood why PTE entries waste 4 bits (WIMG)
> for effectively very few valid combinations.

The only invalid combinations are WI=11 -- if you know of
a way to fit 12 combinations in fewer than 4 bits, let us
know :-)

Not all of those 12 are very useful, of course.


Segher