Re: [PATCH DNA 5/6] tools/xenstored: restore support for mapping ring as foreign memory

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Sep 20, 2021 at 10:24:45AM +0200, Juergen Gross wrote:
> On 17.09.21 17:46, Roger Pau Monne wrote:
> > Restore the previous way of mapping the xenstore ring using foreign
> > memory. Use xenforeignmemory instead of libxc in order to avoid adding
> > another dependency on a unstable interface.
> 
> Mapping a guest page via xenforeignmemory is no good move IMO. A guest
> not supporting a grant table for security reasons is a rather strange
> idea, as it needs to trade that for a general memory access by any
> backend without a way to restrict such accesses. This contradicts one
> of the main concepts of the Xen security architecture.

I've done this in order to be able to assert that the switch to
disable grant tables was working correctly, I don't intended this
specific mode to be something that is desirable or that should be used
in production, but I do think it's useful to be able to create such
guests in order to assert that the option is taking effect.

The main problem of xenstore not being correctly initialized on a
domain is that the "@introduceDomain" watch doesn't fire, and thus
other components don't get notified of the newly created domain.

This seems to be a limitation of the current design, where the only
way to get notifications of new domain creation is using
"@introduceDomain", even when the caller doesn't care of whether the
created domain as a working xenstore connection.

Maybe I can workaround this differently in xenstore, so that the watch
fires even when the shared xenstore ring cannot be initialized.

Thanks, Roger.