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
