Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross <jgross@xxxxxxxx>]

On 07/12/16 18:00, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: Xenstore domains and XS_RESTRICT"):
>> On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
>>> There is no socket connection to xenstore domain.
>>
>> Right but it creates its own XenStore ring. Can it send this xsd_sockmsg
>> with domid_id of zero? Or are you saying this is irrelevant becasue
>> what you are interested is for the Linux kernel to filter certain
>> xsd_sockmsg so it won't do something silly?
> 
> The latter.
> 
>> OK, so this all sounds like the OS needs to mediate access? Sorry for
>> being so dense this morning.
> 
> The OS already needs to mediate access for all xenstore commands.  The
> kernel xenbus driver has a list of the commands.  Some of them it will
> "simply" proxy, translating request id and transaction fields, as
> applicable.  Some of them it does something special for.  Unknown
> commands are rejected.

Sorry, this isn't true. There is special handling for watch/unwatch and
transaction start/end. There is no other command filtering involved,
especially no rejection of unknown commands.

> 
>> This would imply that the kernel driver would need to understand
>> the format and disallow the XS_RESTRICT under certain conditions?
> 
> There should be a way to tell the kernel driver that the connection
> should be restricted.  XS_RESTRICT is as good as any.
> 
> But the XS_RESTRICT command must not be forwarded by the kernel proxy
> to the real xenstore.  Rather, the driver must make an annotation in
> its client struct instead.
> 
> That annotation should result in _every_ proxied xenstore command,
> from that client, being decorated so as to specify the restriction
> domain.
> 
> There needs to be an extension to the xenstore protocol to support
> this.

Right.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel