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

[Jason Andryuk <andryuk@aero.org>]

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