[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xSplice prototype
(Replacing dslutz@xxxxxxxxxxx with rboos@xxxxxxxxxxx since dslutz is no longer at Verizon.) ________________________________________ From: Ross Lagerwall [ross.lagerwall@xxxxxxxxxx] Sent: Monday, October 26, 2015 1:03 PM To: Konrad Rzeszutek Wilk Cc: elena.ufimtseva@xxxxxxxxxx; hanweidong@xxxxxxxxxx; jbeulich@xxxxxxxx; john.liuqiming@xxxxxxxxxx; paul.voccio@xxxxxxxxxxxxx; kurt.hackel@xxxxxxxxxx; daniel.kiper@xxxxxxxxxx; major.hayden@xxxxxxxxxxxxx; liuyingdong@xxxxxxxxxx; aliguori@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx; lars.kurth@xxxxxxxxxx; steven.wilson@xxxxxxxxxxxxx; ian.campbell@xxxxxxxxxx; peter.huangpeng@xxxxxxxxxx; msw@xxxxxxxxxx; xiantao.zxt@xxxxxxxxxxxxxxx; rick.harris@xxxxxxxxxxxxx; boris.ostrovsky@xxxxxxxxxx; jinsong.liu@xxxxxxxxxxxxxxx; amesserl@xxxxxxxxxxxxx; mpohlack@xxxxxxxxxx; dslutz@xxxxxxxxxxx; fanhenglong@xxxxxxxxxx; andrew.cooper3@xxxxxxxxxx Subject: Re: [Xen-devel] xSplice prototype 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |