On 5/29/18 5:28 AM, Ian Jackson wrote:
> Doug Goldstein writes ("Re: [Xen-devel] XSM in osstest, grub config,
> outstanding patch"):
>> So I believe the path forward here was that we'd bake the "default" XSM
>> policy into Xen and the user could then override it by supplying one
>> with the current name.
>
> Can you explain why this is better than shipping the default policy
> file separately (via xen's dist/install/boot/) ?
>
> This is a genuine question - I'm not arguing for the current approach,
> but we should consider the merits. Normally, as a rule of thumb,
> baking configuration into things makes people's lives harder. In this
> case, for example, maybe it makes it hard to find the default policy
> to examine it, or harder to know what to call the replacement.
>
> Ian.
>
To me it seemed sane. It solves the question of where do user supplied
policies go (they go into the current name). It solves the issue with
users having to currently overwrite a distro package provided file (the
policy isn't marked as a config file in any distro currently). It would
solve the question you asked since the defaults would be baked in. In
effect we could have a build of Xen that supports XSM with a default
policy that mirrors the current DAC setup and it could functionally
behave the same.
The policy file isn't something that users can examine since its a
compiled thing. That way the default policy ships with the Xen tree and
we could have a separate repo with some other policies. That would make
it easier for users to understand how to create their own policies.
I'm more just throwing ideas out there so I'd be happy to hear better
suggestions.
--
Doug Goldstein
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
