On Tue, Mar 09, 2004 at 12:12:53PM -0300, Tiago Assump??o wrote: > 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. In a TLB reload handler you can distinguish betwen instruction and TLB fault by comparing the fault address in badvaddr with the EPC value. That gives you non-exec protection for anything that doesn't already reside in the TLB. There is still one spare bit in the pagetables which you can use as the exec permission bit. So if I-fetch && !exec_bit -> SIGILL or something like that. The usual warning applies - any modification to the TLB code is going to have extreme performance impact (a nop in the TLB reload handler will cost about 0.5% of some benchmarks) and any attempts to execute code that is already mapped will be missed. Another better-than-nothing idea would be poisoning the I-cache by pre-loading it. Exploits probably don't flush the cache first so the resulting I-cache non-coherence may crash the process instead. Like the previous idea this is performance intrusive and also a very dirty solution. > 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. Okay, this paragraph was somewhat hard to understand so my comment may be a bit off ... All that's required is writing back data to memory or in cache of Alchemy processors or uncached area not even that. So chances that exploit code actually works without having performed a cacheflush are actually fairly good. > 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 In the end anything less than per-page control is pretty inflexible. > 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. Okay, but that's outside the scope of what no-exec should attempt to do. > If anybody has an idea of how to design and implement such solution on MIPS > computers You could try to run the mapped kernel in supervisor mode. Again lots of performance implications. Ralf
