In a message written on Sun, Aug 31, 2003 at 12:06:28AM +0100, Pedro F. Giffuni wrote: > Well, we only have a JIT JVM for the i386, and on the particular case of the > i386 we cannot enforce full protection anyways so there is probably a > workaround if we do need it.
I'm not sure I want to suggest this, as I can't decide if it's a
"hack" or a good solution. I'm feeling bold though, so I'll throw
it out there. Honestly, I don't know the kernel internals enough
to know if this would eliminate the problem.
Could a new malloc (and friends) set of functions be defined, for
argument I'll call them "emalloc" that executes memory that is
executable? The JIT type apps could use that for the instructions
(and the instructions only) allowing them to be executable, and all
existing code would continue to be executable.
Seems like this would protect all existing code, and give a nice way for
the apps that need it to "label" to executable bits outright, so they
both don't loose functionality but also so the execute right is tightly
scoped.
Note, I do understand you can do this with syscall wrappers, but that
seems to introduce a performance penalty no one likes. Wrappering it in
a new malloc (sbrk?) interface to the kernel might allow the same thing
with much less penalty.
Of course, we'd need multiple platforms to make developers use it.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp00000.pgp
Description: PGP signature
