Re: [Xen-devel] xSplice prototype

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 10/26/2015 03:03 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 26, 2015 at 08:35:30AM +0000, Ross Lagerwall wrote:
> > > It was added as a way to do signature checking and any other type
> > > of checking that needed to be done. And which may take quite a while
> > > to get done - hence doing it asynchronously.
> > OK. There are many things that need to be done to load an xSplice module,
> > almost all of which are dependent on the size of the module and may also
> > fail (e.g. resolving symbols, performing relocations, copying allocated
> > sections, etc). I think signature checking should be as part of the load
> > procedure, and if that needs to be done asynchronously, then so be it. The
> > nice thing about doing signature checking at load time is that (if it's
> > implemented as per Linux's signature checking) once the load phase is
> > complete, the original uploaded payload can be freed from memory. It might
> > be handy to think of the load procedure as equivalent to a basic version of
> > the Linux kernel module loader (which is pretty much what I did when
> > implementing it).
> >
> > And while I remember, I think the REVERTED state is unnecessary. It seems
> > exactly equivalent to the LOADED state, which is just confusing.
> Perhaps it should just move automatically from REVERT to LOADED? You have
> to do some action to trigger it to unload.
>
> And perhaps 'UNLOAD' is better than 'REVERT' ?
I think separating the actions from the state makes it clearer. So for 
example (ignoring CHECK for now), there are 2 states:
    LOADED, APPLIED
and 4 actions:
    LOAD paired with UNLOAD
    APPLY paired with REVERT

LOAD loads the payload
APPLY moves the payload from LOADED to APPLIED
REVERT moves the payload from APPLIED to LOADED
UNLOAD removes the payload from the hypervisor completely

Does this make sense?

--
Ross Lagerwall

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