pageexec@freemail.hu wrote:
> 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.

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

>>>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 know why they are bad.  But they

>>>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).

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

>>>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.

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

>>> 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).

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.
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.