Modifying domain creation interface

Modifying domain creation interface

[Juergen Gross]

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

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

Right now I will add a new binary flag (again for making backports
easier), but I think if we want to modify the domain creation
interface anyway, we should consider doing it in an easy extendable
way. I am targeting Xen 4.12 for that idea in case it is accepted, so
I wanted to start discussion early.

What do you think?


Juergen

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

Re: Modifying domain creation interface

[Wei Liu]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Modifying domain creation interface

[Juergen Gross]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel