Hello,

 The MIPS 4KSd core (at least) implements an XI (eXecute Inhibit)
 page protection bit.  XI is similar to the NX (No Execute) bit
 in the more recent AMD/Intel x86 families:  Attempts to I-fetch
 from a page with XI set cause an exception.

 I've been asked to look into the possibility/difficulty of adding
 support for XI to MIPS-Linux (at least for the 4KSd core), for
 both kernel-mode and user-land.  An admittedly very quick check
 of 2.6.25(-ish) suggests there is no support at all, at present,
 for XI for any MIPS core/configuration.  Nor has a search of the
 'Net found much of anything, with the possible exception of the
 PaX and grsecurity projects.

 Of course, I don't want to repeat work which has already been done.
 Has anyone studied adding, or better yet, already (tried to?) added,
 any support for XI?

 *Speculating*, and with the caveat I'm not completely up on MIPS
 TLB/memory-management/caches, I don't see kernel-mode as too much
 of an issue.  There's no (known to me) cases of code-in-data/stack?
 Whilst I know bugger-all about module loading/unloading, I rather
 doubt there's anything too tricky going on there?

 User-land is clearly more difficult due to the `sigreturn' and FPU
 emulation trampolines, which reside in user-land stack.  At the
 moment I am presuming a `vsyscall'-page scheme solves that problem,
 but have not researched the issue (esp. the FPU emulation) closely.
 A `vsyscall' which just contains the trampolines doesn't sound too
 difficult; but if you add to that (which I am NOT proposing!) the
 optimization of volatile time-of-day data (RO to user-land, RW to
 kernel-mode), then there would seem to be issues/gotchas with MIPS
 caching and/or page-protection?

 Does `gcc' for MIPS generate any trampolines in the stack/data?
 I keep seeing hints that `gcc' does in certain unspecified cases
 and/or architectures, but am at a lost just what is being talked
 about.  Wikipedia suggests this only happens in (some?) cases of
 nested functions; as such, for C, they don't seem necessary and
 my initial inclination is say "don't use 'em!".

 I'm hoping to be able to avoid any support at all for executable
 stacks:  I want all user-land code to have XI-set stacks.  This is
 partly for simplicity (I presume), but also because the target is
 the the "secure" embedded world, where simply being able to assert
 you cannot, never, execute code in the stack (or in data) is much
 easier to pass muster with various certification authorities and
 testing laboratories.  (PCI-PED is the area of immediate interest
 here.)  I'm aware mprotect(2), at the least, is an issue, because
 it can be used to set a page to be both writable and executable.
 (Hence, more generally, I want to be able to assert that no memory
 with the exception of kseg0/kseg1, is ever concurrently writable
 and executable.)

 Advice, suggestions, pointers, comments are very welcome.

cheers!
       -blf-

-- 
"How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools." |      http://www.stopesso.com