[PATCH] no-execute -- please test

[PATCH] no-execute -- please test

[Albert Cahalan]

This kernel patch implements no-execute protection (like x86 "NX bit")
for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
PowerPC processors in the 6xx, 7xx, and 7xxx families.

As given, it usually protects from executing code on the stack.
This has to do with the typical buffer overflow exploit.

I'm running this now on a Mac G4, including X, with no ill effect.

If you want to see messages when an app violates this, change
the "#if 0" to "#if 1". I get no messages except when I run
paxtest to verify that the protection works.

If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
I'd love to hear if anybody can get X to start with this change.
For me (Xorg w/ ATI) a module load fails. Probably because of
poor address space layout, paxtest shows no improvement with this.
Still, I'd love to hear if X (perhaps framebuffer and no GL) works
OK with this extra change.

Apply like this:

cd directory-with-kernel-source
patch -p1 -s -E -l < file-containing-this-email

--- 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: [PATCH] no-execute -- please test

[Paul Mackerras]

Albert Cahalan writes:

> This kernel patch implements no-execute protection (like x86 "NX bit")
> for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
> PowerPC processors in the 6xx, 7xx, and 7xxx families.

I'd be interested in benchmark comparisons with/without this patch, if
anyone cares to run lmbench, kernbench etc. with and without...  If
the performance impact is minimal I'll be happy to apply it.  If the
impact is noticeable then it might need to be selectable with a config
option.

Paul.

Re: [PATCH] no-execute -- please test

[Paul Mackerras]

Albert Cahalan writes:

> If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
> in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
> I'd love to hear if anybody can get X to start with this change.

In general I would expect dynamically-linked programs to fail unless
you compile everything with gcc -msecure-plt.

Paul.

Re: [PATCH] no-execute -- please test

[Albert Cahalan]

On 8/14/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
> > in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
> > I'd love to hear if anybody can get X to start with this change.
>
> In general I would expect dynamically-linked programs to fail unless
> you compile everything with gcc -msecure-plt.

I wouldn't, unless they are also buggy. The PLT should be
marked for full rwx permissions. Enforcing W^X is another
matter entirely of course.

For me, X is the only observed failure with that extra change.
I successfully got to a console, did a bit of exploring at the
command prompt, watched X go to the stiple background
before shutting down in an orderly fashion, and rebooted.
Perhaps do_brk could get a third argument to specify the
caller, so that VM_EXEC could be cleared for some callers.
Then again, pretending to be a Vista developer, I could just
have the kernel recognize the buggy X server.

Other notes:

For maximum benefit, shared objects should be built such
that the executable part can be mapped without any
relation to the other parts. The next best thing would be
to have the executable parts start 256 MiB above where
the other parts start. This allows randomization to be
added without causing loss of no-execute capability.

We need a new gcc default: -msecure-plt -pie -fPIE

Re: [PATCH] no-execute -- please test

[Albert Cahalan]

On 8/14/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > This kernel patch implements no-execute protection (like x86 "NX bit")
> > for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
> > PowerPC processors in the 6xx, 7xx, and 7xxx families.
>
> I'd be interested in benchmark comparisons with/without this patch, if
> anyone cares to run lmbench, kernbench etc. with and without...  If
> the performance impact is minimal I'll be happy to apply it.  If the
> impact is noticeable then it might need to be selectable with a config
> option.

There are a couple optimizations that can be done if needed.

The first is to avoid taking the initial fault on the segment
which contains the instruction pointer.

The second is to avoid cache or TLB invalidates or flushes
in certain circumstances. OpenBSD developers report that
this type of optimization is of great benefit on sparc and ppc.
It's an optimization than is only valid when no-execute is
in use, so the performance effects go both ways.

Re: [PATCH] no-execute -- please test

[Andreas Schwab]

Paul Mackerras <paulus@samba.org> writes:

> Albert Cahalan writes:
>
>> If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
>> in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
>> I'd love to hear if anybody can get X to start with this change.
>
> In general I would expect dynamically-linked programs to fail unless
> you compile everything with gcc -msecure-plt.

X (before X.org 7) does it's own module loading that cannot cope with a
non-executable heap.  X.org 7, on the other hand, uses dlopen now and
should work fine.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] no-execute -- please test

[Michel Dänzer]

On Sun, 2006-08-13 at 23:20 -0400, Albert Cahalan wrote:
> 
> If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
> in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
> I'd love to hear if anybody can get X to start with this change.
> For me (Xorg w/ ATI) a module load fails.

