Re: [Xen-devel] Modifying domain creation interface

[Juergen Gross <jgross@xxxxxxxx>]

On 13/03/18 17:08, Wei Liu wrote:
> 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.

The hypervisor should accept only one way of configuration for each
parameter: either the traditional one (e.g. max. numbers of vcpus) or
the new textual interface (e.g. "xpti=...").

Same for the tools: in case xl knows about a textual parameter it
shouldn't accept it in the "domain_params=[..." form.

> 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?

This would depend on each parameter I guess.

> 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.

Right.

>> 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.

I was thinking of the parser in the hypervisor. It shouldn't crash the
system.


Juergen

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