Re: Xen XSM/FLASK policy, grub defaults, etc.

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On May 29, 2020, at 6:24 PM, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Jan,
> 
> On 29/05/2020 16:11, Jan Beulich wrote:
>> On 29.05.2020 17:05, Julien Grall wrote:
>>> On 29/05/2020 15:47, Ian Jackson wrote:
>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have 
>>>>> an intermediate solution that works right now, even if it’s not optimal.
>>>> 
>>>> I propose the following behaviour by updste-grub:
>>>> 
>>>>   1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>>>>      (For now, skip this step, since the ELF note is not defined.)
>>> 
>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such
>>> thing for the kernel/xen (actually the final binary is not even an ELF).
>> Ouch - of course. Is there anything similar one could employ there?
> 
> In the past, we discussed about adding support for note in the zImage (arm32 
> kernel format) but I never got the chance to pursue the discussion.
> 
> With Juergen's hypfs series, the hypervisor now embbed the .config. Is it 
> possible to extract it?

The problem is that update-grub doesn’t want the config of the *currently 
running* hypervisor, but of whatever specific hypervisor there is in /boot.

So for instance, when someone first does “apt-get install xen”, after xen 
binaries are put in /boot, update-grub is called to make new entries for it.  
Ideally, we want it to create FLASK grub entries, and boot them by default, if 
and only if *that Xen binary* has FLASK enabled and there is a policy for it.  
At the time update-grub runs, Xen will not be running.

And if a user installs several Xen binaries, some of which have FLASK enabled 
and some of which don’t, we want update-grub to generate FLASK entries for the 
binaries that have FLASK enabled, and not for the ones which don’t.  So hypfs 
isn’t really a suitable solution.

The options proposed have included:

1. Making the tools not generate a FLASK policy unless FLASK is enabled in the 
hypervisor being built.  This is flaky because there’s no necessary connection 
between the two builds.

2. Using the xen config file normally copied into /boot.  This should work now, 
but it’s been suggested that packagers may not want to continue putting the xen 
config in /boot along with xen.gz, just as they’ve stopped putting the Linux 
config in /boot along with vmlinuz.

3. Mark the xen.gz binary itself somehow as having FLASK.  This could work for 
x86 in the future, but won’t work for current binaries; and it sounds like it 
won’t work for ARM either.

Ultimately, I have the feeling that #1, although somewhat awkward, is going to 
be the best solution: packagers can arrange that FLASK policies only be 
installed when FLASK policies are created.  People doing self-builds based on 
distro packages will be covered; people doing home-grown self-builds with 
non-default FLASK settings will need to take extra care to make sure the tools 
do the right thing.

 -George