Re: PowerPC paxtest results w/ gcc-4.1

["Albert Cahalan" <acahalan@gmail.com>]

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.