Re: [Xen-devel] [PATCH 15/25] argo: implement the sendv op

[Christopher Clark <christopher.w.clark@xxxxxxxxx>]

On Fri, Jan 4, 2019 at 5:37 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
> >>> On 04.01.19 at 09:13, <christopher.w.clark@xxxxxxxxx> wrote:
> > ok, I'm at the point where I'm close to having a version three of the
> > series to post that addresses all the feedback so far, plus some
> > additional improvements, with the following two items remaining to
> > discuss:
> >
> > 1) the domain_cookie, with Jan's question about a) its exclusion of
> > mismatches and b) its utility.
> >
> > Given the expressed concern that the timer-based cookie initialization
> > does not necessarily exclude mismatches, I've reimplemented it as a
> > simple 128-bit counter protected by the L1 lock: this does now exclude
> > mismatches.
>
> ... for all practical purposes, I assume you mean. In which case
> I'd then immediately ask whether a 64-bit counter wouldn't do
> as well.
>
> > The utility of the cookie follows from this:
> >
> > domid, despite its name, is not a unique domain identifier; it's a
> > temporally unique id: Xen will ensure that no two domains that execute
> > concurrently have the same domid. Domain authentication needs to take
> > this into account.
>
> Correct, at which point the question arises whether domain IDs
> aren't too narrow. After all this isn't the first time we run into such
> a restriction - see the opt_ibpb related code in context_switch().
>
> > With Argo, it affects these points:
> >
> > * ring registration: when the partner domain domid is specified, argo
> > finds the currently executing domain with that domid, and needs to
> > be able to confirm that it is the same domain later when a sendv is
> > issued.
> >
> > * sendv: needs to confirm that the domain sending a message is the same
> > as the single domain authorized to transmit when the ring was first
> > registered.
> >
> > * notify: the querying domain asks about free space, and if there's not
> > enough then a record is kept internal to the hypervisor, and a signal
> > will be sent to the caller later when sufficient space becomes
> > available.  Before sending the signal, Xen needs to confirm that the
> > current domain with the domid it remembered is the same as the one that
> > issued the query, otherwise Xen is sending spurious signals to domains
> > that are not expecting it (and unless it checks, may not even be
> > argo-enabled).
> >
> > * domain teardown: in the absence of the domain cookie, or an
> > alternative data structure that achieves the same ability to
> > distinguish a reincarnated domain, all the rings that are registered
> > that authorize the dying domid to send need to be torn down with
> > suitable notification to their owners, and all the pending signals for
> > that domain about available free space need to be nullified, to prevent
> > a later domain inheriting these credentials and signals.
> >
> > Doing so either entails a potentially-expensive walk of all rings of all
> > domains, plus all the pending notifications on all rings the domain can
> > access, or additional complexity with new data structures storing
> > further metadata on the authorized domain on ring registration, etc.
> > The domain cookie which enables identity confirmation on a domid is
> > a reasonable alternative solution.
>
> For all of these the question then is whether holding a reference
> to the other domain (which has been looked up during ring
> registration) wouldn't help. Furthermore this isn't a new problem,
> see e.g. how event channel code deals with the ECS_INTERDOMAIN
> case - without acquiring extra references, but instead with suitable
> (and mutual) cleanup during domain destruction.

Just to close on this thread: the v3 series posted last night has
added state teardown and mutual cleanup as requested, with the cookie
removed. Thanks for the pointers.

Christopher

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel