linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Albert Cahalan" <acahalan@gmail.com>
To: "Paul Mackerras" <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org,
	debian-powerpc <debian-powerpc@lists.debian.org>
Subject: Re: PowerPC paxtest results w/ gcc-4.1
Date: Sun, 13 Aug 2006 00:11:19 -0400	[thread overview]
Message-ID: <787b0d920608122111p79f29d74r600382658599cd63@mail.gmail.com> (raw)
In-Reply-To: <17630.39716.551115.850057@cargo.ozlabs.ibm.com>

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]

  reply	other threads:[~2006-08-13  4:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-12  5:50 PowerPC paxtest results w/ gcc-4.1 Albert Cahalan
2006-08-12 11:35 ` Paul Mackerras
2006-08-12 14:36   ` Albert Cahalan
2006-08-12 23:54     ` Paul Mackerras
2006-08-13  2:48       ` Albert Cahalan
2006-08-13  3:23         ` Paul Mackerras
2006-08-13  4:11           ` Albert Cahalan [this message]
2006-08-13 16:45             ` Hollis Blanchard
2006-08-13 18:59               ` Albert Cahalan
2006-08-14 12:17             ` Matt Sealey
2006-08-14 14:20               ` Kumar Gala
2006-08-13  3:29       ` Alan Modra
2006-08-13 18:56       ` Albert Cahalan
2006-08-14 11:50       ` Matt Sealey
2006-08-15  3:59         ` Paul Mackerras
2006-08-16 10:59           ` Gabriel Paubert
2006-08-16 11:07             ` Paul Mackerras
2006-08-16 14:43               ` Albert Cahalan
2006-08-16 17:49             ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=787b0d920608122111p79f29d74r600382658599cd63@mail.gmail.com \
    --to=acahalan@gmail.com \
    --cc=debian-powerpc@lists.debian.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).