|To:||Ralf Baechle <email@example.com>|
|Subject:||Re: 2.4 kernels + >=binutils-126.96.36.199.8|
|From:||Tiago Assumpção <firstname.lastname@example.org>|
|Date:||Tue, 09 Mar 2004 12:12:53 -0300|
|References:||<404D0132.email@example.com> <20040308234450.GF16163@rembrandt.csv.ica.uni-stuttgart.de> <404D0A18.firstname.lastname@example.org> <20040309003447.GH16163@rembrandt.csv.ica.uni-stuttgart.de> <404D1909.email@example.com> <20040309040919.GA11345@linux-mips.org>|
Yes, MIPS has no execution control flag in page-level.|
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?
7D9A A6BA 8275 964E EF47
EE5A 7AFF C759 B578 ACAA
At 01:09 9/3/2004, you wrote:
On Mon, Mar 08, 2004 at 08:08:25PM -0500, Kumba wrote:
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: 2.4 kernels + >=binutils-188.8.131.52.8, Kumba|
|Next by Date:||Re: 2.4 kernels + >=binutils-184.108.40.206.8, Ralf Baechle|
|Previous by Thread:||Re: 2.4 kernels + >=binutils-220.127.116.11.8, Kumba|
|Next by Thread:||Re: 2.4 kernels + >=binutils-18.104.22.168.8, Ralf Baechle|
|Indexes:||[Date] [Thread] [Top] [All Lists]|