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

[Julien Grall <julien@xxxxxxx>]

Hi George,

On 01/06/2020 13:57, George Dunlap wrote:
> > 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.
I am fully aware we want to get information of the binaries residing in 
/boot (I wouldn't have suggested zImage note otherwise). So I think you 
misundertood my question.
> 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.
I have never suggested to use hypfs. Instead, I have pointed out that 
.config is embedded in the binary thanks to hypfs. So I was asking 
whether we can extract it.
On Linux, they have a script to extract the .config from the Kernel 
Image (see scripts/extract-ikconfig). Now that the .config is part of 
the Xen binarry, I was wondering whether we could have extract it.
> 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.
4. Extract the .config from the binary using a similar script to 
script/extract-ikconfig.
Cheers,

--
Julien Grall