I think it ought to be possible to create a machine description of any
interdomain protocol including the guarantees provided by all the
parties. The combination of xenstore, xen and the parties involved can
then police that the protocol is observed.
The policing has to be designed such that it can't be subverted so xen
must provide the foundation but as little as possible. Xenstore
provides the trusted configuration information to xen to configure the
primitives (for example, xenstore holds the reference to the correct
machine description of the protocol). Then the front-end and back-end
try to use the protocol. If the FE or the BE detect a protocol
violation, the primitives are sufficient to be able to reliably
distinguish which party was in error so it can be forcibly reset.
We might want to be able to detect and reset in the case when one or
both parties are in error but neither complain too.
I think I spent about 2 mins on this with Ian about a year ago.
This is what you are saying above except that I'd want to do it without
embedding any protocol specific knowledge in the tools apart from a
protocol description file for each supported protocol.
So, in my version xenstore doesn't have any high-level semantic
understanding of the protocols, just a generic mechanism for handling
any protocol.
I certainly didn't mean to imply that this had to be a part of
xenstore itself. But yes, I think we both agree. In short, some
policy enforcement foo could sit along-side xenstore and validate the
way it is used to allow interdomain comms. This foo could be largely
be based on access control checks of access to xenstore (creating
keys/directories, adding watches, etc.). If this foo was actually the
system-wide policy engine, it could use things that it sees happening
in the store to admit lower-level operations.
So basically, the xenstore++ is in a stripped down secured domain and
someone with role-based access privileges communicates with xenstore++
to connect a resource to a domain. Xenstore++ checks the permissions
and sets up the connection where the protocol description to use is an
attribute of the resource class. The protocol is policed and if it's
violated then either the resource provider (BE) or consumer (FE) or both
get blown away.
Sounds good. Although, as we've both posited above, xenstore doesn't
really need to change except to have some AC checks and to be broken
off into a stub domain. And the stub domain is really bonus points at
this stage, as a lot of what we're discussing could proceed in
parallel with disaggregation.
Your points about resource colouring are interesting, but I think they
may a few steps down the road. Once two VMs are allowed to do shared
memory communication it's a little moot as to what they are using it
for -- disk/net/sweet nothings -- so the real benefit to AC in
xenstore is in tool-independent per-resource admission control, and
making sure that VMs follow established driver protocols. (This
facility would be generally useful as a means of shaking out split
driver protocol bugs too by the way. ;) )
Getting back to Reiner's point about block AC checks in the backend
drivers: I think that if you trust the backend code sufficiently to
_have_ the AC check in the first place, then you trust it implicitly
to make correct use of page sharing etc. So why not implement the
tests for (a) permission to talk to the specified frontend, and (b)
permission for that frontend to talk to the specified disk at the
store level (which is where the two drivers are negotiating things
anyway), and just use existing in-hypervisor AC mechanisms to control
whether the backend is allowed to map the comms page and connect event
channels.
a.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home