And agreed, yet I nor PaX team see a way to make MIPS fully supported by PaX
-- if I'm not wrong, at the moment MIPS boards are only supported by ASLR.
I see that MIPS has split TLB's, which can not be distinguished by software
level in another hand. Thus when a page-fault occours I don't see how a piece
of (non-microcoded) exception handler can get aware whether the I-Fetch is being
done in original ``code area'' or as an attempt to execute injected payload in
a memory area supposed to carry only readable/writeable data.
Plus JTLB's holding data and code together in the address translation cache.
Plus situations like kseg0 and kseg1 unmaped translations, which would occour
outside of any TLB (having virtual address subtracted by 0x80000000 and
0xA0000000 respectively to get physiscal locations) making, as you mentioned,
only split uTLB's (not counting kseg2 special case). But PaX wants to take care of
kernel level security too.
Even MIPS split cache unities (which can be probed separately by software) wouldn't
make the approach possible since if you have a piece of data previously cached in
D-Cache (load/store) the cache line would need to suffer an invalidation and the
context to be saved in the I-Cache before the I-Fetch pipe stage succeeds.
Indeed, execution protection (in a general way) does not require split TLB.
Other solutions designed and implemented by PaX are SEGMEXEC (using specific
segmentation features of x86 basead core's) and MPROTECT. The last one uses
vm_flags to control every memory mapping's state, ensuring that these never hold
VM_WRITE | VM_MAYWRITE together with VM_EXEC | VM_MAYEXEC. But as the
solution becomes more complex it also tends to gain more issues. First of all, this
wouldn't be as simple and ``automatic'' as per page control. Another point is that this
solution wouldn't prevent kernel level attacks so, among others, any compromise in
this level could lead to direct manipulation of a task's mappings flags. At the end
a known problem is an attacker who is able to write to the filesystem and to request
this file to be mapped in memory as PROT_EXEC. In other words: yes it is possible to
achieve execution protection in other ways, but not as precise as page-level.
If anybody has an idea of how to design and implement such solution on MIPS computers
I'd really like to hear it.
http://pax.grsecurity.net for further information.
PS.: Kumba, I'd like to have a copy of your kernel image to take a look,
could you please send it to me?
Best regards,
Tiago Assumpcao
module@whatever.org.ar
7D9A A6BA 8275 964E EF47
EE5A 7AFF C759 B578 ACAA
http://whatever.org.ar/~module [/myself.asc]
At 01:09 9/3/2004, you wrote:
On Mon, Mar 08, 2004 at 08:08:25PM -0500, Kumba wrote:
> Hmm, well, The readelf -l and -S output from a 2.14.90.0.7-based
> cross-compiler is attached, along with -l & -S outout from the
> 2.15.90.0.1.1 (--version reports 2.15.90.0.1) as well for comparison.
>
> The PAX_FLAGS bit comes from a patch added in gentoo for PaX support in
> binaries. More info on PaX is at http://pax.grsecurity.net. I'm going
> to rebuild my kernel cross-compiler without that one patch and see what
> the results are.
PAX can't be fully supported on MIPS anyway; the architecture doesn't
have a no-exec flag in it's pages.
PAX docs are bullshit btw. execution proection doesn't require a split TLB
and anyway, the MIPS uTLBs are split.
Ralf
