Re: 2.4 kernels + >=binutils-2.14.90.0.8

[Tiago Assumpção <module@whatever.org.ar>]

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?



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