From: John Richard Moser <nigelenki@comcast.net>
To: Arjan van de Ven <arjan@infradead.org>
Cc: linux-kernel@vger.kernel.org, ubuntu-hardened@lists.ubuntu.com
Subject: Re: Collecting NX information
Date: Mon, 28 Mar 2005 14:14:56 -0500 [thread overview]
Message-ID: <424857B0.4030302@comcast.net> (raw)
In-Reply-To: <1112036121.6003.46.camel@laptopd505.fenrus.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
> On Mon, 2005-03-28 at 13:50 -0500, John Richard Moser wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>
>>Arjan van de Ven wrote:
>>
>>>>As I understand, PT_GNU_STACK uses a single marking to control whether a
>>>>task gets an executable stack and whether ASLR is applied to the
>>>>executable.
>>>
>>>
>>>you understand wrongly.
>>>
>>>PT_GNU_STACK just sets the exec permission for the stack (and the heap
>>>now mirrors the stack). Nothing more nothing less.
>>>
>>
>>So then this would be slightly more useful than I had previously
>>thought, bringing control over the randomization as well?
>
>
> actually Linus was really against adding non-related things to this
> flag. And I think he is right...
>
I'm not interested in altering and hacking up PT_GNU_STACK; PT_PAX_FLAGS
already supplies enough to do what I want. My goal is to have
PT_PAX_FLAGS code in mainline and Exec Shield, so that if it exists in
the binary it will be used; else PT_GNU_STACK will be fallen back to.
> Now.. do you have any examples of when you want a binary marked for no-
> randomisation ?? (eg something the setarch flag won't fix/won't be good
> enough for)
What's setarch do for one? Anyway, ASLR has been known to break some
things. Blackdown Java used to break IIRC; also there's the poorly
designed Oracle and the poorly designed solution of Oracle on a 32 bit
platform; and of course there's Emacs, which I heard was broken due to
Exec Shield's randomization. Temporary work-arounds are sometimes needed.
Remember also that I'm not just trying to make a more robust setting for
ES and mainline; I'm trying to find a way to make it so that
distribution maintainers can set one set of flags and have it assure
that the program works in Mainline, Exec Shield, and PaX. Just a little
less work for the distribution maintainers, which I think would be a
good thing considering that apparently Ubuntu Linux might support both
PaX and Exec Shield in the future, if I'm reading this[1] right.
[1] http://thread.gmane.org/gmane.linux.ubuntu.devel/6130
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSFeuhDd4aOud5P8RApQ+AKCPtp5b4/2rw+aRqEUg7r1FlphmQwCfX3Io
FUNq9xZlDsoo1poGBo5+zus=
=v0dv
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2005-03-28 19:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-28 18:21 Collecting NX information John Richard Moser
2005-03-28 18:37 ` Arjan van de Ven
2005-03-28 18:50 ` John Richard Moser
2005-03-28 18:55 ` Arjan van de Ven
2005-03-28 19:14 ` John Richard Moser [this message]
2005-03-28 20:54 ` [ubuntu-hardened] " Brandon Hale
2005-03-28 22:17 ` John Richard Moser
2005-03-29 7:16 ` Arjan van de Ven
2005-03-29 7:53 ` John Richard Moser
2005-03-29 8:09 ` Arjan van de Ven
[not found] ` <424911FF.1080702@comcast.net>
2005-03-29 8:46 ` Arjan van de Ven
[not found] ` <42499C40.5030202@comcast.net>
[not found] ` <1112121756.6282.88.camel@laptopd505.fenrus.org>
[not found] ` <4249A78A.1040407@comcast.net>
2005-03-29 19:34 ` Arjan van de Ven
2005-03-29 20:41 ` John Richard Moser
2005-03-29 8:45 ` John Richard Moser
2005-03-29 8:15 ` John Richard Moser
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=424857B0.4030302@comcast.net \
--to=nigelenki@comcast.net \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ubuntu-hardened@lists.ubuntu.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.