Scribit Marcus Brinkmann dies 08/01/2007 hora 00:51: > I don't think so. The effect of the proposal is intended to be the > following: Pages can be "tagged" so that they can be made opaque by > certain designated (and thus authorized) subsystems only. Ownership > of the resource remains within the party who did the tagging. I think > that this description catches the main idea.
So basically you introduce the opaque memory but only some parts of the system can use it. How will they be differentiated, and how will it be extensible? If it is, what will prevent the system to be configured so that anyone can use it? What I don't understand in your proposal is that it looks like "I don't want opaque memory, but I need it, so I'll use it and pretend it's not there". The net effect is that if someone wants to use opaque memory to do the harm you want to make impossible, it seems to me that his task to make it possible will be quite simple. Even if the discrimination between services that are able to use opaque memory and services that can't is hardwired into Hurd's source code in a way that prevents any extensibility that could be used to bypass that protection, it will be a matter of recompiling the kernel or the space bank, and the resulting "harmful" one could be transparently used in place of the "harmless" one[1]. And patches to do so would probably be very easy to manage and keep up-to-date. I don't agree with the transparent memory design, but it could probably make it really harder to run undebuggable proprietary software on Hurd. On the other hand, I don't see what your restricted opaque memory can really achieve, apart from making the Hurd less powerful than what it could be (or powerful, but with a power a bit less easy to use). Doubtfully, Pierre [1] except if you design a tivoized Hurd with the help of the TC technology, which I really doubt you would ;-) -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
