Non-executable mappings now in NetBSD too
bicknell at ufp.org
Sat Aug 30 16:38:11 PDT 2003
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
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 - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20030830/e15f475b/attachment.bin
More information about the freebsd-hackers