Subject: Re: Importing PaX features to NetBSD
To: Matt Thomas <>
From: None <>
List: tech-security
Date: 12/18/2005 23:21:21
On 18 Dec 2005 at 13:49, Matt Thomas wrote:

> I know about secureplt.  But that doesn't help for backwards compatibility.

secureplt doesn't as it wasn't designed for that. however i'm not sure
if it's impossible to come up with a way that can be used on non-recompiled
binaries as well. some years ago when i looked at sparc, i could think of
ways to avoid runtime plt stub generation for binaries that weren't designed
for it, maybe it's possible for ppc and others as well. in any case, this
is just a tangent on how you deploy non-executable pages, not about whether
we (well, you) need/want it or not. if you want to keep ppc use executable
bss/data/heap/whatever, so be it, that should surely not affect other archs
that can do with the non-executable variant.

> > if you have textrels, it's best to fix them. see [5] why they're bad,
> > especially for security (basically, they need the privilege for runtime
> > code generation).
> I know why they are bad.  But they

i think something's missing here?

> That's an ABI change (if you are talking extra arguments).  Otherwise
> it reduces down to the same thing as my proposal.

i was thinking of extra flags passed in along with prot or flags,
similar to your proposal, but the difference is that i'd allow more
fine grained control over the protection bits, feels a bit more
unix-like to me, but it's a detail i'll let you guys work out ;-).

> PIE?  Ewww. :)  PIE was primarily intended for small embedded systems.

i think you're mixing it up with something else, PIE was explicitly
created to address the main executable randomization problem [1]:

"This option creates something between a shared library and normal
executable, which can be used for security exposed binaries so that their
base address can be randomized (either a constant address different on
each box through prelink -R (support for PIEs in prelink will be comming),
or totally random address)."

> Some machines require all mappings of a physical page be to compatible virtual
> addresses where the low N (16-24) bits have same value.  That retricts where
> you can map a page in the virtual address space.

oh, this problem, now i see it. and it's not a problem at all, as it
is already taken into account (speaking of PaX/linux), randomization
simply does not affect these bits.