On 18 Dec 2005 at 12:04, Elad Efrat wrote:
> Matt Thomas wrote:
> 
> > Some architectures (powerpc) have ABIs that mandate executable bss/data.
> > There is no way to turn that off.
> 
> True, but two things:

actually, half-true. the ABI in question i guess is that of SysV, and
it has some sillyness in it (blrl in GOT[-1] that's not even marked as
executable...). the bigger problem is that it's runtime generated
(like many other archs), and that's the security problem. recognizing
this, some folks at Red Hat earlier this year had developed a better
mechanism they call secureplt, it's available for ppc and alpha already,
and similar can (and should) be implemented on other archs as well
(an item that's been also on my todo list for too long). see [1]-[4]
for more info.

> > If you have textrel relocations, you have to allow this. 
> 
> True. However, PaX is aware of text relocations, and addresses them.

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 think the
> > right way to have add a PROT_LOCKED that mprotect can understand.  If
> > this is supplied, the protection on such pages can't be downgraded.
> > munmap would still be allowed (it might be advisable to make munmap
> > change the region to PROT_NONE but leave it in place so it can't be
> > remapped.)

a better (more generic) way would be to extend mmap/mprotect to be
able to specify what becomes maxprot, in addition to prot, so that
after textrels (or any kind of runtime code generation) are done,
userland can revoke maxprot bits, effectively sealing the protection
on those pages. this requires userland changes (in ld.so at least),
so i didn't implement it in linux this way, instead some heuristics
is used in the kernel to do the same (this is just FYI, you can do
it the proper way in NetBSD as you control userland as well).

> > The program itself is linked at a base address.

FYI, it has always been possible to create executables in the ET_DYN
ELF format and have them load at random addresses, i've done this more
than 4 years ago under linux, and for something like 2 years now Red
Hat added official toolchain support for it. they call it PIE (as in,
Position Independent Executable), and it's available in gcc 3.3+ and
binutils 2.15+. of course your kernel's ELF loader has to support
ET_DYN executables as well, which afaik, it doesn't at the moment.

> >  the libraries and stacks
> > could be vary but on machines with virtual caches, that might be very painful.

since this virtually indexed cache problem came up more than once, i'd
like to ask what exactly you're referring to. i assume that it's something
to do with address space switches and avoiding cache flushes (someone also
mentioned TLB, but i don't see how that figures in here), but i need some
insights as to what you see as a problem. be as technical as you can be
(pointers to code are appreciated, i'm not too familiar with UVM and pmaps).

more comments in other followups.

[1] http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01134.html
[2] http://sources.redhat.com/ml/binutils/2005-05/msg00391.html
[3] http://sources.redhat.com/ml/binutils/2005-05/msg00736.html
[4] http://sources.redhat.com/ml/libc-alpha/2005-05/msg00090.html
[5] http://people.redhat.com/drepper/dsohowto.pdf