Brian Foster wrote:
Andrew,
As far as I am aware, XI is part of the SMARTMIPS extension,
and I _think_ SMARTMIPS is only implemented by the 4KS cores?
That is correct, though there has long been interest in having XI/RI as
an option
for non-SmartMIPS cores and I would not be surprised if sooner or later it
became more generally available.
Whilst other companies have licensed that core from MIPS, to
the best of my knowledge the SoC I'm concerned with (Innova
Card's USIP Pro) is the only one running Linux. So I suspect
you're quite correct: Nothing's been done.
I believe that there is at least one other 4KS-family customer working with
Linux, but they haven't been nearly as active as InnovaCard. I had some
email exchanges with someone who was working on their kernel a couple
of years back about this very topic. Indeed, I thought that they submitted
some patches for basic RI/XI support at one point. Scan the linux-mips.org
archives, if they survived the rehosting.
I've been in contact with the PaX people, and they inform me
"the experimental NX tweaks [ for MIPS ] didn't get anywhere
due to lack of time/interest of the guy who started it."
The "market segment" USIP is aimed at is sufficiently touchy
about security I currently believe it's plausible (assuming
it's technologically possible) to simply forbid (not support)
concurrently executable-and-writable memory. As such, certain
programs won't work. Tough. There's no call to support the
(broken) JVM's et al. that "require" it, and I'm hoping that
nested C/C++ functions are rare (ideally non-existent in the
code which normally runs on USIP). It'd be nice if such code
either fails to compile and/or fails to link/load, but that's
some (highly useful) porcelain.
Broadly, what I'm trying to say is I don't want to touch gcc
(and/or binutils) and am unconvinced I have to. But I'm very
much open to correction here!
The x86 (including amd64) and, AFAIK, SuperH (sh) Linux kernels
now support NX or equivalent; indeed, a test on my 2.6.22(-ish)
amd64 workstation (Kubuntu 7.10) has a non-executable stack.
As such, those could be a model worth studying/following, but
I understand they have support for specially-marked binaries to
have executable stacks (i.e., binutils/gcc mods, which I want to
avoid).
Well, strictly speaking, you wouldn't actually *need* to modify binutils
to make specially tagged binaries. You could borrow an unused bit in
the ELF header somewhere, have the kernel recognize it, and write your
own little tool that only turns that bit on/off in an ELF file. In the
longer
term, I'd argue that if there's support for appropriate binary tagging in
the x86 tools, that support should simply be enabled for MIPS targets
and any other non-x86 archiectures with such support (e.g. Alpha, if
anyone still uses them).
Regards,
Kevin K.
