Hm. Maybe the answer to this is to simply not expose inherited
mappings via the syscall (which is the only way the process knows
about the mappings). In which case, the code is there but it isn't
used, and the process has to do the normal linking and mapping. It
just loses some of it's available VM space.
Would that work? It would mean we could preserve the global TLB
entry. But if it doesn't, like you say, we just lose the global TLB,
which isn't a big deal.
BTW: a simple munmap(2) would still unmap an inherited mapping. So you
could even leave the responsibility of security issues to
user-space. Just as now LD_* environment variables are scrubbed for
setuid programmes (by user-space), inherited mappings could be
unmapped as well. I'm not necessarily advocating this approach, just
pointing out the possibility.
Also, you could have root-created inheritable mappings retained even
for setuid. This would mean that the global TLB is still useful for
such programmes. Just another idea.
But all these things seem to be minor details to me. It seems to me
that the basic idea of inherited mappings is simple, and allows us to
have shared code. Separate from that, we can have shared data.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/