Re: [Xen-devel] Modifying domain creation interface

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Feb 21, 2018 at 03:08:23PM +0100, Juergen Gross wrote:
> Creating a new domain currently is a sequence of hypercalls with many of
> those being mandatory and needed in a specific sequence. Its has been
> discussed before to build a new interface for domain creation with _all_
> the mandatory information passed to the hypervisor in one hypercall.
> 
> I'd like to suggest to extend this idea even more: instead of passing
> the mandatory data only we could even add some optional data in a
> generic way. Instead of extending the binary interface each time a new
> configurable parameter is added for domains we could use a text based
> interface for that purpose, similar to the boot parameters of the
> hypervisor or the kernel. So instead adding e.g. a new flag for
> switching the Meltdown mitigation on or off for a specific domain (this
> example is the reason I thought of the new interface) to
> xen_domctl_createdomain.flags we could pass a string "xpti=off" to the
> hypervisor in the domain create hypercall parameters. Passing an array
> of strings plus the number of array elements would allow to extend the
> interface without having to change any header file.
> 
> It would even be possible to have something like:
> 
> domain_params=[ "xpti=off", "param_xy=foo" ]
> 
> in the xl config file of a domain allowing to specify new parameters
> without having to modify xl/libxl. This would allow backports of
> security patches which need some per-domain configuration aid (some
> SUSE customers already asked for a way to switch Meltdown mitigation
> on a per-domain basis in old versions).
> 

This is yet another way to configure a domain. What is your thought
going forward? I certainly don't want to have more than one way to
configure some aspects of a domain.

Say, we want to introduce parameter foo, do we support foo=bar in
domain_params only? Do we allow foo=bar as top-level option?

A problem I can see is that it would make it harder for toolstack to
reject incompatible options during migration -- it can't know until it
actually tries to (re)create the guest with the same parameters. But
what we have today isn't perfect either.

> Security is a point to be looked at, of course. OTOH it should be quite
> easy to use a fuzzer for proving the parser to be secure, as the parser
> can be constructed to be testable in user environment (like e.g. the
> x86 instruction emulator).
> 

One way to deal with that is to say we trust the configuration file
completely so bugs in parser won't be security issues.

Wei.

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