Which versions of the X server and driver, and which module fails to
load exactly how? As of X.Org 6.9, the X server no longer uses a custom
module loader but just dlopen and friends.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [PATCH] no-execute -- please test

[Albert Cahalan]

On 8/14/06, Michel D=E4nzer <michel@tungstengraphics.com> wrote:
> On Sun, 2006-08-13 at 23:20 -0400, Albert Cahalan wrote:
> >
> > If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
> > in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
> > I'd love to hear if anybody can get X to start with this change.
> > For me (Xorg w/ ATI) a module load fails.
>
> Which versions of the X server and driver, and which module fails to
> load exactly how? As of X.Org 6.9, the X server no longer uses a custom
> module loader but just dlopen and friends.

xorg                    1:7.0.20
xserver-xorg            1:7.0.20
xserver-xorg-core       1:1.0.2-8
xserver-xorg-video-ati  1:6.5.8.0-1

Debian's aptitude program didn't complain, and I didn't do anything
like holding back a package, so the version mismatch isn't my doing.

What calls does the old X server use to allocate the memory?
Knowing the mmap() and/or mprotect() args might help to let
the old server still work.

If dlopen() doesn't need to patch up the code, W^X could be
enforced on the new X server.

Re: [PATCH] no-execute -- please test

[Albert Cahalan]

The module failing is not actually the problem.
I get GLcore failing with a numeric error message
(grrr... like an original Mac or Amiga, or LILO)
even when things work OK.

Messages from the failing situation:

