Re: [Xen-devel] [PATCH v2] libxl: Reset toolstack_save file position in libxl

[Jason Andryuk <andryuk@xxxxxxxx>]

On 5/21/2014 12:02 PM, Ian Jackson wrote:
> Jason Andryuk writes ("[PATCH v2] libxl: Reset toolstack_save file position 
> in libxl"):
>> toolstack_save data is written to a temporary file in libxl and read
>> back in libxl-save-helper.  The file position must be reset prior to
>> reading the file, which is done in libxl-save-helper with lseek.
>>
>> lseek is unsupported for pipes and sockets, so a wrapper passing such an
>> fd to libxl-save-helper fails the lseek.  Moving the lseek to libxl
>> avoids the error, allowing the save to continue.
> 
> I don't object to this in principle, and arguably it's wrong that this
> functionality should be in the save helper rather than libxl proper
> (since the save helper is supposed to be an as-thin-as-possible
> wrapper around the libxc functions).  So TBH I'm inclined to take
> this change on those grounds.
> 
> But I'm curious as to what kind of wrapper you have devised, and for
> what purpose.  Do you mean a wrapper program for libxl-save-helper ?
> Which presumably interposes a pipe for the toolstack data fd ?

Using XSM Flask and Domain Builder [1], the hypervisor can protect domU memory 
from control domains.  The wrapper spawns a migrator domain to run 
libxl-save-helper.  This migrator domain has the XSM permission to access the 
domU memory and encrypts the data stream to continue protecting the domU.

The wrapper in the control domain plumbs stdin, stdout, io_fd, and 
toolstack_save_fd through a vchan to the migrator domain.  Inside the migrator 
domain, the vchan data streams are passed through pipes to libxl-save-helper.  
(An earlier prototype used vifs and a socket).  The migrator domain's 
libxl-save-helper return value is passed to control domain, where the wrapper 
cleans up and then exits with the aforementioned return value.

Yes, it's an atypical setup.  The patch doesn't change co-located 
libxl/libxl-save-helper, but it does allow the possibility described above.

Regards,

Jason

[1] http://lists.xen.org/archives/html/xen-devel/2014-03/msg00320.html

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