Hi,
During work on multiboot2 protocol support for Xen it was discovered
that memory map passed via relevant tag could not represent wide range
of memory types available on EFI platforms. Additionally, GRUB2
implementation calls ExitBootServices() on them just before jumping
into loaded image. In this situation loaded system could not clearly
identify reserved memory regions, EFI runtime services regions and others.
Normally, on EFI platform, system requires access to at least EFI runtime
services. However, it is not possible to identify them in GRUB2
implementation of multiboot2 protocol because they are marked as reserved,
like memory mapped IO regions, really reserved memory regions and others.
Additionally, it is not possible to get memory map directly from EFI (similar
solution is used on legacy BIOS platforms in Xen case) because ExitBootServices()
was earlier called by GRUB2. So there is only one chance to do that today.
Loaded image could map all reserved regions. However, this is not final
solution because it could be dangerous. So this is rather workaround which
should be used on currently existing multiboot2 protocol implementation only.
At this stage extra tag could be added to multiboot2 protocol to pass plain
EFI memory map to loaded image too. However, this solution requires some
coordination with GRUB2 upstream and could take some time.
Additionally, it should be mentioned that there is no possibility or it could
be very difficult to implement secure boot on EFI platforms using GRUB2 as boot
loader because, as it was mentioned earlier, it calls ExitBootServices().
At first there was a plan to use upstream GRUB2 as a reference multiboot2 protocol
implementation. However, during discussion on LPC 2013 it was stated that every
distribution uses tons of patches for GRUB2. So distros GRUB2 implementation
substantially deviates form upstream. One of this deviation is linuxefi module
which enables usage of secure boot protocol on EFI platforms with shim. However,
it should be mentioned that this module still uses Linux x86 boot protocol.
So I think that similar solution could be used in multiboot2 protocol case.
Separate multiboot2efi module should be established. It should verify system
kernel and all loaded modules using shim on EFI platforms with enabled secure boot
(this step should be omitted on platforms without secure boot). If verification
is successfully completed GRUB2 should transfer control to loaded image. Later
it should get system memory map directly from EFI, do other needed things, call
ExitBootServices() and finally start loaded system. I think that this proposal
could solve above mentioned problems. Additionally, I think that multiboot2 protocol
should be extended by adding extra tag which will be used to pass plain EFI memory
map to loaded image. Just in case (we could also use this as transitional thing
as I mentioned above). Work on this solution should be coordinated with upstream
GRUB2 guys to ease its later introduction in distros and to avoid another deviation.
At first I am going to prepare multiboot2 protocol implementation for Xen (there
is about 80% of code ready) with above mentioned workaround. Later I am going
to work on multiboot2efi module.
What do you think about that?
Any comments, suggestions, objections?
Daniel
>>> On 21.10.13 at 14:57, Daniel Kiper <[email protected]> wrote:
(Looking at the Cc list it's quite interesting that you copied a
whole lot of people, but not me as the maintainer of the EFI
bits in Xen.)
> Separate multiboot2efi module should be established. It should verify system
> kernel and all loaded modules using shim on EFI platforms with enabled
> secure boot
Each involved component verifies only the next image. I.e. the
shim verifies the Xen image, and Xen verifies the Dom0 kernel
binary. The Dom0 kernel (assuming it to be Linux) will then be
responsible for dealing with its initrd. (One open question is how
Xen ought to deal with an eventual XSM module; I take it that
the CPUs themselves take care of the microcode blob.) This can't
be different because the shim provided verification protocol
assumes that it's being handed a PE image (hence the need for
Linux to package itself as a fake PE image), and hence can't be
used for verifying other than the Xen and Dom0 kernel binaries.
> At first I am going to prepare multiboot2 protocol implementation for Xen
> (there
> is about 80% of code ready) with above mentioned workaround.
Is that really worthwhile as long as it's not clear whether ...
> Later I am going to work on multiboot2efi module.
... is going to be accepted?
> What do you think about that?
> Any comments, suggestions, objections?
The complications here make it pretty clear to me that the
GrUB2-less solution (or, if GruB2 absolutely has to be involved,
its chain loading capability) I have been advocating continues
to be the better (and, as said before, conceptually correct)
model.
Jan
On Mon, Oct 21, 2013 at 02:57:56PM +0200, Daniel Kiper wrote:
> Hi,
>
> During work on multiboot2 protocol support for Xen it was discovered
> that memory map passed via relevant tag could not represent wide range
> of memory types available on EFI platforms. Additionally, GRUB2
> implementation calls ExitBootServices() on them just before jumping
> into loaded image. In this situation loaded system could not clearly
> identify reserved memory regions, EFI runtime services regions and others.
I think you'll find that many distros are shipping patches to grub2 to
add a "linuxefi" command that starts the kernel through its EFISTUB
code. You may want to look in to that.
--
Peter
On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
> >>> On 21.10.13 at 14:57, Daniel Kiper <[email protected]> wrote:
>
> (Looking at the Cc list it's quite interesting that you copied a
> whole lot of people, but not me as the maintainer of the EFI
> bits in Xen.)
I see this:
From: Daniel Kiper <[email protected]>
To: [email protected], [email protected],
[email protected], [email protected], [email protected],
You are on the 'To' instead of the 'CC'. That should make the email
arrive at your mailbox much quicker than through the mailing list?
>
> > Separate multiboot2efi module should be established. It should verify system
> > kernel and all loaded modules using shim on EFI platforms with enabled
> > secure boot
>
> Each involved component verifies only the next image. I.e. the
> shim verifies the Xen image, and Xen verifies the Dom0 kernel
> binary. The Dom0 kernel (assuming it to be Linux) will then be
> responsible for dealing with its initrd. (One open question is how
> Xen ought to deal with an eventual XSM module; I take it that
> the CPUs themselves take care of the microcode blob.) This can't
> be different because the shim provided verification protocol
> assumes that it's being handed a PE image (hence the need for
> Linux to package itself as a fake PE image), and hence can't be
> used for verifying other than the Xen and Dom0 kernel binaries.
>
> > At first I am going to prepare multiboot2 protocol implementation for Xen
> > (there
> > is about 80% of code ready) with above mentioned workaround.
>
> Is that really worthwhile as long as it's not clear whether ...
>
> > Later I am going to work on multiboot2efi module.
>
> ... is going to be accepted?
>
> > What do you think about that?
> > Any comments, suggestions, objections?
>
> The complications here make it pretty clear to me that the
> GrUB2-less solution (or, if GruB2 absolutely has to be involved,
> its chain loading capability) I have been advocating continues
> to be the better (and, as said before, conceptually correct)
> model.
However my understanding is that the general distro approach is
to use GRUB2 and I think we want to follow the mainstream on this.
Which means using GRUB2 and making sense of the myrid of patches
that each distro has.
>>> On 21.10.13 at 16:23, Konrad Rzeszutek Wilk <[email protected]> wrote:
> On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 14:57, Daniel Kiper <[email protected]> wrote:
>>
>> (Looking at the Cc list it's quite interesting that you copied a
>> whole lot of people, but not me as the maintainer of the EFI
>> bits in Xen.)
>
> I see this:
>
> From: Daniel Kiper <[email protected]>
> To: [email protected], [email protected],
> [email protected], [email protected], [email protected],
>
>
> You are on the 'To' instead of the 'CC'. That should make the email
> arrive at your mailbox much quicker than through the mailing list?
Indeed - I was clearly looking at the wrong place. I'm very sorry.
>> > What do you think about that?
>> > Any comments, suggestions, objections?
>>
>> The complications here make it pretty clear to me that the
>> GrUB2-less solution (or, if GruB2 absolutely has to be involved,
>> its chain loading capability) I have been advocating continues
>> to be the better (and, as said before, conceptually correct)
>> model.
>
> However my understanding is that the general distro approach is
> to use GRUB2 and I think we want to follow the mainstream on this.
> Which means using GRUB2 and making sense of the myrid of patches
> that each distro has.
As does ours - and we simply use the chain loading mechanism as
I'm told (and as I suggested - I'm only occasionally involved in the
secure boot stuff).
Jan
On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
> >>> On 21.10.13 at 14:57, Daniel Kiper <[email protected]> wrote:
[...]
> > Separate multiboot2efi module should be established. It should verify system
> > kernel and all loaded modules using shim on EFI platforms with enabled
> > secure boot
>
> Each involved component verifies only the next image. I.e. the
> shim verifies the Xen image, and Xen verifies the Dom0 kernel
> binary. The Dom0 kernel (assuming it to be Linux) will then be
> responsible for dealing with its initrd. (One open question is how
Currently Linux Kernel is only verified. Sorry, my fault.
As I know Matthew Garrett would like to verify Linux Kernel
modules too. However, I do not know details now. I think that
we should take into account his work.
> Xen ought to deal with an eventual XSM module; I take it that
Could you tell me more about that? What issues do you expect here?
> the CPUs themselves take care of the microcode blob.) This can't
> be different because the shim provided verification protocol
> assumes that it's being handed a PE image (hence the need for
> Linux to package itself as a fake PE image), and hence can't be
> used for verifying other than the Xen and Dom0 kernel binaries.
>
> > At first I am going to prepare multiboot2 protocol implementation for Xen
> > (there
> > is about 80% of code ready) with above mentioned workaround.
>
> Is that really worthwhile as long as it's not clear whether ...
>
> > Later I am going to work on multiboot2efi module.
>
> ... is going to be accepted?
It is only proposal. I am not going to continue work until we agree all details.
> > What do you think about that?
> > Any comments, suggestions, objections?
>
> The complications here make it pretty clear to me that the
> GrUB2-less solution (or, if GruB2 absolutely has to be involved,
> its chain loading capability) I have been advocating continues
> to be the better (and, as said before, conceptually correct)
> model.
In general I agree but real life is more complicated (sadly). EFI boot loader
is not so flexible as GRUB2. Additionally, its configuration differs from
platform to platform. I do not mention that if you would like to change EFI
boot loader configuration from EFI platform configuration menu it is at least
onerous. Until all above mentioned issues (and others) will be fixed I do not
expect that everybody will use EFI boot loader as a standard way for system
loading. Probably it will happen later than sooner (if at all). So I think we
should find right solution for that problem instead of ignoring it.
Daniel
On Mon, Oct 21, 2013 at 03:37:21PM +0100, Jan Beulich wrote:
> >>> On 21.10.13 at 16:23, Konrad Rzeszutek Wilk <[email protected]> wrote:
> > On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
> >> >>> On 21.10.13 at 14:57, Daniel Kiper <[email protected]> wrote:
[...]
> >> > What do you think about that?
> >> > Any comments, suggestions, objections?
> >>
> >> The complications here make it pretty clear to me that the
> >> GrUB2-less solution (or, if GruB2 absolutely has to be involved,
> >> its chain loading capability) I have been advocating continues
> >> to be the better (and, as said before, conceptually correct)
> >> model.
> >
> > However my understanding is that the general distro approach is
> > to use GRUB2 and I think we want to follow the mainstream on this.
> > Which means using GRUB2 and making sense of the myrid of patches
> > that each distro has.
>
> As does ours - and we simply use the chain loading mechanism as
> I'm told (and as I suggested - I'm only occasionally involved in the
> secure boot stuff).
Do you think about GRUB2 chainloader command?
Daniel
On Mon, Oct 21, 2013 at 09:54:38AM -0400, Peter Jones wrote:
> On Mon, Oct 21, 2013 at 02:57:56PM +0200, Daniel Kiper wrote:
> > Hi,
> >
> > During work on multiboot2 protocol support for Xen it was discovered
> > that memory map passed via relevant tag could not represent wide range
> > of memory types available on EFI platforms. Additionally, GRUB2
> > implementation calls ExitBootServices() on them just before jumping
> > into loaded image. In this situation loaded system could not clearly
> > identify reserved memory regions, EFI runtime services regions and others.
>
> I think you'll find that many distros are shipping patches to grub2 to
> add a "linuxefi" command that starts the kernel through its EFISTUB
> code. You may want to look in to that.
I am referring to that patches in my initial email. However, I think that
we are not able to use them directly (correct me if I am wrong) because
Xen does not use Linux Boot protocol. I thought that it is worth to
migrate to multiboot2 protocol if Xen supports earlier multiboot protocol
version. As I understood you are suggesting to drop multiboot2 idea and
prepare something similar to linuxefi. It should pass only needed things
to Xen and later Xen itself should get required stuff from EFI directly.
Finally it should call ExitBootSerices(). Is it correct?
Daniel
Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
> Hi,
>
> During work on multiboot2 protocol support for Xen it was discovered
> that memory map passed via relevant tag could not represent wide range
> of memory types available on EFI platforms. Additionally, GRUB2
> implementation calls ExitBootServices() on them just before jumping
> into loaded image. In this situation loaded system could not clearly
> identify reserved memory regions, EFI runtime services regions and others.
Yes, that is exactly why we added full support to pass the entire UEFI
memory map via a new tag.
>
> Normally, on EFI platform, system requires access to at least EFI runtime
> services. However, it is not possible to identify them in GRUB2
> implementation of multiboot2 protocol because they are marked as reserved,
> like memory mapped IO regions, really reserved memory regions and others.
> Additionally, it is not possible to get memory map directly from EFI (similar
> solution is used on legacy BIOS platforms in Xen case) because ExitBootServices()
> was earlier called by GRUB2. So there is only one chance to do that today.
> Loaded image could map all reserved regions. However, this is not final
> solution because it could be dangerous. So this is rather workaround which
> should be used on currently existing multiboot2 protocol implementation only.
> At this stage extra tag could be added to multiboot2 protocol to pass plain
> EFI memory map to loaded image too. However, this solution requires some
> coordination with GRUB2 upstream and could take some time.
This is precisely what we did, and though there is a risk of using a tag
that is not accepted upstream, we did what we needed to do, since we ship the
boot loader with the OS and don't have to be concerned with making it work
with some arbitrary already-installed loader.
>
> Additionally, it should be mentioned that there is no possibility or it could
> be very difficult to implement secure boot on EFI platforms using GRUB2 as boot
> loader because, as it was mentioned earlier, it calls ExitBootServices().
>
> At first there was a plan to use upstream GRUB2 as a reference multiboot2 protocol
> implementation. However, during discussion on LPC 2013 it was stated that every
> distribution uses tons of patches for GRUB2. So distros GRUB2 implementation
> substantially deviates form upstream. One of this deviation is linuxefi module
> which enables usage of secure boot protocol on EFI platforms with shim. However,
> it should be mentioned that this module still uses Linux x86 boot protocol.
> So I think that similar solution could be used in multiboot2 protocol case.
>
> Separate multiboot2efi module should be established. It should verify system
> kernel and all loaded modules using shim on EFI platforms with enabled secure boot
> (this step should be omitted on platforms without secure boot). If verification
> is successfully completed GRUB2 should transfer control to loaded image. Later
> it should get system memory map directly from EFI, do other needed things, call
> ExitBootServices() and finally start loaded system. I think that this proposal
> could solve above mentioned problems. Additionally, I think that multiboot2 protocol
> should be extended by adding extra tag which will be used to pass plain EFI memory
> map to loaded image. Just in case (we could also use this as transitional thing
> as I mentioned above). Work on this solution should be coordinated with upstream
> GRUB2 guys to ease its later introduction in distros and to avoid another deviation.
>
I'm not sure we even need a separate command -- it adds complexity for no
reason. It's reasonable to just perform the validation if we're on a UEFI
platform and secure boot is enabled. MAYBE an arg to the multiboot2 command
would be useful for testing, but I'd rather not have any way for secure boot
to be circumvented, lest a piece of malware only needs to write a new
menuentry with the non-secure-boot multiboot2 command and make it the default.
Thanks,
--S
> At first I am going to prepare multiboot2 protocol implementation for Xen (there
> is about 80% of code ready) with above mentioned workaround. Later I am going
> to work on multiboot2efi module.
>
> What do you think about that?
> Any comments, suggestions, objections?
>
> Daniel
>
> _______________________________________________
> Grub-devel mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
Mail is big, I think I got your essential points but I didn't read it whole.
On 21.10.2013 14:57, Daniel Kiper wrote:
> Hi,
>
> During work on multiboot2 protocol support for Xen it was discovered
> that memory map passed via relevant tag could not represent wide range
> of memory types available on EFI platforms. Additionally, GRUB2
> implementation calls ExitBootServices() on them just before jumping
> into loaded image. In this situation loaded system could not clearly
> identify reserved memory regions, EFI runtime services regions and others.
>
Will a multiboot2 tag with whole EFI memory map solve your problem?
> Additionally, it should be mentioned that there is no possibility or it could
> be very difficult to implement secure boot on EFI platforms using GRUB2 as boot
> loader because, as it was mentioned earlier, it calls ExitBootServices().
>
GRUB has generic support for signing kernels/modules/whatsoever using
GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
method doesn't have any controversy associated with EFI stuff but at
this particular case does exactly the same thing: verify signature.
multiboot2 is mainly memory structure specification so probably how the
files are checked is outside of its scope. But it's possible to add
specification on how to embed signatures in kernel.
On 21.10.2013 22:53, Seth Goldberg wrote:
>
>
> Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
>
>> Hi,
>>
>> During work on multiboot2 protocol support for Xen it was discovered
>> that memory map passed via relevant tag could not represent wide range
>> of memory types available on EFI platforms. Additionally, GRUB2
>> implementation calls ExitBootServices() on them just before jumping
>> into loaded image. In this situation loaded system could not clearly
>> identify reserved memory regions, EFI runtime services regions and
>> others.
>
> Yes, that is exactly why we added full support to pass the entire UEFI
> memory map via a new tag.
>
Can you send this patch? Or provide a link to publically available
source? I think we can accept it with probably just minor changes.
Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following on...:
> On 21.10.2013 22:53, Seth Goldberg wrote:
>>
>>
>> Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
>>
>>> Hi,
>>>
>>> During work on multiboot2 protocol support for Xen it was discovered
>>> that memory map passed via relevant tag could not represent wide range
>>> of memory types available on EFI platforms. Additionally, GRUB2
>>> implementation calls ExitBootServices() on them just before jumping
>>> into loaded image. In this situation loaded system could not clearly
>>> identify reserved memory regions, EFI runtime services regions and
>>> others.
>>
>> Yes, that is exactly why we added full support to pass the entire UEFI
>> memory map via a new tag.
>>
> Can you send this patch? Or provide a link to publically available
> source? I think we can accept it with probably just minor changes.
>
Sure :). Just as an FYI, the changes are available in one of the zips from:
http://www.oracle.com/technetwork/opensource/systems-solaris-1562786.html
(their size is rather comical of course, but only because they include ALL
FOSS source shipped with Solaris 11.1).
I'll try to isolate that change and base it against the current trunk.
We may need to change the tag id, as I ended up using an OEM-specific number
for it; I didn't want to conflict with new tags.
Thanks,
--S
>>> On 21.10.13 at 20:39, Daniel Kiper <[email protected]> wrote:
> On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 14:57, Daniel Kiper <[email protected]> wrote:
>> > Separate multiboot2efi module should be established. It should verify system
>> > kernel and all loaded modules using shim on EFI platforms with enabled
>> > secure boot
>>
>> Each involved component verifies only the next image. I.e. the
>> shim verifies the Xen image, and Xen verifies the Dom0 kernel
>> binary. The Dom0 kernel (assuming it to be Linux) will then be
>> responsible for dealing with its initrd. (One open question is how
>
> Currently Linux Kernel is only verified. Sorry, my fault.
> As I know Matthew Garrett would like to verify Linux Kernel
> modules too. However, I do not know details now. I think that
> we should take into account his work.
Sure, Linux modules are to be verified. But that's a Linux thing
we can be entirely unconcerned about. In the context of GrUB,
"module" can only have the meaning of GrUB modules.
>> Xen ought to deal with an eventual XSM module; I take it that
>
> Could you tell me more about that? What issues do you expect here?
We obviously need to have a way to verify the integrity of an
XSM module. Otherwise - as with any unverified component -
its presence would break the integrity of the supposedly secure
system.
Jan
>>> On 21.10.13 at 20:46, Daniel Kiper <[email protected]> wrote:
> On Mon, Oct 21, 2013 at 03:37:21PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 16:23, Konrad Rzeszutek Wilk <[email protected]> wrote:
>> > However my understanding is that the general distro approach is
>> > to use GRUB2 and I think we want to follow the mainstream on this.
>> > Which means using GRUB2 and making sense of the myrid of patches
>> > that each distro has.
>>
>> As does ours - and we simply use the chain loading mechanism as
>> I'm told (and as I suggested - I'm only occasionally involved in the
>> secure boot stuff).
>
> Do you think about GRUB2 chainloader command?
Sure.
Jan
On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Mail is big, I think I got your essential points but I didn't read it whole.
> On 21.10.2013 14:57, Daniel Kiper wrote:
>> Hi,
>>
>> During work on multiboot2 protocol support for Xen it was discovered
>> that memory map passed via relevant tag could not represent wide range
>> of memory types available on EFI platforms. Additionally, GRUB2
>> implementation calls ExitBootServices() on them just before jumping
>> into loaded image. In this situation loaded system could not clearly
>> identify reserved memory regions, EFI runtime services regions and others.
>>
> Will a multiboot2 tag with whole EFI memory map solve your problem?
I added such a tag in documentation and wrote a patch for it (attached).
Awaiting for someone to test it to commit
On Mon, 2013-10-21 at 20:57 +0200, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 09:54:38AM -0400, Peter Jones wrote:
> > On Mon, Oct 21, 2013 at 02:57:56PM +0200, Daniel Kiper wrote:
> > > Hi,
> > >
> > > During work on multiboot2 protocol support for Xen it was discovered
> > > that memory map passed via relevant tag could not represent wide range
> > > of memory types available on EFI platforms. Additionally, GRUB2
> > > implementation calls ExitBootServices() on them just before jumping
> > > into loaded image. In this situation loaded system could not clearly
> > > identify reserved memory regions, EFI runtime services regions and others.
> >
> > I think you'll find that many distros are shipping patches to grub2 to
> > add a "linuxefi" command that starts the kernel through its EFISTUB
> > code. You may want to look in to that.
>
> I am referring to that patches in my initial email. However, I think that
> we are not able to use them directly (correct me if I am wrong) because
> Xen does not use Linux Boot protocol.
AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
It actually loads and executes the kernel binary as a PE/COFF executable
(the native UEFI binary executable format). xen.efi is a PE/COFF binary
too and could equally well be launched by linuxefi in this way.
Ian.
>>> On 22.10.13 at 11:26, Ian Campbell <[email protected]> wrote:
> AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
> Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
> It actually loads and executes the kernel binary as a PE/COFF executable
> (the native UEFI binary executable format). xen.efi is a PE/COFF binary
> too and could equally well be launched by linuxefi in this way.
Except that unless I'm mistaken "linuxefi" still expects to find certain
Linux-specific internal data structures inside the PE image, which I
don't see us wanting to be emulating. That's the main difference to
"chainloader" afaict.
Jan
On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> >>> On 22.10.13 at 11:26, Ian Campbell <[email protected]> wrote:
> > AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
> > Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
> > It actually loads and executes the kernel binary as a PE/COFF executable
> > (the native UEFI binary executable format). xen.efi is a PE/COFF binary
> > too and could equally well be launched by linuxefi in this way.
>
> Except that unless I'm mistaken "linuxefi" still expects to find certain
> Linux-specific internal data structures inside the PE image, which I
> don't see us wanting to be emulating. That's the main difference to
> "chainloader" afaict.
Ah, I'd been led to believe it was just the lack of a call to
ExitBootServices, but I didn't check. What you say sounds completely
plausible.
Do you know what sort of Linux specific data structures are we talking
about?
Ian.
>>> On 22.10.13 at 11:45, Ian Campbell <[email protected]> wrote:
> On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
>> >>> On 22.10.13 at 11:26, Ian Campbell <[email protected]> wrote:
>> > AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
>> > Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
>> > It actually loads and executes the kernel binary as a PE/COFF executable
>> > (the native UEFI binary executable format). xen.efi is a PE/COFF binary
>> > too and could equally well be launched by linuxefi in this way.
>>
>> Except that unless I'm mistaken "linuxefi" still expects to find certain
>> Linux-specific internal data structures inside the PE image, which I
>> don't see us wanting to be emulating. That's the main difference to
>> "chainloader" afaict.
>
> Ah, I'd been led to believe it was just the lack of a call to
> ExitBootServices, but I didn't check. What you say sounds completely
> plausible.
>
> Do you know what sort of Linux specific data structures are we talking
> about?
The setup header I would assume (i.e. the bits surrounding the
"HdrS" signature). But I'm only guessing anyway.
Jan
On Tue, Oct 22, 2013 at 10:59:33AM +0100, Jan Beulich wrote:
> >>> On 22.10.13 at 11:45, Ian Campbell <[email protected]> wrote:
> > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> >> >>> On 22.10.13 at 11:26, Ian Campbell <[email protected]> wrote:
> >> > AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
> >> > Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
> >> > It actually loads and executes the kernel binary as a PE/COFF executable
> >> > (the native UEFI binary executable format). xen.efi is a PE/COFF binary
> >> > too and could equally well be launched by linuxefi in this way.
> >>
> >> Except that unless I'm mistaken "linuxefi" still expects to find certain
> >> Linux-specific internal data structures inside the PE image, which I
> >> don't see us wanting to be emulating. That's the main difference to
> >> "chainloader" afaict.
> >
> > Ah, I'd been led to believe it was just the lack of a call to
> > ExitBootServices, but I didn't check. What you say sounds completely
> > plausible.
> >
> > Do you know what sort of Linux specific data structures are we talking
> > about?
>
> The setup header I would assume (i.e. the bits surrounding the
> "HdrS" signature). But I'm only guessing anyway.
This is a bit lengthy email, so please get your coffee/tea ready.
Peter Jones was kind enough to educate me on IRC what it does. The
GRUB2 module calls the PE/COFF executable (so using the Microsoft ABI
for passing parameters) using this typedef:
typedef void(*handover_func)(void *, grub_efi_system_table_t *, struct linux_kernel_params *);
" and grub_cmd_linux (i.e. "linuxefi") does:
if (!lh.handover_offset) { blah } ... handover_offset = lh.handover_offset
and then allocates the linux_kernel_params using EFI's AllocatePool() as EFI_LOADER_DATA, and then just:
hf = (handover_func)((char *)kernel_mem + handover_offset + offset);
asm volatile ("cli");
hf (grub_efi_image_handle, grub_efi_system_table, params);
" (from conversation with Peter Jones).
Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is defined
in the linux/Documentation/x86/boot.txt and hpa is pretty strict
about making it backwards compatible. It also seems to support Xen!
(Interestingly enough we do have this structure in the code: see
setup_header in arch/x86/bzimage.c)
GRUB expects the image to have the 0xAA55 at a specific offset (0x01FE)
otherwise it will stop the load.
Then there is also the need to have at 0x202 the 'HdrS' string and
and version id at (0x206). There is also at offset 0x264 the handover_offset
which is what gets called (this I presume is the same as with PE/COFF
images and it is expected that a native PE/COFF image would have the
same location). Interestingly enough the Linux payload has both headers
built-in - this boot one and also the Microsoft PE/COFF header. Meaning
it can be launched as a normal PE/COFF binary or a boot loader can
parse it and find the Linux x86 boot protocol. Pretty nifty.
Anyhow, the handover function is called with three parameters. The
third one is the extra 'struct linux_kernel_params' :
/* Boot parameters for Linux based on 2.6.12. This is used by the setup
sectors of Linux, and must be simulated by GRUB on EFI, because
the setup sectors depend on BIOS. */
struct linux_kernel_params
{
grub_uint8_t video_cursor_x; /* 0 */
grub_uint8_t video_cursor_y;
grub_uint16_t ext_mem; /* 2 */
grub_uint16_t video_page; /* 4 */
grub_uint8_t video_mode; /* 6 */
grub_uint8_t video_width; /* 7 */
grub_uint8_t padding1[0xa - 0x8];
grub_uint16_t video_ega_bx; /* a */
grub_uint8_t padding2[0xe - 0xc];
grub_uint8_t video_height; /* e */
grub_uint8_t have_vga; /* f */
grub_uint16_t font_size; /* 10 */
grub_uint16_t lfb_width; /* 12 */
grub_uint16_t lfb_height; /* 14 */
grub_uint16_t lfb_depth; /* 16 */
grub_uint32_t lfb_base; /* 18 */
grub_uint32_t lfb_size; /* 1c */
grub_uint16_t cl_magic; /* 20 */
grub_uint16_t cl_offset;
grub_uint16_t lfb_line_len; /* 24 */
grub_uint8_t red_mask_size; /* 26 */
grub_uint8_t red_field_pos;
grub_uint8_t green_mask_size;
grub_uint8_t green_field_pos;
grub_uint8_t blue_mask_size;
grub_uint8_t blue_field_pos;
grub_uint8_t reserved_mask_size;
grub_uint8_t reserved_field_pos;
grub_uint16_t vesapm_segment; /* 2e */
grub_uint16_t vesapm_offset; /* 30 */
grub_uint16_t lfb_pages; /* 32 */
grub_uint16_t vesa_attrib; /* 34 */
grub_uint32_t capabilities; /* 36 */
grub_uint8_t padding3[0x40 - 0x3a];
grub_uint16_t apm_version; /* 40 */
grub_uint16_t apm_code_segment; /* 42 */
grub_uint32_t apm_entry; /* 44 */
grub_uint16_t apm_16bit_code_segment; /* 48 */
grub_uint16_t apm_data_segment; /* 4a */
grub_uint16_t apm_flags; /* 4c */
grub_uint32_t apm_code_len; /* 4e */
grub_uint16_t apm_data_len; /* 52 */
grub_uint8_t padding4[0x60 - 0x54];
grub_uint32_t ist_signature; /* 60 */
grub_uint32_t ist_command; /* 64 */
grub_uint32_t ist_event; /* 68 */
grub_uint32_t ist_perf_level; /* 6c */
grub_uint8_t padding5[0x80 - 0x70];
grub_uint8_t hd0_drive_info[0x10]; /* 80 */
grub_uint8_t hd1_drive_info[0x10]; /* 90 */
grub_uint16_t rom_config_len; /* a0 */
grub_uint8_t padding6[0xb0 - 0xa2];
grub_uint32_t ofw_signature; /* b0 */
grub_uint32_t ofw_num_items; /* b4 */
grub_uint32_t ofw_cif_handler; /* b8 */
grub_uint32_t ofw_idt; /* bc */
grub_uint8_t padding7[0x1b8 - 0xc0];
union
{
struct
{
grub_uint32_t efi_system_table; /* 1b8 */
grub_uint32_t padding7_1; /* 1bc */
grub_uint32_t efi_signature; /* 1c0 */
grub_uint32_t efi_mem_desc_size; /* 1c4 */
grub_uint32_t efi_mem_desc_version; /* 1c8 */
grub_uint32_t efi_mmap_size; /* 1cc */
grub_uint32_t efi_mmap; /* 1d0 */
} v0204;
struct
{
grub_uint32_t padding7_1; /* 1b8 */
grub_uint32_t padding7_2; /* 1bc */
grub_uint32_t efi_signature; /* 1c0 */
grub_uint32_t efi_system_table; /* 1c4 */
grub_uint32_t efi_mem_desc_size; /* 1c8 */
grub_uint32_t efi_mem_desc_version; /* 1cc */
grub_uint32_t efi_mmap; /* 1d0 */
grub_uint32_t efi_mmap_size; /* 1d4 */
} v0206;
struct
{
grub_uint32_t padding7_1; /* 1b8 */
grub_uint32_t padding7_2; /* 1bc */
grub_uint32_t efi_signature; /* 1c0 */
grub_uint32_t efi_system_table; /* 1c4 */
grub_uint32_t efi_mem_desc_size; /* 1c8 */
grub_uint32_t efi_mem_desc_version; /* 1cc */
grub_uint32_t efi_mmap; /* 1d0 */
grub_uint32_t efi_mmap_size; /* 1d4 */
grub_uint32_t efi_system_table_hi; /* 1d8 */
grub_uint32_t efi_mmap_hi; /* 1dc */
} v0208;
};
grub_uint32_t alt_mem; /* 1e0 */
grub_uint8_t padding8[0x1e8 - 0x1e4];
grub_uint8_t mmap_size; /* 1e8 */
grub_uint8_t padding9[0x1f1 - 0x1e9];
grub_uint8_t setup_sects; /* The size of the setup in sectors */
grub_uint16_t root_flags; /* If the root is mounted readonly */
grub_uint16_t syssize; /* obsolete */
grub_uint16_t swap_dev; /* obsolete */
grub_uint16_t ram_size; /* obsolete */
grub_uint16_t vid_mode; /* Video mode control */
grub_uint16_t root_dev; /* Default root device number */
grub_uint8_t padding10; /* 1fe */
grub_uint8_t ps_mouse; /* 1ff */
grub_uint16_t jump; /* Jump instruction */
grub_uint32_t header; /* Magic signature "HdrS" */
grub_uint16_t version; /* Boot protocol version supported */
grub_uint32_t realmode_swtch; /* Boot loader hook */
grub_uint16_t start_sys; /* The load-low segment (obsolete) */
grub_uint16_t kernel_version; /* Points to kernel version string */
grub_uint8_t type_of_loader; /* Boot loader identifier */
grub_uint8_t loadflags; /* Boot protocol option flags */
grub_uint16_t setup_move_size; /* Move to high memory size */
grub_uint32_t code32_start; /* Boot loader hook */
grub_uint32_t ramdisk_image; /* initrd load address */
grub_uint32_t ramdisk_size; /* initrd size */
grub_uint32_t bootsect_kludge; /* obsolete */
grub_uint16_t heap_end_ptr; /* Free memory after setup end */
grub_uint8_t ext_loader_ver; /* Extended loader version */
grub_uint8_t ext_loader_type; /* Extended loader type */
grub_uint32_t cmd_line_ptr; /* Points to the kernel command line */
grub_uint32_t initrd_addr_max; /* Maximum initrd address */
grub_uint32_t kernel_alignment; /* Alignment of the kernel */
grub_uint8_t relocatable_kernel; /* Is the kernel relocatable */
grub_uint8_t pad1[3];
grub_uint32_t cmdline_size; /* Size of the kernel command line */
grub_uint32_t hardware_subarch;
grub_uint64_t hardware_subarch_data;
grub_uint32_t payload_offset;
grub_uint32_t payload_length;
grub_uint64_t setup_data;
grub_uint8_t pad2[120]; /* 258 */
struct grub_e820_mmap e820_map[(0x400 - 0x2d0) / 20]; /* 2d0 */
} __attribute__ ((packed));
Which in the GRUB2 is being constructed by parsing the EFI
data structures. But Linux concentrates on the EFI parts and mostly
ignores the rest. So this is more about passing those EFI values
downstream.
With this (and please correct me), my understanding is that with GRUB2
(Fedora's version) right now (without any patches) we can boot the Xen EFI
image. It will executute it as normal PE/COFF image. I don't know what
GRUB2 stanze arguments need to look like - and we don't support any
parameter parsing (either the Linux x86/boot protocol or the UEFI
standard - if there is any). But I believe GRUB2 still calls
ExitBootServices so not everything is peachy.
If we want to use the linuxefi module and its wealth of options we
would need to build the Xen EFI blob with the linux/x86 boot protocol
embedded in it. It looks like it can co-exist with PE/COFF. We would
have to handle the linux_kernel_parameters structure.
Lastly, we can also support the multiboot2 protocol extension that
Sun folks have come up. This means we don't have to build the binary
as PE/COFF and can get away with making it a gz image. Still need
to support the new format in Xen. There was talk of ARM using mutliboot2
but I don't know if that is still the case.
There is also the backwards compatible way of booting Xen with the
'fakebios' GRUB module. This will construct a fake BIOS payload so
that Xen will use that to get everything it needs. It even looks
to create an ACPI, SMBIOS, etc structures so anything that can't do
pure EFI can still boot.
We can also support all three: PE/COFF by itself launched from GRUB2
(ExitBootServices called, not too good), multiboot2 support, and
linuxefi, I think?
The disadvantage of multiboot2 is that it is not upstream. But the patches
do exist and it looks like they could be put in GRUB2 upstream. The neat
about them is that it also supports Solaris and can support any other
multboot payload type kernels (ie, non-Linux centric).
The advantage of linuxefi is that it is supported by all Linux distros right
now - so we would fit right away. We still have to fiddle with the
linux_kernel_parameters to get everything we want from it - which
is probably just the EFI stuff and we can ditch the rest.
On Tue, 2013-10-22 at 09:42 -0400, Konrad Rzeszutek Wilk wrote:
> Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is defined
> in the linux/Documentation/x86/boot.txt and hpa is pretty strict
> about making it backwards compatible. It also seems to support Xen!
>
> (Interestingly enough we do have this structure in the code: see
> setup_header in arch/x86/bzimage.c)
There will be another usage in tools/libxc/...bzimage too
FWIW I think we only use this stuff for the magic number/version and the
payload_offset/length fields, which we do in order to extract the
payload (ELF file) for booting dom0 and domU. It's not AFAIK used for
booting Xen itself or lets say, that's not why I added it ;-)).
> Which in the GRUB2 is being constructed by parsing the EFI
> data structures. But Linux concentrates on the EFI parts and mostly
> ignores the rest. So this is more about passing those EFI values
> downstream.
I wonder why Linux can't make the EFI calls to fetch them itself?
Ian.
On Tue, Oct 22, 2013 at 02:53:05PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 09:42 -0400, Konrad Rzeszutek Wilk wrote:
>
> > Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is defined
> > in the linux/Documentation/x86/boot.txt and hpa is pretty strict
> > about making it backwards compatible. It also seems to support Xen!
> >
> > (Interestingly enough we do have this structure in the code: see
> > setup_header in arch/x86/bzimage.c)
>
> There will be another usage in tools/libxc/...bzimage too
Right.
>
> FWIW I think we only use this stuff for the magic number/version and the
> payload_offset/length fields, which we do in order to extract the
> payload (ELF file) for booting dom0 and domU. It's not AFAIK used for
> booting Xen itself or lets say, that's not why I added it ;-)).
Right. I just meant that we have some of the code in the hypervisor
so using it to pass the EFI payload that way could be possible. But
then I realized it is pointless as we boot using the PV mechanism
which gets the EFI payload via hypercalls. So many ways to get this.
>
> > Which in the GRUB2 is being constructed by parsing the EFI
> > data structures. But Linux concentrates on the EFI parts and mostly
> > ignores the rest. So this is more about passing those EFI values
> > downstream.
>
> I wonder why Linux can't make the EFI calls to fetch them itself?
I believe it can if it is launched that way. Here is what I saw in the
Linux kernel:
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
* for initialization. Note, the efi init code path is determined by the
* global efi_enabled. This allows the same kernel image to be used on existing
* systems (with a traditional BIOS) as well as on EFI systems.
*/
Looking at arch/x86/boot/header.S in Linux I see some PE header and this
commit explains at lot:
commit 291f36325f9f252bd76ef5f603995f37e453fc60
Author: Matt Fleming <[email protected]>
Date: Mon Dec 12 21:27:52 2011 +0000
x86, efi: EFI boot stub support
There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,
"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."
This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.
The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.
Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
So it can be booted the same way as xen.efi. But my understanding is
that folks prefer a bootloader instead of loading the bzImage in an
NVRAM of a platform with pre-set parameters. Hence that mechanism
is not used by the majority of users.
Instead the majority of users would like to use a bootloader, like
GRUB2. And there are certain restrictions - if you launch from it
an PE/COFF application GRUB2 will call ExitBootServices. But if
you launch the Linux image (so using the linuxefi), it WILL NOT
call ExitBootServices.
But I say that (about ExitBootServices) - and I can't find it in
the GRUB2 code, so perhaps I am mistaken.
>>> On 22.10.13 at 15:53, Ian Campbell <[email protected]> wrote:
> On Tue, 2013-10-22 at 09:42 -0400, Konrad Rzeszutek Wilk wrote:
>
>> Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is
> defined
>> in the linux/Documentation/x86/boot.txt and hpa is pretty strict
>> about making it backwards compatible. It also seems to support Xen!
>>
>> (Interestingly enough we do have this structure in the code: see
>> setup_header in arch/x86/bzimage.c)
>
> There will be another usage in tools/libxc/...bzimage too
>
> FWIW I think we only use this stuff for the magic number/version and the
> payload_offset/length fields, which we do in order to extract the
> payload (ELF file) for booting dom0 and domU. It's not AFAIK used for
> booting Xen itself or lets say, that's not why I added it ;-)).
Indeed, we only use this to handle bzImage type kernels.
Jan
> I wonder why Linux can't make the EFI calls to fetch them itself?
It can. It does. It prefers to. This is what the "EFI boot stub" is all about. But grub2 is crack-inspired and likes to do all kinds of crap that it shouldn't. It is an exercise in complexity for complexity's sake. The 'linuxefi' method is actually not really Linux-specific; it just boots an EFI executable (which the bzImage *is* when compiled that way).
Seriously, forget bootloaders (especially grub2) and make it a COFF/PE executable. Then everything should just work, including Secure Boot etc.
And bootloaders can still load that, of course.
--
dwmw2
(Apologies for HTML and top-posting; Android mailer is broken.)
-------- Original message --------
From: Ian Campbell <[email protected]>
Date: 22/10/2013 2:53 PM (GMT+00:00)
To: Konrad Rzeszutek Wilk <[email protected]>
Cc: Jan Beulich <[email protected]>,[email protected],[email protected],[email protected],"Woodhouse, David" <[email protected]>,"Maliszewski, Richard L" <[email protected]>,[email protected],[email protected],Daniel Kiper <[email protected]>,Peter Jones <[email protected]>,[email protected],[email protected]
Subject: Re: EFI and multiboot2 devlopment work for Xen
On Tue, 2013-10-22 at 09:42 -0400, Konrad Rzeszutek Wilk wrote:
> Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is defined
> in the linux/Documentation/x86/boot.txt and hpa is pretty strict
> about making it backwards compatible. It also seems to support Xen!
>
> (Interestingly enough we do have this structure in the code: see
> setup_header in arch/x86/bzimage.c)
There will be another usage in tools/libxc/...bzimage too
FWIW I think we only use this stuff for the magic number/version and the
payload_offset/length fields, which we do in order to extract the
payload (ELF file) for booting dom0 and domU. It's not AFAIK used for
booting Xen itself or lets say, that's not why I added it ;-)).
> Which in the GRUB2 is being constructed by parsing the EFI
> data structures. But Linux concentrates on the EFI parts and mostly
> ignores the rest. So this is more about passing those EFI values
> downstream.
I wonder why Linux can't make the EFI calls to fetch them itself?
Ian.
On Tue, 2013-10-22 at 10:09 -0400, Konrad Rzeszutek Wilk wrote:
> So it can be booted the same way as xen.efi. But my understanding is
> that folks prefer a bootloader instead of loading the bzImage in an
> NVRAM of a platform with pre-set parameters. Hence that mechanism
> is not used by the majority of users.
My understanding is that they prefer a bootloader which can launch Linux
as a PE/COFF image, i.e. the linuxefi thing.
> Instead the majority of users would like to use a bootloader, like
> GRUB2. And there are certain restrictions - if you launch from it
> an PE/COFF application GRUB2 will call ExitBootServices. But if
> you launch the Linux image (so using the linuxefi), it WILL NOT
> call ExitBootServices.
"linuxefi" won't call ExitBootServices but it will launch as a PE/COFF
application not as a "Linux image", that's right isn't it? I think that
is the whole point of it.
The "launch as a Linux image" grub command is called just "linux" (and
"kernel" may be a synonym).
> But I say that (about ExitBootServices) - and I can't find it in
> the GRUB2 code, so perhaps I am mistaken.
linuxefi isn't in the upstream grub2 tree -- all the distros are
carrying it as a patch. So if you are grepping upstream you won't find
it.
Ian.
On Tue, Oct 22, 2013 at 09:42:52AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 22, 2013 at 10:59:33AM +0100, Jan Beulich wrote:
> > >>> On 22.10.13 at 11:45, Ian Campbell <[email protected]> wrote:
> > > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> > >> >>> On 22.10.13 at 11:26, Ian Campbell <[email protected]> wrote:
> > >> > AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
> > >> > Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
> > >> > It actually loads and executes the kernel binary as a PE/COFF executable
> > >> > (the native UEFI binary executable format). xen.efi is a PE/COFF binary
> > >> > too and could equally well be launched by linuxefi in this way.
> > >>
> > >> Except that unless I'm mistaken "linuxefi" still expects to find certain
> > >> Linux-specific internal data structures inside the PE image, which I
> > >> don't see us wanting to be emulating. That's the main difference to
> > >> "chainloader" afaict.
> > >
> > > Ah, I'd been led to believe it was just the lack of a call to
> > > ExitBootServices, but I didn't check. What you say sounds completely
> > > plausible.
> > >
> > > Do you know what sort of Linux specific data structures are we talking
> > > about?
> >
> > The setup header I would assume (i.e. the bits surrounding the
> > "HdrS" signature). But I'm only guessing anyway.
>
> This is a bit lengthy email, so please get your coffee/tea ready.
>
> Peter Jones was kind enough to educate me on IRC what it does. The
> GRUB2 module calls the PE/COFF executable (so using the Microsoft ABI
> for passing parameters) using this typedef:
>
> typedef void(*handover_func)(void *, grub_efi_system_table_t *, struct linux_kernel_params *);
>
> " and grub_cmd_linux (i.e. "linuxefi") does:
>
> if (!lh.handover_offset) { blah } ... handover_offset = lh.handover_offset
>
> and then allocates the linux_kernel_params using EFI's AllocatePool() as EFI_LOADER_DATA, and then just:
>
> hf = (handover_func)((char *)kernel_mem + handover_offset + offset);
> asm volatile ("cli");
> hf (grub_efi_image_handle, grub_efi_system_table, params);
> " (from conversation with Peter Jones).
>
> Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is defined
> in the linux/Documentation/x86/boot.txt and hpa is pretty strict
> about making it backwards compatible. It also seems to support Xen!
>
> (Interestingly enough we do have this structure in the code: see
> setup_header in arch/x86/bzimage.c)
>
> GRUB expects the image to have the 0xAA55 at a specific offset (0x01FE)
> otherwise it will stop the load.
>
> Then there is also the need to have at 0x202 the 'HdrS' string and
> and version id at (0x206). There is also at offset 0x264 the handover_offset
> which is what gets called (this I presume is the same as with PE/COFF
> images and it is expected that a native PE/COFF image would have the
> same location). Interestingly enough the Linux payload has both headers
> built-in - this boot one and also the Microsoft PE/COFF header. Meaning
> it can be launched as a normal PE/COFF binary or a boot loader can
> parse it and find the Linux x86 boot protocol. Pretty nifty.
>
> Anyhow, the handover function is called with three parameters. The
> third one is the extra 'struct linux_kernel_params' :
And looking at bit deeper in the x86/linux boot spec:
**** EFI HANDOVER PROTOCOL
This protocol allows boot loaders to defer initialisation to the EFI
boot stub. The boot loader is required to load the kernel/initrd(s)
from the boot media and jump to the EFI handover protocol entry point
which is hdr->handover_offset bytes from the beginning of
startup_{32,64}.
The function prototype for the handover entry point looks like this,
efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
'handle' is the EFI image handle passed to the boot loader by the EFI
firmware, 'table' is the EFI system table - these are the first two
arguments of the "handoff state" as described in section 2.3 of the
UEFI specification. 'bp' is the boot loader-allocated boot params.
The boot loader *must* fill out the following fields in bp,
o hdr.code32_start
o hdr.cmd_line_ptr
o hdr.cmdline_size
o hdr.ramdisk_image (if applicable)
o hdr.ramdisk_size (if applicable)
All other fields should be zero.
So not much in the third parameter.
And digging in the code (arch/x86/boot/compressed/head_64.S)
the handover_offset ends up pointing to efi_stub_entry which
calls this:
struct boot_params *efi_main(void *handle, efi_system_table_t *_table,
struct boot_params *boot_params)
If it Linux code is called as a normal PE/COFF image, then it ends
up calling efi_pe_entry, which generates a 'boot_params' structure
(see make_boot_params) based on the EFI.
On Tue, Oct 22, 2013 at 03:24:28PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 10:09 -0400, Konrad Rzeszutek Wilk wrote:
>
> > So it can be booted the same way as xen.efi. But my understanding is
> > that folks prefer a bootloader instead of loading the bzImage in an
> > NVRAM of a platform with pre-set parameters. Hence that mechanism
> > is not used by the majority of users.
>
> My understanding is that they prefer a bootloader which can launch Linux
> as a PE/COFF image, i.e. the linuxefi thing.
>
> > Instead the majority of users would like to use a bootloader, like
> > GRUB2. And there are certain restrictions - if you launch from it
> > an PE/COFF application GRUB2 will call ExitBootServices. But if
> > you launch the Linux image (so using the linuxefi), it WILL NOT
> > call ExitBootServices.
>
> "linuxefi" won't call ExitBootServices but it will launch as a PE/COFF
> application not as a "Linux image", that's right isn't it? I think that
> is the whole point of it.
No. The linuxefi will parse the payload and verify that it has the
Linux x86/boot protocol. So any PE/COFF image won't do.
(See grub_cmd_linux in grub-core/loader/i386/efi/linux.c)
If you use 'linux' module, it will call ExitBootService.
If you use 'multiboot' module, it will call ExitBootService too.
So if you don't want to the module to call 'grub_efi_finish_boot_services'
you need to use 'linuxefi' :-)
And I still haven't found the module that can launch any PE/COFF
image from GRUB2. Maybe that is a myth.
>
> The "launch as a Linux image" grub command is called just "linux" (and
> "kernel" may be a synonym).
>
> > But I say that (about ExitBootServices) - and I can't find it in
> > the GRUB2 code, so perhaps I am mistaken.
>
> linuxefi isn't in the upstream grub2 tree -- all the distros are
> carrying it as a patch. So if you are grepping upstream you won't find
> it.
Right, I am looking at Fedora 19's GRUB2 sources.
>
> Ian.
>
On Tue, Oct 22, 2013 at 02:18:52PM +0000, Woodhouse, David wrote:
>
> > I wonder why Linux can't make the EFI calls to fetch them itself?
>
> It can. It does. It prefers to. This is what the "EFI boot stub" is all about. But grub2 is crack-inspired and likes to do all kinds of crap that it shouldn't. It is an exercise in complexity for complexity's sake. The 'linuxefi' method is actually not really Linux-specific; it just boots an EFI executable (which the bzImage *is* when compiled that way).
Perhaps I am reading the wrong code, but I am unable to find this
in the source.
I am looking in grub_cmd_linux in grub-core/loader/i386/efi/linux.c (Fedora 19 src RPM)
and I see:
if (grub_file_read (file, &lh, sizeof (lh)) != sizeof (lh))
{
if (!grub_errno)
grub_error (GRUB_ERR_BAD_OS, N_("premature end of file %s"),
argv[0]);
goto fail;
}
if (lh.boot_flag != grub_cpu_to_le16 (0xaa55))
{
grub_error (GRUB_ERR_BAD_OS, N_("invalid magic number"));
goto fail;
}
if (lh.setup_sects > GRUB_LINUX_MAX_SETUP_SECTS)
{
grub_error (GRUB_ERR_BAD_OS, N_("too many setup sectors"));
goto fail;
}
.. snip..
if (!lh.handover_offset)
{
grub_error (GRUB_ERR_BAD_OS, N_("kernel doesn't support EFI handover"));
goto fail;
}
Which would imply that the header MUST have a Linux x86/boot header.
Which GRUB2 module can boot an non-Linux x86/boot header?
>
> Seriously, forget bootloaders (especially grub2) and make it a COFF/PE executable. Then everything should just work, including Secure Boot etc.
>
> And bootloaders can still load that, of course.
That 'that' is a standard PE/COFF image? Could you please point me
to the code that does that in GRUB2?
Thanks!
>>> On 22.10.13 at 16:51, Konrad Rzeszutek Wilk <[email protected]> wrote:
> And I still haven't found the module that can launch any PE/COFF
> image from GRUB2. Maybe that is a myth.
I can't exclude that this is a custom a patch as the linuxefi support.
Jan
On Tue, 2013-10-22 at 10:57 -0400, Konrad Rzeszutek Wilk wrote:
> That 'that' is a standard PE/COFF image? Could you please point me
> to the code that does that in GRUB2?
As I said earlier in the thread, it's a patch which is being carried by
all the distros. It is not in upstream grub.
For instance here is Debian's version:
http://anonscm.debian.org/loggerhead/pkg-grub/trunk/grub/download/head:/linuxefi.patch-20130129060348-21bhrqmbqj52c28w-1/linuxefi.patch
AIUI all the distros are carry basically the same patch.
Ian.
On Tue, 2013-10-22 at 15:24 +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 10:09 -0400, Konrad Rzeszutek Wilk wrote:
>
> > So it can be booted the same way as xen.efi. But my understanding is
> > that folks prefer a bootloader instead of loading the bzImage in an
> > NVRAM of a platform with pre-set parameters. Hence that mechanism
> > is not used by the majority of users.
>
> My understanding is that they prefer a bootloader which can launch Linux
> as a PE/COFF image, i.e. the linuxefi thing.
What I'm trying to say here is that from the xen.efi or linux.efi point
of view it can't tell if it was launched directly from the EFI shell or
by some intermediate bootloader (i.e. by grub2's linuxefi command).
Ian.
On Tue, 2013-10-22 at 14:18 +0000, Woodhouse, David wrote:
> > I wonder why Linux can't make the EFI calls to fetch them itself?
>
> It can. It does. It prefers to. This is what the "EFI boot stub" is all about.
Good, this is what I thought, glad to see I'm not talking out my behind
for once!
> Seriously, forget bootloaders (especially grub2) and make it a COFF/PE
> executable. Then everything should just work, including Secure Boot
> etc.
>
> And bootloaders can still load that, of course.
Ack!
Ian.
On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>
> And looking at bit deeper in the x86/linux boot spec:
>
> **** EFI HANDOVER PROTOCOL
>
> This protocol allows boot loaders to defer initialisation to the EFI
> boot stub. The boot loader is required to load the kernel/initrd(s)
> from the boot media and jump to the EFI handover protocol entry point
> which is hdr->handover_offset bytes from the beginning of
> startup_{32,64}.
Oh, ignore that. You want the *actual* PE executable entry point, as it
would get invoked by a real UEFI firmware.
I thought that's what Grub invoked, for 'linuxefi'. Perhaps I mean a
chainloader method of some kind instead. Either way, make Grub (or
whatever bootloader you choose) load it as an EFI executable.
Seriously, forget Grub for now. Grub is mostly just an exercise in
gratuitously doing things the difficult way and wondering why it's
fragile.
Make your code work as an EFI executable when loaded directly from the
UEFI firmware. Worry about the insanity of grub later.
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
On Tue, Oct 22, 2013 at 03:25:39PM +0000, Woodhouse, David wrote:
> Oh, ignore that. You want the *actual* PE executable entry point, as it
> would get invoked by a real UEFI firmware.
There are two problems with this:
1) The kernel will only boot if it's signed with a key in db, not a key
in MOK.
2) grub will read the kernel, but the kernel will have to read the
initramfs using EFI calls. That means your initramfs must be on a FAT
partition.
If you're happy with those limitations then just use the chainloader
command. If you're not, use the linuxefi command.
--
Matthew Garrett | [email protected]
On Tue, Oct 22, 2013 at 10:51:40AM -0400, Konrad Rzeszutek Wilk wrote:
> And I still haven't found the module that can launch any PE/COFF
> image from GRUB2. Maybe that is a myth.
"chainload" will do this. In fact, it doesn't do much:
static grub_err_t
grub_chainloader_boot (void)
{
grub_efi_boot_services_t *b;
grub_efi_status_t status;
grub_efi_uintn_t exit_data_size;
grub_efi_char16_t *exit_data = NULL;
b = grub_efi_system_table->boot_services;
status = efi_call_3 (b->start_image, image_handle, &exit_data_size, &exit_data);
if (status != GRUB_EFI_SUCCESS)
...
That means, of course, that it won't use shim on Secure Boot systems.
There's probably some value in merging the two, so that chainload will
use the efi stub if and only if a) it's present, and b) it's needed for
e.g. multiple initrds or bad UGA/GOP data.
--
Peter
On 22.10.2013 16:51, Konrad Rzeszutek Wilk wrote:
> If you use 'linux' module, it will call ExitBootService.
> If you use 'multiboot' module, it will call ExitBootService too.
>
> So if you don't want to the module to call 'grub_efi_finish_boot_services'
> you need to use 'linuxefi' :-)
That's a very limited logic. Commands can be modified and protocols can
be extended.
There was only one e-mail explaining the needs and I answered with
proposing possible solutions yet the 2 e-mails in question were
completely ignored.
What's the need behind not calling ExitBootService? This is a point
which was never really explained to me. EFI specification specifically
tells to call ExitBootService.
On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>
> There are two problems with this:
>
> 1) The kernel will only boot if it's signed with a key in db, not a key
> in MOK.
> 2) grub will read the kernel, but the kernel will have to read the
> initramfs using EFI calls. That means your initramfs must be on a FAT
> partition.
>
> If you're happy with those limitations then just use the chainloader
> command. If you're not, use the linuxefi command.
Well, we're talking about booting the Xen hypervisor aren't we?
So yes, there are reasons the Linux kernel uses the 'boot stub' the way
it does, but I'm not sure we advocate that Xen should emulate that in
all its 'glory'?
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
On Tue, Oct 22, 2013 at 03:42:42PM +0000, Woodhouse, David wrote:
> On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
> >
> > There are two problems with this:
> >
> > 1) The kernel will only boot if it's signed with a key in db, not a key
> > in MOK.
> > 2) grub will read the kernel, but the kernel will have to read the
> > initramfs using EFI calls. That means your initramfs must be on a FAT
> > partition.
> >
> > If you're happy with those limitations then just use the chainloader
> > command. If you're not, use the linuxefi command.
>
> Well, we're talking about booting the Xen hypervisor aren't we?
>
> So yes, there are reasons the Linux kernel uses the 'boot stub' the way
> it does, but I'm not sure we advocate that Xen should emulate that in
> all its 'glory'?
Right, I think that sensible mixture of multiboot2 protocol (it is needed
to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot protocol
for it) with extension proposed by Vladimir and something similar to linuxefi
command will solve our problem (I proposed it in my first email). Users which
do not need SB may use upstream GRUB2 and others could use
'multiboot2efi extension'.
Daniel
On Tue, 2013-10-22 at 18:01 +0200, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 03:42:42PM +0000, Woodhouse, David wrote:
> > On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
> > >
> > > There are two problems with this:
> > >
> > > 1) The kernel will only boot if it's signed with a key in db, not a key
> > > in MOK.
> > > 2) grub will read the kernel, but the kernel will have to read the
> > > initramfs using EFI calls. That means your initramfs must be on a FAT
> > > partition.
> > >
> > > If you're happy with those limitations then just use the chainloader
> > > command. If you're not, use the linuxefi command.
> >
> > Well, we're talking about booting the Xen hypervisor aren't we?
> >
> > So yes, there are reasons the Linux kernel uses the 'boot stub' the way
> > it does, but I'm not sure we advocate that Xen should emulate that in
> > all its 'glory'?
>
> Right, I think that sensible mixture of multiboot2 protocol (it is needed
> to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot protocol
> for it) with extension proposed by Vladimir and something similar to linuxefi
> command will solve our problem (I proposed it in my first email). Users which
> do not need SB may use upstream GRUB2 and others could use
> 'multiboot2efi extension'.
Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
of this stuff to me, it might be useful for you to get it from the
horses mouth instead of laundered through my brain (which is a bit
addled afterwards ;-)).
Ian.
On Tue, Oct 22, 2013 at 05:08:03PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 18:01 +0200, Daniel Kiper wrote:
> > On Tue, Oct 22, 2013 at 03:42:42PM +0000, Woodhouse, David wrote:
> > > On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
> > > >
> > > > There are two problems with this:
> > > >
> > > > 1) The kernel will only boot if it's signed with a key in db, not a key
> > > > in MOK.
> > > > 2) grub will read the kernel, but the kernel will have to read the
> > > > initramfs using EFI calls. That means your initramfs must be on a FAT
> > > > partition.
> > > >
> > > > If you're happy with those limitations then just use the chainloader
> > > > command. If you're not, use the linuxefi command.
> > >
> > > Well, we're talking about booting the Xen hypervisor aren't we?
> > >
> > > So yes, there are reasons the Linux kernel uses the 'boot stub' the way
> > > it does, but I'm not sure we advocate that Xen should emulate that in
> > > all its 'glory'?
> >
> > Right, I think that sensible mixture of multiboot2 protocol (it is needed
> > to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot protocol
> > for it) with extension proposed by Vladimir and something similar to linuxefi
> > command will solve our problem (I proposed it in my first email). Users which
> > do not need SB may use upstream GRUB2 and others could use
> > 'multiboot2efi extension'.
>
> Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
> of this stuff to me, it might be useful for you to get it from the
> horses mouth instead of laundered through my brain (which is a bit
> addled afterwards ;-)).
Sadly no. However, if it is possible/needed I could participate in conference call.
Daniel
On 22.10.2013 18:01, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 03:42:42PM +0000, Woodhouse, David wrote:
>> On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>>>
>>> There are two problems with this:
>>>
>>> 1) The kernel will only boot if it's signed with a key in db, not a key
>>> in MOK.
>>> 2) grub will read the kernel, but the kernel will have to read the
>>> initramfs using EFI calls. That means your initramfs must be on a FAT
>>> partition.
>>>
>>> If you're happy with those limitations then just use the chainloader
>>> command. If you're not, use the linuxefi command.
>>
>> Well, we're talking about booting the Xen hypervisor aren't we?
>>
>> So yes, there are reasons the Linux kernel uses the 'boot stub' the way
>> it does, but I'm not sure we advocate that Xen should emulate that in
>> all its 'glory'?
>
> Right, I think that sensible mixture of multiboot2 protocol (it is needed
> to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot protocol
> for it) with extension proposed by Vladimir and something similar to linuxefi
> command will solve our problem (I proposed it in my first email). Users which
> do not need SB may use upstream GRUB2 and others could use
> 'multiboot2efi extension'.
I think it's possible to handle secureboot with same multiboot2 base.
Correct me if I'm wrong but secureboot doesn't specify format of
signaatures, only that they should be present and checked.
So why not to make that the only difference between secureboot-enabled
and not-secureboot-enabled versions is that former enforces signatures
even against user will. This will reduce the policy-charger patch to
about 100 lines.
The signature format to use can be discussed as well. My main problem
with pe signatures as used for EFI is their apparent complexity but I
haven't looked in them yet.
>
> Daniel
>
> _______________________________________________
> Grub-devel mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
On Tue, Oct 22, 2013 at 04:21:47PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 10:57 -0400, Konrad Rzeszutek Wilk wrote:
> > That 'that' is a standard PE/COFF image? Could you please point me
> > to the code that does that in GRUB2?
>
> As I said earlier in the thread, it's a patch which is being carried by
> all the distros. It is not in upstream grub.
>
> For instance here is Debian's version:
> http://anonscm.debian.org/loggerhead/pkg-grub/trunk/grub/download/head:/linuxefi.patch-20130129060348-21bhrqmbqj52c28w-1/linuxefi.patch
>
That is the same patch that I see in Fedora's GRUB2.
That patch _only_ boots PE/COFF images with the Linux x86/boot
format. It won't boot standard PE/COFF images.
> AIUI all the distros are carry basically the same patch.
I concur.
>
> Ian.
>
On 22.10.2013 18:14, Daniel Kiper wrote:
>> > Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
>> > of this stuff to me, it might be useful for you to get it from the
>> > horses mouth instead of laundered through my brain (which is a bit
>> > addled afterwards ;-)).
What and when happens in Edinburgh? It's close enough to me and I might
be able to free myself if it's for collaboration with xen. I'd also like
to discuss grant tables version issue for pvgrub2 (which is almost ready)
On Tue, Oct 22, 2013 at 04:22:38PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 15:24 +0100, Ian Campbell wrote:
> > On Tue, 2013-10-22 at 10:09 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > > So it can be booted the same way as xen.efi. But my understanding is
> > > that folks prefer a bootloader instead of loading the bzImage in an
> > > NVRAM of a platform with pre-set parameters. Hence that mechanism
> > > is not used by the majority of users.
> >
> > My understanding is that they prefer a bootloader which can launch Linux
> > as a PE/COFF image, i.e. the linuxefi thing.
>
> What I'm trying to say here is that from the xen.efi or linux.efi point
> of view it can't tell if it was launched directly from the EFI shell or
> by some intermediate bootloader (i.e. by grub2's linuxefi command).
It can (at least in Linux). There are two entry points in the Linux kernel
and - one when it is launched from 'linuxefi' (See efi_stub_entry in
arch/x86/boot/compressed/head_64.S), the other when it is launched
from an EFI shell - see efi_pe_entry in arch/x86/boot/compressed/head_64.S.
On Tue, 2013-10-22 at 12:24 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 22, 2013 at 04:21:47PM +0100, Ian Campbell wrote:
> > On Tue, 2013-10-22 at 10:57 -0400, Konrad Rzeszutek Wilk wrote:
> > > That 'that' is a standard PE/COFF image? Could you please point me
> > > to the code that does that in GRUB2?
> >
> > As I said earlier in the thread, it's a patch which is being carried by
> > all the distros. It is not in upstream grub.
> >
> > For instance here is Debian's version:
> > http://anonscm.debian.org/loggerhead/pkg-grub/trunk/grub/download/head:/linuxefi.patch-20130129060348-21bhrqmbqj52c28w-1/linuxefi.patch
> >
>
> That is the same patch that I see in Fedora's GRUB2.
>
> That patch _only_ boots PE/COFF images with the Linux x86/boot
> format. It won't boot standard PE/COFF images.
Right, Matthew was just explaining this to me. :-(
>
> > AIUI all the distros are carry basically the same patch.
>
> I concur.
> >
> > Ian.
> >
On Tue, 2013-10-22 at 18:25 +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 22.10.2013 18:14, Daniel Kiper wrote:
> >> > Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
> >> > of this stuff to me, it might be useful for you to get it from the
> >> > horses mouth instead of laundered through my brain (which is a bit
> >> > addled afterwards ;-)).
> What and when happens in Edinburgh?
LinuxCon right now and Xen Summit on Thursday+Friday this week.
> It's close enough to me and I might
> be able to free myself if it's for collaboration with xen.
I suppose it is too short notice :-/
> I'd also like
> to discuss grant tables version issue for pvgrub2 (which is almost ready)
Cool!
Ian.
On Tue, Oct 22, 2013 at 05:39:24PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 22.10.2013 16:51, Konrad Rzeszutek Wilk wrote:
> > If you use 'linux' module, it will call ExitBootService.
> > If you use 'multiboot' module, it will call ExitBootService too.
> >
> > So if you don't want to the module to call 'grub_efi_finish_boot_services'
> > you need to use 'linuxefi' :-)
> That's a very limited logic. Commands can be modified and protocols can
> be extended.
> There was only one e-mail explaining the needs and I answered with
> proposing possible solutions yet the 2 e-mails in question were
> completely ignored.
This was before my time - so I am not exactly sure what was discussed.
You wouldn't by any chance have any URLs handy?
> What's the need behind not calling ExitBootService? This is a point
> which was never really explained to me. EFI specification specifically
> tells to call ExitBootService.
This commit points to it being a problem with the spec and hardware
implementations not being in sync:
commit 916f676f8dc016103f983c7ec54c18ecdbb6e349
Author: Matthew Garrett <[email protected]>
Date: Wed May 25 09:53:13 2011 -0400
x86, efi: Retain boot service code until after switching to virtual mode
UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
is an ancient African word meaning "Why do something right when you can
do it so wrong that children will weep and brave adults will cower before
you", and "UEI" is Celtic for "We missed DOS so we burned it into your
ROMs". The UEFI specification provides for runtime services (ie, another
way for the operating system to be forced to depend on the firmware) and
we rely on these for certain trivial tasks such as setting up the
bootloader. But some hardware fails to work if we attempt to use these
runtime services from physical mode, and so we have to switch into virtual
mode. So far so dreadful.
The specification makes it clear that the operating system is free to do
whatever it wants with boot services code after ExitBootServices() has been
called. SetVirtualAddressMap() can't be called until ExitBootServices() has
been. So, obviously, a whole bunch of EFI implementations call into boot
services code when we do that. Since we've been charmingly naive and
trusted that the specification may be somehow relevant to the real world,
we've already stuffed a picture of a penguin or something in that address
space. And just to make things more entertaining, we've also marked it
non-executable.
This patch allocates the boot services regions during EFI init and makes
sure that they're executable. Then, after SetVirtualAddressMap(), it
discards them and everyone lives happily ever after. Except for the ones
who have to work on EFI, who live sad lives haunted by the knowledge that
someone's eventually going to write yet another firmware specification.
[ hpa: adding this to urgent with a stable tag since it fixes currently-broken
hardware. However, I do not know what the dependencies are and so I do
not know which -stable versions this may be a candidate for. ]
Signed-off-by: Matthew Garrett <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
>
I may be off-base, but when I was wading through the grub2 code earlier
this year, it looked to me like it was going to refuse to launch anything
via MB1 or MB2 if the current state was a secure boot launch.
--Richard
On 10/22/13 9:24 AM, "Vladimir '$B&U(B-coder/phcoder' Serbinenko"
<[email protected]> wrote:
>On 22.10.2013 18:01, Daniel Kiper wrote:
>> On Tue, Oct 22, 2013 at 03:42:42PM +0000, Woodhouse, David wrote:
>>> On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>>>>
>>>> There are two problems with this:
>>>>
>>>> 1) The kernel will only boot if it's signed with a key in db, not a
>>>>key
>>>> in MOK.
>>>> 2) grub will read the kernel, but the kernel will have to read the
>>>> initramfs using EFI calls. That means your initramfs must be on a FAT
>>>> partition.
>>>>
>>>> If you're happy with those limitations then just use the chainloader
>>>> command. If you're not, use the linuxefi command.
>>>
>>> Well, we're talking about booting the Xen hypervisor aren't we?
>>>
>>> So yes, there are reasons the Linux kernel uses the 'boot stub' the way
>>> it does, but I'm not sure we advocate that Xen should emulate that in
>>> all its 'glory'?
>>
>> Right, I think that sensible mixture of multiboot2 protocol (it is
>>needed
>> to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot
>>protocol
>> for it) with extension proposed by Vladimir and something similar to
>>linuxefi
>> command will solve our problem (I proposed it in my first email). Users
>>which
>> do not need SB may use upstream GRUB2 and others could use
>> 'multiboot2efi extension'.
>I think it's possible to handle secureboot with same multiboot2 base.
>Correct me if I'm wrong but secureboot doesn't specify format of
>signaatures, only that they should be present and checked.
>So why not to make that the only difference between secureboot-enabled
>and not-secureboot-enabled versions is that former enforces signatures
>even against user will. This will reduce the policy-charger patch to
>about 100 lines.
>The signature format to use can be discussed as well. My main problem
>with pe signatures as used for EFI is their apparent complexity but I
>haven't looked in them yet.
>>
>> Daniel
>>
>> _______________________________________________
>> Grub-devel mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
On Tue, Oct 22, 2013 at 03:25:39PM +0000, Woodhouse, David wrote:
> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > And looking at bit deeper in the x86/linux boot spec:
> >
> > **** EFI HANDOVER PROTOCOL
> >
> > This protocol allows boot loaders to defer initialisation to the EFI
> > boot stub. The boot loader is required to load the kernel/initrd(s)
> > from the boot media and jump to the EFI handover protocol entry point
> > which is hdr->handover_offset bytes from the beginning of
> > startup_{32,64}.
>
> Oh, ignore that. You want the *actual* PE executable entry point, as it
> would get invoked by a real UEFI firmware.
Right. The Xen hypervisor can be built in two images: a standard PE/COFF
that can be executed from the EFI shell, and an multiboot blob that can
be loaded by multiboot compatible boot loaders (like GRUB).
>
> I thought that's what Grub invoked, for 'linuxefi'. Perhaps I mean a
> chainloader method of some kind instead. Either way, make Grub (or
> whatever bootloader you choose) load it as an EFI executable.
Looks like chainloader was it from Peter's answer. But then you can't
do SecureBoot <sigh>.
>
> Seriously, forget Grub for now. Grub is mostly just an exercise in
> gratuitously doing things the difficult way and wondering why it's
> fragile.
>
> Make your code work as an EFI executable when loaded directly from the
> UEFI firmware. Worry about the insanity of grub later.
That has been done by Jan. Now we are at the 'have a shim that launches
GRUB2, now what?'
>
>
> --
> Sent with MeeGo's ActiveSync support.
>
> David Woodhouse Open Source Technology Centre
> [email protected] Intel Corporation
>
>
>
> > Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
> > of this stuff to me, it might be useful for you to get it from the
> > horses mouth instead of laundered through my brain (which is a bit
> > addled afterwards ;-)).
>
> Sadly no. However, if it is possible/needed I could participate in conference call.
+1 (the conference call)
>
> Daniel
On Tue, Oct 22, 2013 at 04:36:04PM +0000, Maliszewski, Richard L wrote:
> I may be off-base, but when I was wading through the grub2 code earlier
> this year, it looked to me like it was going to refuse to launch anything
> via MB1 or MB2 if the current state was a secure boot launch.
Are you talking about upstream GRUB2 or GRUB2 with tons of distros
patches including linuxefi one. If later one it could be the case.
Daniel
On 22.10.2013 18:51, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 04:36:04PM +0000, Maliszewski, Richard L wrote:
>> I may be off-base, but when I was wading through the grub2 code earlier
>> this year, it looked to me like it was going to refuse to launch anything
>> via MB1 or MB2 if the current state was a secure boot launch.
>
> Are you talking about upstream GRUB2 or GRUB2 with tons of distros
> patches including linuxefi one. If later one it could be the case.
>
> Daniel
>
secureboot patch in its current state has only one goal: make microsoft
sign existing image and load linux. If we integrate it with GRUB
signatures check (as far as GNU policy permits but rest would be tiny)
then it will be a matter of choosing which way xen is going to be
signed. I'd recommend GnuPG detached signature (xen and xen.sig) but
don't insist on it.
В Mon, 21 Oct 2013 23:16:24 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <[email protected]> пишет:
> GRUB has generic support for signing kernels/modules/whatsoever using
> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
> method doesn't have any controversy associated with EFI stuff but at
> this particular case does exactly the same thing: verify signature.
> multiboot2 is mainly memory structure specification so probably how the
> files are checked is outside of its scope. But it's possible to add
> specification on how to embed signatures in kernel.
>
I'm a bit skeptical here. Given that
- EFI secure boot will still be needed to handle Windows
- kernel can be launched directly as EFI application
- there are other bootloaders with secure boot support
distributions will likely need to carry on EFI secure boot support. At
which point it is not clear what advantages second, parallel,
infrastructure for the sake of single application will bring.
The most compelling reason would be allowing module loading (which is
currently disabled by secure boot patches).
On 22.10.2013 19:12, Andrey Borzenkov wrote:
> В Mon, 21 Oct 2013 23:16:24 +0200
> Vladimir 'φ-coder/phcoder' Serbinenko <[email protected]> пишет:
>
>> GRUB has generic support for signing kernels/modules/whatsoever using
>> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
>> method doesn't have any controversy associated with EFI stuff but at
>> this particular case does exactly the same thing: verify signature.
>> multiboot2 is mainly memory structure specification so probably how the
>> files are checked is outside of its scope. But it's possible to add
>> specification on how to embed signatures in kernel.
>>
>
> I'm a bit skeptical here. Given that
>
> - EFI secure boot will still be needed to handle Windows
> - kernel can be launched directly as EFI application
> - there are other bootloaders with secure boot support
>
> distributions will likely need to carry on EFI secure boot support. At
> which point it is not clear what advantages second, parallel,
> infrastructure for the sake of single application will bring.
>
Using PE signatures is possible as I already said which invalidates your
points.
> The most compelling reason would be allowing module loading (which is
> currently disabled by secure boot patches).
>
The latter. The code I was looking at definitely has the linuxefi
directive. FWIW, if you install FC18/19 on an EFI system, the grub2
config file uses the linuxefi and companion initrd directives for launch.
--Richard
On 10/22/13 9:51 AM, "Daniel Kiper" <[email protected]> wrote:
>On Tue, Oct 22, 2013 at 04:36:04PM +0000, Maliszewski, Richard L wrote:
>> I may be off-base, but when I was wading through the grub2 code earlier
>> this year, it looked to me like it was going to refuse to launch
>>anything
>> via MB1 or MB2 if the current state was a secure boot launch.
>
>Are you talking about upstream GRUB2 or GRUB2 with tons of distros
>patches including linuxefi one. If later one it could be the case.
>
>Daniel
2013/10/23 Konrad Rzeszutek Wilk <[email protected]>:
> On Tue, Oct 22, 2013 at 03:25:39PM +0000, Woodhouse, David wrote:
>> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>> >
>> > And looking at bit deeper in the x86/linux boot spec:
>> >
>> > **** EFI HANDOVER PROTOCOL
>> >
>> > This protocol allows boot loaders to defer initialisation to the EFI
>> > boot stub. The boot loader is required to load the kernel/initrd(s)
>> > from the boot media and jump to the EFI handover protocol entry point
>> > which is hdr->handover_offset bytes from the beginning of
>> > startup_{32,64}.
>>
>> Oh, ignore that. You want the *actual* PE executable entry point, as it
>> would get invoked by a real UEFI firmware.
>
> Right. The Xen hypervisor can be built in two images: a standard PE/COFF
> that can be executed from the EFI shell, and an multiboot blob that can
> be loaded by multiboot compatible boot loaders (like GRUB).
>
>>
>> I thought that's what Grub invoked, for 'linuxefi'. Perhaps I mean a
>> chainloader method of some kind instead. Either way, make Grub (or
>> whatever bootloader you choose) load it as an EFI executable.
>
> Looks like chainloader was it from Peter's answer. But then you can't
> do SecureBoot <sigh>.
In SUSE/openSUSE we had a patch[1] in chainloader for supporting
shim's protocol to verify loaded EFI images. The efi image can be
loaded and verified by db or MOK keyrings.
[1] https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-secureboot-chainloader.patch?expand=1
With the linux foundation's PreLoader, that patch can be eliminated
totally as the verification is done via installed hook, where
verification result from MOK keyring is added, to authenticate file
protocol. The verification is thus transparent to UEFI applications so
any other loader, like shim, can be benefited from it.
The PreLoader has it's own controversy as that protocol is not part of
UEFI spec, instead it's part of PI spec for UEFI firmware
implementation thus shouldn't be used by an application (loader). It
could have compatibility problem ...
Regards,
Michael
>
>>
>> Seriously, forget Grub for now. Grub is mostly just an exercise in
>> gratuitously doing things the difficult way and wondering why it's
>> fragile.
>>
>> Make your code work as an EFI executable when loaded directly from the
>> UEFI firmware. Worry about the insanity of grub later.
>
> That has been done by Jan. Now we are at the 'have a shim that launches
> GRUB2, now what?'
>
>>
>>
>> --
>> Sent with MeeGo's ActiveSync support.
>>
>> David Woodhouse Open Source Technology Centre
>> [email protected] Intel Corporation
>>
>>
>>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
2013/10/23 Michael Chang <[email protected]>:
> 2013/10/23 Konrad Rzeszutek Wilk <[email protected]>:
>> On Tue, Oct 22, 2013 at 03:25:39PM +0000, Woodhouse, David wrote:
>>> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>>> >
>>> > And looking at bit deeper in the x86/linux boot spec:
>>> >
>>> > **** EFI HANDOVER PROTOCOL
>>> >
>>> > This protocol allows boot loaders to defer initialisation to the EFI
>>> > boot stub. The boot loader is required to load the kernel/initrd(s)
>>> > from the boot media and jump to the EFI handover protocol entry point
>>> > which is hdr->handover_offset bytes from the beginning of
>>> > startup_{32,64}.
>>>
>>> Oh, ignore that. You want the *actual* PE executable entry point, as it
>>> would get invoked by a real UEFI firmware.
>>
>> Right. The Xen hypervisor can be built in two images: a standard PE/COFF
>> that can be executed from the EFI shell, and an multiboot blob that can
>> be loaded by multiboot compatible boot loaders (like GRUB).
>>
>>>
>>> I thought that's what Grub invoked, for 'linuxefi'. Perhaps I mean a
>>> chainloader method of some kind instead. Either way, make Grub (or
>>> whatever bootloader you choose) load it as an EFI executable.
>>
>> Looks like chainloader was it from Peter's answer. But then you can't
>> do SecureBoot <sigh>.
>
> In SUSE/openSUSE we had a patch[1] in chainloader for supporting
> shim's protocol to verify loaded EFI images. The efi image can be
> loaded and verified by db or MOK keyrings.
>
> [1] https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-secureboot-chainloader.patch?expand=1
>
> With the linux foundation's PreLoader, that patch can be eliminated
> totally as the verification is done via installed hook, where
> verification result from MOK keyring is added, to authenticate file
> protocol. The verification is thus transparent to UEFI applications so
> any other loader, like shim, can be benefited from it.
Sorry, other loaders should be gummiboot, refind and so on ..
>
> The PreLoader has it's own controversy as that protocol is not part of
> UEFI spec, instead it's part of PI spec for UEFI firmware
> implementation thus shouldn't be used by an application (loader). It
> could have compatibility problem ...
>
> Regards,
> Michael
>>
>>>
>>> Seriously, forget Grub for now. Grub is mostly just an exercise in
>>> gratuitously doing things the difficult way and wondering why it's
>>> fragile.
>>>
>>> Make your code work as an EFI executable when loaded directly from the
>>> UEFI firmware. Worry about the insanity of grub later.
>>
>> That has been done by Jan. Now we are at the 'have a shim that launches
>> GRUB2, now what?'
>>
>>>
>>>
>>> --
>>> Sent with MeeGo's ActiveSync support.
>>>
>>> David Woodhouse Open Source Technology Centre
>>> [email protected] Intel Corporation
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
On Tue, Oct 22, 2013 at 09:42:52AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 22, 2013 at 10:59:33AM +0100, Jan Beulich wrote:
> > >>> On 22.10.13 at 11:45, Ian Campbell <[email protected]> wrote:
> > > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> > >> >>> On 22.10.13 at 11:26, Ian Campbell <[email protected]> wrote:
> > >> > AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
> > >> > Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
> > >> > It actually loads and executes the kernel binary as a PE/COFF executable
> > >> > (the native UEFI binary executable format). xen.efi is a PE/COFF binary
> > >> > too and could equally well be launched by linuxefi in this way.
> > >>
> > >> Except that unless I'm mistaken "linuxefi" still expects to find certain
> > >> Linux-specific internal data structures inside the PE image, which I
> > >> don't see us wanting to be emulating. That's the main difference to
> > >> "chainloader" afaict.
> > >
> > > Ah, I'd been led to believe it was just the lack of a call to
> > > ExitBootServices, but I didn't check. What you say sounds completely
> > > plausible.
> > >
> > > Do you know what sort of Linux specific data structures are we talking
> > > about?
> >
> > The setup header I would assume (i.e. the bits surrounding the
> > "HdrS" signature). But I'm only guessing anyway.
>
> This is a bit lengthy email, so please get your coffee/tea ready.
[...]
> We can also support all three: PE/COFF by itself launched from GRUB2
> (ExitBootServices called, not too good), multiboot2 support, and
> linuxefi, I think?
>
> The disadvantage of multiboot2 is that it is not upstream. But the patches
> do exist and it looks like they could be put in GRUB2 upstream. The neat
> about them is that it also supports Solaris and can support any other
> multboot payload type kernels (ie, non-Linux centric).
>
> The advantage of linuxefi is that it is supported by all Linux distros right
> now - so we would fit right away. We still have to fiddle with the
> linux_kernel_parameters to get everything we want from it - which
> is probably just the EFI stuff and we can ditch the rest.
Usage of Linux Boot protocol is quiet complicated in our case. It pases
one pointer to all initrd images loaded one by one into memory. So if
we would like to use it we will be forced to parse this blob to find
separate images. Not good. multiboot2 protocol passes list of pointers
to all loaded modules.
Daniel
On Tue, Oct 22, 2013 at 10:54:44AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > Mail is big, I think I got your essential points but I didn't read it whole.
> > On 21.10.2013 14:57, Daniel Kiper wrote:
> >> Hi,
> >>
> >> During work on multiboot2 protocol support for Xen it was discovered
> >> that memory map passed via relevant tag could not represent wide range
> >> of memory types available on EFI platforms. Additionally, GRUB2
> >> implementation calls ExitBootServices() on them just before jumping
> >> into loaded image. In this situation loaded system could not clearly
> >> identify reserved memory regions, EFI runtime services regions and others.
> >>
> > Will a multiboot2 tag with whole EFI memory map solve your problem?
> I added such a tag in documentation and wrote a patch for it (attached).
Thanks. Could you send me a pointer to current multiboot2 protocol docs?
> Awaiting for someone to test it to commit
On first sight it looks quite nice. However, as I know Solaris guys
prepared similar solution. I am not sure it was discussed with GRUB2
guys. However, I think that it is worth coordinating both works and
do not break existing solution if it is possible.
I will try to get more details about Solaris implementation.
Daniel
On Mon, Oct 21, 2013 at 11:16:24PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Mail is big, I think I got your essential points but I didn't read it whole.
> On 21.10.2013 14:57, Daniel Kiper wrote:
> > Hi,
> >
> > During work on multiboot2 protocol support for Xen it was discovered
> > that memory map passed via relevant tag could not represent wide range
> > of memory types available on EFI platforms. Additionally, GRUB2
> > implementation calls ExitBootServices() on them just before jumping
> > into loaded image. In this situation loaded system could not clearly
> > identify reserved memory regions, EFI runtime services regions and others.
> >
> Will a multiboot2 tag with whole EFI memory map solve your problem?
> > Additionally, it should be mentioned that there is no possibility or it could
> > be very difficult to implement secure boot on EFI platforms using GRUB2 as boot
> > loader because, as it was mentioned earlier, it calls ExitBootServices().
> >
> GRUB has generic support for signing kernels/modules/whatsoever using
> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
> method doesn't have any controversy associated with EFI stuff but at
> this particular case does exactly the same thing: verify signature.
> multiboot2 is mainly memory structure specification so probably how the
> files are checked is outside of its scope. But it's possible to add
> specification on how to embed signatures in kernel.
I think that EFI signatures should be supported because they are quite
common right now. However, I think that it is also worth to support
GnuPG signatures. This way anybody will be able to choose good solution
for a given case.
Daniel
On Tue, Oct 22, 2013 at 05:21:15PM +0000, Maliszewski, Richard L wrote:
> The latter. The code I was looking at definitely has the linuxefi
> directive. FWIW, if you install FC18/19 on an EFI system, the grub2
> config file uses the linuxefi and companion initrd directives for launch.
>
> --Richard
>
> On 10/22/13 9:51 AM, "Daniel Kiper" <[email protected]> wrote:
>
> >On Tue, Oct 22, 2013 at 04:36:04PM +0000, Maliszewski, Richard L wrote:
> >> I may be off-base, but when I was wading through the grub2 code earlier
> >> this year, it looked to me like it was going to refuse to launch
> >>anything
> >> via MB1 or MB2 if the current state was a secure boot launch.
> >
> >Are you talking about upstream GRUB2 or GRUB2 with tons of distros
> >patches including linuxefi one. If later one it could be the case.
I realized that in SB case GRUB2 with linuefi patches does not have
a lot features (correct me if I am wrong). So you are able to just
load Linux or something which supports Linux Boot protocol. It is
not so flexible as it was designed. I think that it should be changed
and support for others systems/hypervisors should be added without
breaking SB support of course. GRUB2 upstream solution is preferred.
Daniel
> On Oct 23, 2013, at 12:05 AM, Daniel Kiper <[email protected]> wrote:
>
>> On Tue, Oct 22, 2013 at 10:54:44AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> Mail is big, I think I got your essential points but I didn't read it whole.
>>>> On 21.10.2013 14:57, Daniel Kiper wrote:
>>>> Hi,
>>>>
>>>> During work on multiboot2 protocol support for Xen it was discovered
>>>> that memory map passed via relevant tag could not represent wide range
>>>> of memory types available on EFI platforms. Additionally, GRUB2
>>>> implementation calls ExitBootServices() on them just before jumping
>>>> into loaded image. In this situation loaded system could not clearly
>>>> identify reserved memory regions, EFI runtime services regions and others.
>>> Will a multiboot2 tag with whole EFI memory map solve your problem?
>> I added such a tag in documentation and wrote a patch for it (attached).
>
> Thanks. Could you send me a pointer to current multiboot2 protocol docs?
>
>> Awaiting for someone to test it to commit
>
> On first sight it looks quite nice. However, as I know Solaris guys
> prepared similar solution. I am not sure it was discussed with GRUB2
> guys. However, I think that it is worth coordinating both works and
> do not break existing solution if it is possible.
>
> I will try to get more details about Solaris implementation.
It's compatible. Vladimir based this change on the changes we made; we just need to test to verify.
--S
>
> Daniel
>
> _______________________________________________
> Grub-devel mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/grub-devel
On Tue, 2013-10-22 at 12:26 -0400, Konrad Rzeszutek Wilk wrote:
> It can (at least in Linux). There are two entry points in the Linux kernel
> and - one when it is launched from 'linuxefi' (See efi_stub_entry in
> arch/x86/boot/compressed/head_64.S), the other when it is launched
> from an EFI shell - see efi_pe_entry in arch/x86/boot/compressed/head_64.S.
Yes, it seems I was confused and spreading misinformation. Sorry!
Matthew explained this stuff to me yesterday, let me see if I can
regurgitate it. Hopefully Matthew can crrect the inevitable mistakes...
A kernel binary built with EFI stub support has three entry points:
* The traditional real mode "zImage" entry point
* The standard PE/COFF entry point
* A "Linux EFI" PE/COFF entry point
I think we can safely ignore the first of these for the purposes of this
conversation. I'm also going to ignore SB initially and cover it
separately at the end.
The second (standard PE/COFF entry point) can be launched using the UEFI
chainloader call. AIUI this should work with xen.efi today. There are
some limitations however, firstly there is no way to pass additional
blobs and so the launched image must load e.g. dom0 and initrd itself,
which Linux does by processing the initrd= option in the command line
and using UEFI functionality to load the blobs from disk. Xen does by
reading its own config file and loading dom0 + initrd based on that. I
assume this means that chainload doesn't call ExitBootServices (anyone
can confirm?). Another limitation of this is that the UEFI functionality
to load stuff from disk can only read from FAT partitions. It's not
clear to me if this mechanism limits only the loading of additional
blobs from FAT or if that applies to the kernel image itself. In reality
the blob and the kernel are usually stored in the same directory anyhow.
Is there a second method which can load standard PE/COFF images i.e.
some sort of "boot a kernel" method which calls ExitBootServices etc?
Even if this exists I don't think we can/want to use it.
The third ("Linux EFI" PE/COFF entry) is launched with the "efilinux"
patch to grub. This does not call ExitBootServices and also passes an
additional struct to the kernel which contains mostly (exactly? == is
the same struct) the same stuff as the traditional 16-bit entry point
would construct and pass to the 32-bit kernel. The EFI stub can also use
UEFI calls to get most (all?) of the same info. There was some related
madness about how the framebuffer is detected. Unlike the chainload
mechanism efilinux does not expect or provide PE/COFF relocation. The
kernel is PIC on entry so no relocations are actually needed. In theory
the Linux EFI stub could instead have included a NULL relocation table
but doesn't. (I expect Xen is in the same boat WRT relocations). I think
this method also provides a mechanism to provide a blob (AKA the initrd)
to the kernel, which means it can be loaded from any filesystem which
grub understands (not just FAT). There is only one which is a not
sufficient for Xen.
>From a SB point of view the major difference between chainload and
linuxefi is that chainload can only validate signatures against the UEFI
"core" key db (maintained by UEFI) while linuxefi can also use keys from
MOK db ("Machine Operator Key", which is a second DB provided and
maintained by "shim"). Michael was saying elsewhere in this thread that
SuSE at least have a patch which allow the chainload mechanism to use
MOK as well.
I hope that is an accurate braindump of what Matthew explained to me
yesterday, mistakes are naturally all mine ;-)
Am I correct that xen.efi today can be loaded from grub today using the
chainload command? Whereupon it will parse the xen.cfg and load the dom0
kernel and load things from FAT etc and everything just works. IOW
UEFI -> chainload(Xen)
and
UEFI -> chainload(grub) -> chainload(Xen)
work equivalently from the POV of Xen?
Ian.
On 23.10.2013 09:43, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 11:16:24PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Mail is big, I think I got your essential points but I didn't read it whole.
>> On 21.10.2013 14:57, Daniel Kiper wrote:
>>> Hi,
>>>
>>> During work on multiboot2 protocol support for Xen it was discovered
>>> that memory map passed via relevant tag could not represent wide range
>>> of memory types available on EFI platforms. Additionally, GRUB2
>>> implementation calls ExitBootServices() on them just before jumping
>>> into loaded image. In this situation loaded system could not clearly
>>> identify reserved memory regions, EFI runtime services regions and others.
>>>
>> Will a multiboot2 tag with whole EFI memory map solve your problem?
>>> Additionally, it should be mentioned that there is no possibility or it could
>>> be very difficult to implement secure boot on EFI platforms using GRUB2 as boot
>>> loader because, as it was mentioned earlier, it calls ExitBootServices().
>>>
>> GRUB has generic support for signing kernels/modules/whatsoever using
>> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
>> method doesn't have any controversy associated with EFI stuff but at
>> this particular case does exactly the same thing: verify signature.
>> multiboot2 is mainly memory structure specification so probably how the
>> files are checked is outside of its scope. But it's possible to add
>> specification on how to embed signatures in kernel.
>
> I think that EFI signatures should be supported because they are quite
> common right now. However, I think that it is also worth to support
> GnuPG signatures. This way anybody will be able to choose good solution
> for a given case.
>
Agreed.
> Daniel
>
On 23.10.2013 09:05, Daniel Kiper wrote:
> Thanks. Could you send me a pointer to current multiboot2 protocol docs?
It's managed as "multiboot2" branch in our repo:
http://git.savannah.gnu.org/cgit/grub.git
Note: we're in process of moving from bzr to git which may cause the
link to change.
On Wed, Oct 23, 2013 at 09:32:30AM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 12:26 -0400, Konrad Rzeszutek Wilk wrote:
> > It can (at least in Linux). There are two entry points in the Linux kernel
> > and - one when it is launched from 'linuxefi' (See efi_stub_entry in
> > arch/x86/boot/compressed/head_64.S), the other when it is launched
> > from an EFI shell - see efi_pe_entry in arch/x86/boot/compressed/head_64.S.
>
>
> Yes, it seems I was confused and spreading misinformation. Sorry!
>
> Matthew explained this stuff to me yesterday, let me see if I can
> regurgitate it. Hopefully Matthew can crrect the inevitable mistakes...
>
> A kernel binary built with EFI stub support has three entry points:
>
> * The traditional real mode "zImage" entry point
> * The standard PE/COFF entry point
> * A "Linux EFI" PE/COFF entry point
>
> I think we can safely ignore the first of these for the purposes of this
> conversation. I'm also going to ignore SB initially and cover it
> separately at the end.
>
> The second (standard PE/COFF entry point) can be launched using the UEFI
> chainloader call. AIUI this should work with xen.efi today. There are
> some limitations however, firstly there is no way to pass additional
> blobs and so the launched image must load e.g. dom0 and initrd itself,
> which Linux does by processing the initrd= option in the command line
> and using UEFI functionality to load the blobs from disk. Xen does by
> reading its own config file and loading dom0 + initrd based on that. I
> assume this means that chainload doesn't call ExitBootServices (anyone
> can confirm?). Another limitation of this is that the UEFI functionality
Confirmed.
> to load stuff from disk can only read from FAT partitions. It's not
> clear to me if this mechanism limits only the loading of additional
> blobs from FAT or if that applies to the kernel image itself. In reality
> the blob and the kernel are usually stored in the same directory anyhow.
>
> Is there a second method which can load standard PE/COFF images i.e.
> some sort of "boot a kernel" method which calls ExitBootServices etc?
> Even if this exists I don't think we can/want to use it.
None that I can find in GRUB2 - either upstream or Fedora's version.
>
> The third ("Linux EFI" PE/COFF entry) is launched with the "efilinux"
> patch to grub. This does not call ExitBootServices and also passes an
> additional struct to the kernel which contains mostly (exactly? == is
> the same struct) the same stuff as the traditional 16-bit entry point
> would construct and pass to the 32-bit kernel. The EFI stub can also use
> UEFI calls to get most (all?) of the same info. There was some related
> madness about how the framebuffer is detected. Unlike the chainload
> mechanism efilinux does not expect or provide PE/COFF relocation. The
> kernel is PIC on entry so no relocations are actually needed. In theory
> the Linux EFI stub could instead have included a NULL relocation table
> but doesn't. (I expect Xen is in the same boat WRT relocations). I think
> this method also provides a mechanism to provide a blob (AKA the initrd)
> to the kernel, which means it can be loaded from any filesystem which
> grub understands (not just FAT). There is only one which is a not
> sufficient for Xen.
Correct. Especially as we might have many binary blobs - microcode blob,
XSM blob, whoknowswhatblob, etc.
>
> >From a SB point of view the major difference between chainload and
> linuxefi is that chainload can only validate signatures against the UEFI
> "core" key db (maintained by UEFI) while linuxefi can also use keys from
> MOK db ("Machine Operator Key", which is a second DB provided and
> maintained by "shim"). Michael was saying elsewhere in this thread that
> SuSE at least have a patch which allow the chainload mechanism to use
> MOK as well.
>
> I hope that is an accurate braindump of what Matthew explained to me
> yesterday, mistakes are naturally all mine ;-)
>
> Am I correct that xen.efi today can be loaded from grub today using the
> chainload command? Whereupon it will parse the xen.cfg and load the dom0
> kernel and load things from FAT etc and everything just works. IOW
> UEFI -> chainload(Xen)
> and
> UEFI -> chainload(grub) -> chainload(Xen)
> work equivalently from the POV of Xen?
Yes. However it does require the user to know the magic values in the Xen
configuration file and setup the chainload stanze correctly. That means
if a user wishes to modify some of the bootup options they have to modify
the Xen configuration file. No runtime changes.
>From a distro standpoint the FAT part is painfull - as the common mechanism
for the /boot directory is to have it in ext2/ext3. But I presume you can
have _two_ boot partitions with GPT - one FAT and one ext2 and the tool
(dracut?) can push the images/config changes in both partitions.
Hence the idea of expanding GRUB2 to have an evercompassing multiboot2
protocol that will carry all the EFI bits and allow multiple
seperate payloads will require:
- not make an ExitBootServices call - which it does right now in the Solaris
GRUB2 case and in the Fedora GRUB2 case.
- Do the signature verification (hand-waving which one - probably both).
- Pack the right bits in the multiboot2 structure.
That will also require from the Xen side to:
- support parsing multiboot2 structure
And on the dracut side to create a new stanze that will use multiboot2 for
Xen.efi.
Easy :-)
On 23.10.2013 15:13, Konrad Rzeszutek Wilk wrote:
> - not make an ExitBootServices call - which it does right now in the Solaris
> GRUB2 case and in the Fedora GRUB2 case.
What about having a special tag in multiboot2 file header "RKEBSIHE":
"request to keep EFI boot services" and then bootloader will pass
another (empty, other than header) info tag: "Beware of EFI"
> - Do the signature verification (hand-waving which one - probably both).
Can someone throw me the link on the EFI signature specification? Can't
really find it now.
> - Pack the right bits in the multiboot2 structure.
As soon as my patch is tested for compatibility with Solaris, I commit
it. Tell me if you need sth else.
>>> Ian Campbell <[email protected]> 10/23/13 10:32 AM >>>
>The second (standard PE/COFF entry point) can be launched using the UEFI
>chainloader call. AIUI this should work with xen.efi today. There are
>some limitations however, firstly there is no way to pass additional
>blobs and so the launched image must load e.g. dom0 and initrd itself,
>which Linux does by processing the initrd= option in the command line
>and using UEFI functionality to load the blobs from disk. Xen does by
>reading its own config file and loading dom0 + initrd based on that. I
>assume this means that chainload doesn't call ExitBootServices (anyone
>can confirm?). Another limitation of this is that the UEFI functionality
>to load stuff from disk can only read from FAT partitions.
Again that's only a pseudo limitation: Rather than implementing support
for other file systems in GrUB, it should be implemented as EFI module.
Then any subsequent EFI binary would benefit from this. (Obviously, as
a half hearted intermediate solution, GrUB - which iiuc stays in memory
after transferring control - could export its file system support to its
descendants).
> It's not
>clear to me if this mechanism limits only the loading of additional
>blobs from FAT or if that applies to the kernel image itself.
Only the additional blobs would be affected.
> The
>kernel is PIC on entry so no relocations are actually needed. In theory
>the Linux EFI stub could instead have included a NULL relocation table
>but doesn't. (I expect Xen is in the same boat WRT relocations).
No, Xen definitely needs its relocations processed.
Jan
>>> Konrad Rzeszutek Wilk <[email protected]> 10/23/13 3:15 PM >>>
>On Wed, Oct 23, 2013 at 09:32:30AM +0100, Ian Campbell wrote:
>> Am I correct that xen.efi today can be loaded from grub today using the
>> chainload command? Whereupon it will parse the xen.cfg and load the dom0
>> kernel and load things from FAT etc and everything just works. IOW
>> UEFI -> chainload(Xen)
>> and
>> UEFI -> chainload(grub) -> chainload(Xen)
>> work equivalently from the POV of Xen?
>
>Yes. However it does require the user to know the magic values in the Xen
>configuration file and setup the chainload stanze correctly. That means
>if a user wishes to modify some of the bootup options they have to modify
>the Xen configuration file. No runtime changes.
Not necessarily - there's no reason for it being impossible to specify options
in the GrUB entry, nor for option added on the GrUB prompt (or its graphical
equivalent) to be passed to the chain loaded binary. If that doesn't already
work, it can't be really hard to implement.
Jan
> GrUB - which iiuc stays in memory
> after transferring control - could export its file system support to its
> descendants).
Xen shouldn't need to load any file after multiboot2 entry point. The
needed files would already be in memory with pointers to them passed.
If you insist on being able to load directly from EFI, then IMO the best
way is to have a PE executable with one of sections containing Xen and
code which would load remaining files to memory and call common entry point.
В Wed, 23 Oct 2013 16:07:38 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <[email protected]> пишет:
> > - Do the signature verification (hand-waving which one - probably both).
> Can someone throw me the link on the EFI signature specification? Can't
> really find it now.
It is in UEFI specs, specifically chapter 27 of UEFI 2.4, Secure Boot
and Driver Signature. Link to download: http://uefi.org/specs/access.
You need to accept agreement so I cannot post direct download link
(actually I do not have it handy).
>>> Vladimir 'φ-coder/phcoder' Serbinenko<[email protected]> 10/23/13 7:02 PM >>>
>> GrUB - which iiuc stays in memory
>> after transferring control - could export its file system support to its
>> descendants).
>
>Xen shouldn't need to load any file after multiboot2 entry point. The
>needed files would already be in memory with pointers to them passed.
I should have said "to its chainloaded descendants".
>If you insist on being able to load directly from EFI, then IMO the best
>way is to have a PE executable with one of sections containing Xen and
>code which would load remaining files to memory and call common entry point.
I think you've been told before - this is what has been working already for quite
some time.
Jan
On Tue, Oct 22, 2013 at 10:54:44AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > Mail is big, I think I got your essential points but I didn't read it whole.
> > On 21.10.2013 14:57, Daniel Kiper wrote:
> >> Hi,
> >>
> >> During work on multiboot2 protocol support for Xen it was discovered
> >> that memory map passed via relevant tag could not represent wide range
> >> of memory types available on EFI platforms. Additionally, GRUB2
> >> implementation calls ExitBootServices() on them just before jumping
> >> into loaded image. In this situation loaded system could not clearly
> >> identify reserved memory regions, EFI runtime services regions and others.
> >>
> > Will a multiboot2 tag with whole EFI memory map solve your problem?
> I added such a tag in documentation and wrote a patch for it (attached).
> Awaiting for someone to test it to commit
Great! I think from Xen perspective we first need to have Xen be able
to understand multiboot2 - that is something Daniel had been working on.
I will let Daniel talk more about it.
Seth, would you have any time to test the patch against Solaris to
make sure it works?
Thanks!
>
>>> Will a multiboot2 tag with whole EFI memory map solve your problem?
>> I added such a tag in documentation and wrote a patch for it (attached).
>> Awaiting for someone to test it to commit
>
> Great! I think from Xen perspective we first need to have Xen be able
> to understand multiboot2 - that is something Daniel had been working on.
> I will let Daniel talk more about it.
>
> Seth, would you have any time to test the patch against Solaris to
> make sure it works?
>
I've committed that patch. BTW do you want protected mode or long mode
entry point for x86_64 variant? Currently it's protected mode but I
planned to add long mode possibility but it wasn't a priority.
Hi,
Quoting Konrad Rzeszutek Wilk, who wrote the following on Mon, 28 Oct 2013:
> On Tue, Oct 22, 2013 at 10:54:44AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> Mail is big, I think I got your essential points but I didn't read it whole.
>>> On 21.10.2013 14:57, Daniel Kiper wrote:
>>>> Hi,
>>>>
>>>> During work on multiboot2 protocol support for Xen it was discovered
>>>> that memory map passed via relevant tag could not represent wide range
>>>> of memory types available on EFI platforms. Additionally, GRUB2
>>>> implementation calls ExitBootServices() on them just before jumping
>>>> into loaded image. In this situation loaded system could not clearly
>>>> identify reserved memory regions, EFI runtime services regions and others.
>>>>
>>> Will a multiboot2 tag with whole EFI memory map solve your problem?
>> I added such a tag in documentation and wrote a patch for it (attached).
>> Awaiting for someone to test it to commit
>
> Great! I think from Xen perspective we first need to have Xen be able
> to understand multiboot2 - that is something Daniel had been working on.
> I will let Daniel talk more about it.
>
> Seth, would you have any time to test the patch against Solaris to
> make sure it works?
I'd love to, yes. I'm just a bit short on time this week.
Thanks,
--S
>>> On 28.10.13 at 19:01, Vladimir 'f-coder/phcoder' Serbinenko<[email protected]> wrote:
>>>> Will a multiboot2 tag with whole EFI memory map solve your problem?
>>> I added such a tag in documentation and wrote a patch for it (attached).
>>> Awaiting for someone to test it to commit
>>
>> Great! I think from Xen perspective we first need to have Xen be able
>> to understand multiboot2 - that is something Daniel had been working on.
>> I will let Daniel talk more about it.
>>
>> Seth, would you have any time to test the patch against Solaris to
>> make sure it works?
>>
> I've committed that patch. BTW do you want protected mode or long mode
> entry point for x86_64 variant? Currently it's protected mode but I
> planned to add long mode possibility but it wasn't a priority.
32-bit protected mode is obviously the more consistent model
with multiboot1. But since we'll want to avoid switching back to
real mode when booted from UEFI, long mode would certainly
be an option too (just that the code paths would need to
diverge more).
Jan
Hi,
Here is a short summary of our discussion. It looks
that we have two choices right now:
- chainloader,
- multiboot2 protocol.
chainloader solution could be implemented quite easily. Some code should be
added for command line parsing. However, all arguments for Xen itself and
modules must be passed as single line with special separators (e.g. ///;
correct me if I am wrong). This thing makes that solution not very convenient,
especially if you would like to edit boot command line directly from boot
loader. chainloader will support PE images directly. However, it could load
only PE image with Xen. Xen image should load all other parts but they could
be loaded from FAT filesystem only. This works because it was implemented
in original Xen EFI implementation. Support for secure boot and shim loader
could be added. It was implemented by SUSE guys and is available in latest SUSE
distros. However, it is not merged into GRUB2 upstream (like linuxefi). I do
not know what are GRUB2 and SUSE guys plans to upstream this solution.
multiboot2 protocol requires some more changes. However, about 80% of code
is ready. In this case Xen and modules are loaded by GRUB2 itself. It means
that all images could be placed on any filesystem recognized by GRUB2. Options
for Xen and modules are passed separately which simplifies command line editing
in boot loader and parsing. multiboot2 protocol is very flexible and could be
easily extended in the future if a need arises. Support for secure boot and
shim loader could be added. However, it was not implemented yet. Probably
linuxefi module could be used as a reference or even as a base for development.
However, I do not know are there plans to support such solution by GRUB2
community. Currently, support for native PE images signatures and GPG signatures
is under development for GRUB2 upstream.
Personally I prefer multiboot2 protocol solution because it is much
more flexible and easier for use (even if it is more difficult to
implement).
There is still open question that ExitBootServices() should be called by GRUB2
loader or by loaded image itself on EFI platform. UEFI spec 2.4 states in many
places that it is "OS loader" or "Operating System" responsibility. However,
I think that "OS loader" should be understood as a integral piece of "Operating
System" responsible for its load into memory without usage of any additional
loader like GRUB2. So in this situation it looks that "Operating System" should
call ExitBootServices() on EFI platforms instead of GRUB2. Even if we agree that
this assumption is wrong I think that it is better to give an "Operating System"
a choice to use boot services. This way OS could decide which source of information
is more convenient in its case, do extra things with EFI platform support (e.g.
get memory map directly from EFI) and call ExitBootServices() in relevant time.
There is also third solution for issues with ExitBootServices(). In case
of multiboot2 protocol OS could request that EFI should be left as is.
Solution was proposed by Vladimir and I think that it makes sense. However,
this does not solve problem with ExitBootServices() in case of other
boot loaders/protocols. So we should take a decision accordingly to above
considerations in regards to linux, chainloader and similar stuff.
Daniel
On 30.10.2013 12:19, Daniel Kiper wrote:
> Hi,
> multiboot2 protocol requires some more changes. However, about 80% of code
> is ready. In this case Xen and modules are loaded by GRUB2 itself. It means
> that all images could be placed on any filesystem recognized by GRUB2. Options
> for Xen and modules are passed separately which simplifies command line editing
> in boot loader and parsing. multiboot2 protocol is very flexible and could be
> easily extended in the future if a need arises. Support for secure boot and
> shim loader could be added. However, it was not implemented yet. Probably
> linuxefi module could be used as a reference or even as a base for development.
> However, I do not know are there plans to support such solution by GRUB2
> community. Currently, support for native PE images signatures and GPG signatures
> is under development for GRUB2 upstream.
>
GPG signatures are supported already. My plan is as follows:
- Implement PE signatures upstream.
- Uplift as much of secureboot to upstream as policy permits. I would
like to be in partnership over this with some distro people so that they
can carry remaining part (unless FSF allows secureboot per policy)
> There is still open question that ExitBootServices() should be called by GRUB2
> loader or by loaded image itself on EFI platform. UEFI spec 2.4 states in many
> places that it is "OS loader" or "Operating System" responsibility. However,
> I think that "OS loader" should be understood as a integral piece of "Operating
> System" responsible for its load into memory without usage of any additional
> loader like GRUB2.
"Operating system" isn't just kernel. Everything you get in base install
is "Operating system" including i.a. shell or bootloader.
However this is kind of decision that couldn't be taken based on spec
alone. The bugs in real-world EFI implementations play more role in
design solutions that EFI specification.
> There is also third solution for issues with ExitBootServices(). In case
> of multiboot2 protocol OS could request that EFI should be left as is.
> Solution was proposed by Vladimir and I think that it makes sense.
I will write the specification draft for it then but probably not today.
> However,
> this does not solve problem with ExitBootServices() in case of other
> boot loaders/protocols.
multiboot2 was designed in a way not to be limited to GRUB2. It can be
added to other bootloaders as well.
> So we should take a decision accordingly to above
> considerations in regards to linux, chainloader and similar stuff.
>
> Daniel
>