# cat Xorg.0.log.old | egrep 'EE|WW|!!|[abcdf-zA-Z]GL|gl|Gl|GL[a-zA-Z]|Chipset'
Current Operating System: Linux cube 2.6.17-rc5 #13 PREEMPT Sun Aug 13
22:06:21 EDT 2006 ppc
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(II) LoadModule: "GLcore"
(II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so
dlopen: /usr/lib/xorg/modules/extensions/libGLcore.so: undefined
symbol: __glXLastContext
(EE) Failed to load /usr/lib/xorg/modules/extensions/libGLcore.so
(II) UnloadModule: "GLcore"
(EE) Failed to load module "GLcore" (loader failed, 7)
(II) Loading extension MIT-SCREEN-SAVER
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="X.Org Foundation"
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so
(II) Module GLcore: vendor="X.Org Foundation"
(II) Loading extension GLX
(--) Chipset ATI Rage 128 Pro GL PF (AGP) found
(WW) ****INVALID IO ALLOCATION**** b: 0xf0000400 e: 0xf00004ff correcting
(EE) end of block range 0xefffffff < begin 0xf0000000
(--) R128(0): Chipset: "ATI Rage 128 Pro GL PF (AGP)" (ChipID = 0x5046)
(WW) R128(0): Video BIOS not detected in PCI space!
(WW) R128(0): Attempting to read Video BIOS from legacy ISA space!
(WW) R128(0): Video BIOS not found!
(WW) R128(0): Can't determine panel dimensions, and none specified.
(EE) R128(0): No DFP detected
(!!) R128(0): For information on using the multimedia capabilities
(WW) R128(0): Static buffer allocation failed -- need at least 19200
kB video memory
        Solid filled rectangles
        8x8 mono pattern filled rectangles
(WW) R128(0): Direct rendering disabled


Messages from when it works:

# cat Xorg.0.log | egrep 'EE|WW|!!|[abcdf-zA-Z]GL|gl|Gl|GL[a-zA-Z]|Chipset'
Current Operating System: Linux cube 2.6.17-rc5 #11 PREEMPT Sun Aug 13
19:02:53 EDT 2006 ppc
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(II) LoadModule: "GLcore"
(II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so
dlopen: /usr/lib/xorg/modules/extensions/libGLcore.so: undefined
symbol: __glXLastContext
(EE) Failed to load /usr/lib/xorg/modules/extensions/libGLcore.so
(II) UnloadModule: "GLcore"
(EE) Failed to load module "GLcore" (loader failed, 7)
(II) Loading extension MIT-SCREEN-SAVER
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="X.Org Foundation"
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so
(II) Module GLcore: vendor="X.Org Foundation"
(II) Loading extension GLX
(--) Chipset ATI Rage 128 Pro GL PF (AGP) found
(WW) ****INVALID IO ALLOCATION**** b: 0xf0000400 e: 0xf00004ff correcting
(EE) end of block range 0xefffffff < begin 0xf0000000
(--) R128(0): Chipset: "ATI Rage 128 Pro GL PF (AGP)" (ChipID = 0x5046)
(WW) R128(0): Video BIOS not detected in PCI space!
(WW) R128(0): Attempting to read Video BIOS from legacy ISA space!
(WW) R128(0): Video BIOS not found!
(WW) R128(0): Can't determine panel dimensions, and none specified.
(EE) R128(0): No DFP detected
(!!) R128(0): For information on using the multimedia capabilities
(WW) R128(0): Static buffer allocation failed -- need at least 19200
kB video memory
        Solid filled rectangles
        8x8 mono pattern filled rectangles
(WW) R128(0): Direct rendering disabled

A diff:

--- Xorg.0.log  2006-08-14 16:08:07.000000000 -0400
+++ Xorg.0.log.old      2006-08-13 22:28:40.000000000 -0400
@@ -3,7 +3,7 @@
 Release Date: 21 December 2005
 X Protocol Version 11, Revision 0, Release 7.0
 Build Operating System:Linux 2.4.25 ppc
-Current Operating System: Linux cube 2.6.17-rc5 #11 PREEMPT Sun Aug
13 19:02:53 EDT 2006 ppc
+Current Operating System: Linux cube 2.6.17-rc5 #13 PREEMPT Sun Aug
13 22:06:21 EDT 2006 ppc
 Build Date: 16 March 2006
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
@@ -11,7 +11,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 13 22:32:27 2006
+(==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 13 22:28:37 2006
 (==) Using config file: "/etc/X11/xorg.conf"
 (==) ServerLayout "Default Layout"
 (**) |-->Screen "Default Screen" (0)
@@ -788,12 +788,4 @@
 Could not init font path element /usr/share/fonts/X11/TTF/, removing from list!
 Could not init font path element /usr/share/fonts/X11/OTF, removing from list!
 Could not init font path element /usr/share/fonts/X11/CID/, removing from list!
-(II) 3rd Button detected: disabling emulate3Button
-SetGrabKeysState - disabled
-SetGrabKeysState - enabled
-SetGrabKeysState - disabled
-SetGrabKeysState - enabled
-SetGrabKeysState - disabled
-SetGrabKeysState - enabled
-SetGrabKeysState - disabled
-SetGrabKeysState - enabled
+FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should
be 1; fixing.

Re: [PATCH] no-execute -- please test

[Michel Dänzer]

On Mon, 2006-08-14 at 12:08 -0400, Albert Cahalan wrote:
> The module failing is not actually the problem.
> I get GLcore failing with a numeric error message
> (grrr... like an original Mac or Amiga, or LILO)

What more explanation than 'undefined symbol' do you need? You're not
supposed to load GLcore explicitly, it'll be loaded automatically when
needed by the glx module.


The diff between the log files doesn't show any explanation as to why it
works in one case but doesn't in the other, maybe the difference really
lies on the client side?


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [PATCH] no-execute -- please test

[Paul Mackerras]

Albert Cahalan writes:

> The first is to avoid taking the initial fault on the segment
> which contains the instruction pointer.

Good idea.

> The second is to avoid cache or TLB invalidates or flushes
> in certain circumstances. OpenBSD developers report that
> this type of optimization is of great benefit on sparc and ppc.
> It's an optimization than is only valid when no-execute is
> in use, so the performance effects go both ways.

We have a bit per page that says if the page is icache dirty or not.
On machines with no-execute support, we already avoid flushing the
page until some process first tries to execute from it.  If we
extended that to this scheme, when we made a segment executable, we
would have to find and flush all icache-dirty pages in the segment (up
to 65536 pages).  We wouldn't want to do that every time we made a
segment executable - it would need to be optimized (e.g. keep a count
per segment of icache-dirty pages in the segment).

Paul.

Re: [PATCH] no-execute -- please test

[Benjamin Herrenschmidt]

> We have a bit per page that says if the page is icache dirty or not.
> On machines with no-execute support, we already avoid flushing the
> page until some process first tries to execute from it.  If we
> extended that to this scheme, when we made a segment executable, we
> would have to find and flush all icache-dirty pages in the segment (up
> to 65536 pages).  We wouldn't want to do that every time we made a
> segment executable - it would need to be optimized (e.g. keep a count
> per segment of icache-dirty pages in the segment).

Note that we need to change the icache flush mecanism anyway as it's
always been racy on ppc32 SMP (though very few people noticed so far :)
and ppc64 SMP with < POWER3 CPUs (without N bit).

Ben.

Re: [PATCH] no-execute -- please test

[Albert Cahalan]

On 8/14/06, Michel D=E4nzer <michel@tungstengraphics.com> wrote:

> The diff between the log files doesn't show any explanation as to why it
> works in one case but doesn't in the other, maybe the difference really
> lies on the client side?

You're right. Somehow I hadn't spotted this in my syslog:

fuckup @ 1002f158 with trap 0x400 code 10000000 by x-session-manag

That is the GNOME session manager.
The /proc/*/maps file contains this:

1002f000-101dc000 rwxp 1002f000 00:00 0          [heap]

Why the heck is the heap being executed?
If this is legit, how do I recognize it?
As far as I can tell, this is not the PLT area
and anyway the PLT is marked executable.

$ file /usr/bin/gnome-session
/usr/bin/gnome-session: ELF 32-bit MSB executable, PowerPC or cisco
4500, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses
shared libs), for GNU/Linux 2.4.1, stripped

------------------- some eu-readelf stuff -----------------------
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, big endian
  Ident Version:                     1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           PowerPC
  Version:                           1 (current)
  Entry point address:               0x100077d0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          124156 (bytes into file)
  Flags:
  Size of this header:               52 (bytes)
  Size of program header entries:    32 (bytes)
  Number of program headers entries: 7
  Size of section header entries:    40 (bytes)
  Number of section headers entries: 27
  Section header string table index: 26

Section Headers:
[Nr] Name                 Type         Addr     Off    Size   ES Flags Lk I=
nf Al
[ 0]                      NULL         00000000 000000 000000  0        0  =
 0  0
[ 1] .interp              PROGBITS     10000114 000114 00000d  0 A      0  =
 0  1
[ 2] .note.ABI-tag        NOTE         10000124 000124 000020  0 A      0  =
 0  4
[ 3] .hash                HASH         10000144 000144 0017ec  4 A      4  =
 0  4
[ 4] .dynsym              DYNSYM       10001930 001930 002160 16 A      5  =
 1  4
[ 5] .dynstr              STRTAB       10003a90 003a90 00251a  0 A      0  =
 0  1
[ 6] .gnu.version         GNU_versym   10005faa 005faa 00042c  2 A      4  =
 0  2
[ 7] .gnu.version_r       GNU_verneed  100063d8 0063d8 000070  0 A      5  =
 2  4
[ 8] .rela.dyn            RELA         10006448 006448 00003c 12 A      4  =
 0  4
[ 9] .rela.plt            RELA         10006484 006484 001320 12 A      4  =
24  4
[10] .init                PROGBITS     100077a4 0077a4 000028  0 AX     0  =
 0  4
[11] .text                PROGBITS     100077d0 0077d0 0132b0  0 AX     0  =
 0 16
[12] .fini                PROGBITS     1001aa80 01aa80 000020  0 AX     0  =
 0  4
[13] .rodata              PROGBITS     1001aaa0 01aaa0 003630  0 A      0  =
 0  8
[14] .eh_frame            PROGBITS     1001e0d0 01e0d0 000004  0 A      0  =
 0  4
[15] .ctors               PROGBITS     1002e0d4 01e0d4 000008  0 WA     0  =
 0  4
[16] .dtors               PROGBITS     1002e0dc 01e0dc 000008  0 WA     0  =
 0  4
[17] .jcr                 PROGBITS     1002e0e4 01e0e4 000004  0 WA     0  =
 0  4
[18] .got2                PROGBITS     1002e0e8 01e0e8 000010  0 WA     0  =
 0  1
[19] .dynamic             DYNAMIC      1002e0f8 01e0f8 000180  8 WA     5  =
 0  4
[20] .data                PROGBITS     1002e278 01e278 00018c  0 WA     0  =
 0  4
[21] .got                 PROGBITS     1002e404 01e404 000014  4 WAX    0  =
 0  4
[22] .sdata               PROGBITS     1002e418 01e418 000018  0 WA     0  =
 0  4
[23] .sbss                NOBITS       1002e430 01e430 000118  0 WA     0  =
 0  4
[24] .plt                 NOBITS       1002e548 01e430 001368  0 WAX    0  =
 0  4
[25] .bss                 NOBITS       1002f8b0 01e430 000078  0 WA     0  =
 0  4
[26] .shstrtab            STRTAB       00000000 01e430 0000ca  0        0  =
 0  1

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz  MemSiz   Flg Align
  PHDR           0x000034 0x10000034 0x10000034 0x0000e0 0x0000e0 R E 0x4
  INTERP         0x000114 0x10000114 0x10000114 0x00000d 0x00000d R   0x1
        [Requesting program interpreter: /lib/ld.so.1]
  LOAD           0x000000 0x10000000 0x10000000 0x01e0d4 0x01e0d4 R E 0x100=
00
  LOAD           0x01e0d4 0x1002e0d4 0x1002e0d4 0x00035c 0x001854 RWE 0x100=
00
  DYNAMIC        0x01e0f8 0x1002e0f8 0x1002e0f8 0x000180 0x000180 RW  0x4
  NOTE           0x000124 0x10000124 0x10000124 0x000020 0x000020 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x000000 0x000000 RW  0x4


 Section to Segment mapping:
  Segment Sections...
   00
   01      [RO: .interp]
   02      [RO: .interp .note.ABI-tag .hash .dynsym .dynstr
.gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini .
rodata .eh_frame]
   03      .ctors .dtors .jcr .got2 .dynamic .data .got .sdata .sbss .plt .=
bss
   04      .dynamic
   05      [RO: .note.ABI-tag]
   06

Dynamic segment contains 48 entries:
 Addr: 0x1002e0f8  Offset: 0x01e0f8  Link to section: [ 5] '.dynstr'
  Type              Value
  NEEDED            Shared library: [libgnome-desktop-2.so.2]
  NEEDED            Shared library: [libgnomeui-2.so.0]
  NEEDED            Shared library: [libstartup-notification-1.so.0]
  NEEDED            Shared library: [libSM.so.6]
  NEEDED            Shared library: [libICE.so.6]
  NEEDED            Shared library: [libgnome-2.so.0]
  NEEDED            Shared library: [libesd.so.0]
  NEEDED            Shared library: [libgtk-x11-2.0.so.0]
  NEEDED            Shared library: [libgdk-x11-2.0.so.0]
  NEEDED            Shared library: [libatk-1.0.so.0]
  NEEDED            Shared library: [libgdk_pixbuf-2.0.so.0]
  NEEDED            Shared library: [libXrandr.so.2]
  NEEDED            Shared library: [libpango-1.0.so.0]
  NEEDED            Shared library: [libX11.so.6]
  NEEDED            Shared library: [libbonobo-2.so.0]
  NEEDED            Shared library: [libgconf-2.so.4]
  NEEDED            Shared library: [libbonobo-activation.so.4]
  NEEDED            Shared library: [libORBit-2.so.0]
  NEEDED            Shared library: [libgobject-2.0.so.0]
  NEEDED            Shared library: [libpthread.so.0]
  NEEDED            Shared library: [libglib-2.0.so.0]
  NEEDED            Shared library: [libwrap.so.0]
  NEEDED            Shared library: [libc.so.6]
  NEEDED            Shared library: [libXau.so.6]
  INIT              0x100077a4
  FINI              0x1001aa80
  HASH              0x10000144
  STRTAB            0x10003a90
  SYMTAB            0x10001930
  STRSZ             9498 (bytes)
  SYMENT            16 (bytes)
  DEBUG
  PLTGOT            0x1002e548
  PLTRELSZ          4896 (bytes)
  PLTREL            RELA
  JMPREL            0x10006484
  RELA              0x10006448
  RELASZ            4956 (bytes)
  RELAENT           12 (bytes)
  VERNEED           0x100063d8
  VERNEEDNUM        2
  VERSYM            0x10005faa
  NULL
  NULL
  NULL
  NULL
  NULL
  NULL

Version needs section [ 7] '.gnu.version_r' contains 2 entries:
 Addr: 0x100063d8  Offset: 0x0063d8  Link to section: [ 5] '.dynstr'
  000000: Version: 1  File: libpthread.so.0  Cnt: 1
  0x0010: Name: GLIBC_2.0  Flags: none  Version: 3
  0x0020: Version: 1  File: libc.so.6  Cnt: 4
  0x0030: Name: GLIBC_2.3  Flags: none  Version: 6
  0x0040: Name: GLIBC_2.2  Flags: none  Version: 5
  0x0050: Name: GLIBC_2.1  Flags: none  Version: 4
  0x0060: Name: GLIBC_2.0  Flags: none  Version: 2

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

Re: [PATCH] no-execute -- please test

[Albert Cahalan]

On 8/14/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > This kernel patch implements no-execute protection (like x86 "NX bit")
> > for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
> > PowerPC processors in the 6xx, 7xx, and 7xxx families.
>
> I'd be interested in benchmark comparisons with/without this patch, if
> anyone cares to run lmbench, kernbench etc. with and without...  If
> the performance impact is minimal I'll be happy to apply it.  If the
> impact is noticeable then it might need to be selectable with a config
> option.

With no special effort at optimization, the patch appears to be harmless.
Actually most things are a tad faster, which is entirely illogical.
I must have gotten lucky with the cache.

Note that lmbench sucks. It won't compile out of the box. The Debian
package is unavailable for PowerPC, and anyway places files in all
sorts of unusual and annoying root-only locations. One of the tests
gets SIGSEGV while trying to do Sun RPC. The nice summary report
contains no data. I did find the raw results after digging around in
various directories though.

Before:

Simple syscall: 0.3180 microseconds
Simple read: 1.1413 microseconds
Simple write: 1.0040 microseconds
Simple stat: 5.5255 microseconds
Simple fstat: 1.6198 microseconds
Simple open/close: 8.3318 microseconds
Select on 10 fd's: 2.3284 microseconds
Select on 100 fd's: 18.2500 microseconds
Select on 250 fd's: 45.2063 microseconds
Select on 500 fd's: 89.6290 microseconds
Select on 10 tcp fd's: 2.6409 microseconds
Select on 100 tcp fd's: 31.1889 microseconds
Select on 250 tcp fd's: 79.1831 microseconds
Select on 500 tcp fd's: 160.2571 microseconds
Signal handler installation: 1.5846 microseconds
Signal handler overhead: 7.8899 microseconds
Protection fault: 0.7714 microseconds
Pipe latency: 24.4466 microseconds
AF_UNIX sock stream latency: 34.4834 microseconds
Process fork+exit: 671.3750 microseconds
Process fork+execve: 2417.0000 microseconds
Process fork+/bin/sh -c: 10904.0000 microseconds
File /tmp/XXX write bandwidth: 25636 KB/sec
Pagefaults on /tmp/XXX: 3.9404 microseconds

After:

Simple syscall: 0.3179 microseconds
Simple read: 1.1355 microseconds
Simple write: 0.9964 microseconds
Simple stat: 5.5497 microseconds
Simple fstat: 1.6473 microseconds
Simple open/close: 8.0965 microseconds
Select on 10 fd's: 2.3278 microseconds
Select on 100 fd's: 18.0789 microseconds
Select on 250 fd's: 44.1440 microseconds
Select on 500 fd's: 88.1935 microseconds
Select on 10 tcp fd's: 2.6399 microseconds
Select on 100 tcp fd's: 30.8939 microseconds
Select on 250 tcp fd's: 77.5070 microseconds
Select on 500 tcp fd's: 156.3438 microseconds
Signal handler installation: 1.5741 microseconds
Signal handler overhead: 7.8997 microseconds
Protection fault: 0.8085 microseconds
Pipe latency: 24.2050 microseconds
AF_UNIX sock stream latency: 33.7037 microseconds
Process fork+exit: 656.6250 microseconds
Process fork+execve: 2392.3333 microseconds
Process fork+/bin/sh -c: 10454.0000 microseconds
File /tmp/XXX write bandwidth: 25911 KB/sec
Pagefaults on /tmp/XXX: 3.6414 microseconds

Right now I have the code doing printk() rather than killing processes
that misbehave, and I'm doing something about the heap too. It seems
that GNOME things like to execute the heap, while non-GNOME things
do not. Perhaps libORBit is at fault. Things that execute the heap
include:

abiword
firefox-bin
gedit
gimp
gnome-panel
gnome-settings-
gnome-vfs-daemo
metacity
x-session-manag

Apps that behave well include xterm, xcalc, and xli.

I haven't found anything unusual in the ELF section flags. Both libORBit
and libX11 (which is fine) have flags like this:

[ 7] .rela.plt RELA   000138e4 0138e4 001824 12 A   2 23 4
[22] .sbss     NOBITS 000f2f34 0e2f34 000140  0 WA  0  0 4
[23] .plt      NOBITS 000f3074 0e2f34 00186c  0 WAX 0  0 4
[24] .bss      NOBITS 000f48e0 0e2f34 000328  0 WA  0  0 4

Firefox is less than a month old. It's newer than xterm.