* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 13:42 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 13:42 UTC (permalink / raw)
To: Jan Beulich
Cc: Ian Campbell, ross.philipson, stefano.stabellini, grub-devel,
david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Daniel Kiper, Peter Jones, linux-kernel, keir
On Tue, Oct 22, 2013 at 10:59:33AM +0100, Jan Beulich wrote:
> >>> On 22.10.13 at 11:45, Ian Campbell <ian.campbell@citrix.com> wrote:
> > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> >> >>> On 22.10.13 at 11:26, Ian Campbell <ian.campbell@citrix.com> 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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:42 ` Konrad Rzeszutek Wilk
(?)
@ 2013-10-22 13:53 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 13:53 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:42 ` Konrad Rzeszutek Wilk
@ 2013-10-22 13:53 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 13:53 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 13:53 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 13:53 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jan Beulich, ross.philipson, stefano.stabellini, grub-devel,
david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Daniel Kiper, Peter Jones, linux-kernel, keir
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:53 ` Ian Campbell
(?)
@ 2013-10-22 14:09 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:09 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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 <matt.fleming@intel.com>
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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:53 ` Ian Campbell
@ 2013-10-22 14:09 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:09 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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 <matt.fleming@intel.com>
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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 14:09 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:09 UTC (permalink / raw)
To: Ian Campbell
Cc: Jan Beulich, ross.philipson, stefano.stabellini, grub-devel,
david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Daniel Kiper, Peter Jones, linux-kernel, keir
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 <matt.fleming@intel.com>
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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:09 ` Konrad Rzeszutek Wilk
(?)
@ 2013-10-22 14:24 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 14:24 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:09 ` Konrad Rzeszutek Wilk
@ 2013-10-22 14:24 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 14:24 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 14:24 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 14:24 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jan Beulich, ross.philipson, stefano.stabellini, grub-devel,
david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Daniel Kiper, Peter Jones, linux-kernel, keir
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:24 ` Ian Campbell
(?)
@ 2013-10-22 14:51 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:51 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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.
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:24 ` Ian Campbell
@ 2013-10-22 14:51 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:51 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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.
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 14:51 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:51 UTC (permalink / raw)
To: Ian Campbell
Cc: Jan Beulich, ross.philipson, stefano.stabellini, grub-devel,
david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Daniel Kiper, Peter Jones, linux-kernel, keir
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.
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:51 ` Konrad Rzeszutek Wilk
(?)
@ 2013-10-22 14:59 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-22 14:59 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski,
Ian Campbell
>>> On 22.10.13 at 16:51, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:51 ` Konrad Rzeszutek Wilk
@ 2013-10-22 14:59 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-22 14:59 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, ross.philipson,
boris.ostrovsky, richard.l.maliszewski, Ian Campbell
>>> On 22.10.13 at 16:51, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 14:59 ` Jan Beulich
0 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-22 14:59 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ian Campbell, ross.philipson, stefano.stabellini, grub-devel,
david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Daniel Kiper, Peter Jones, linux-kernel, keir
>>> On 22.10.13 at 16:51, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:51 ` Konrad Rzeszutek Wilk
@ 2013-10-22 15:35 ` Peter Jones
-1 siblings, 0 replies; 238+ messages in thread
From: Peter Jones @ 2013-10-22 15:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, ross.philipson, Jan Beulich,
boris.ostrovsky, xen-devel, richard.l.maliszewski, Ian Campbell
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
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 15:35 ` Peter Jones
0 siblings, 0 replies; 238+ messages in thread
From: Peter Jones @ 2013-10-22 15:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ian Campbell, Jan Beulich, ross.philipson, stefano.stabellini,
grub-devel, david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Daniel Kiper, linux-kernel, keir
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:51 ` Konrad Rzeszutek Wilk
` (3 preceding siblings ...)
(?)
@ 2013-10-22 15:35 ` Peter Jones
-1 siblings, 0 replies; 238+ messages in thread
From: Peter Jones @ 2013-10-22 15:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, ross.philipson, Jan Beulich,
boris.ostrovsky, xen-devel, richard.l.maliszewski, Ian Campbell
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
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:51 ` Konrad Rzeszutek Wilk
` (4 preceding siblings ...)
(?)
@ 2013-10-22 15:39 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 15:39 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: keir, david.woodhouse, stefano.stabellini, Daniel Kiper,
linux-kernel, xen-devel, Jan Beulich, ross.philipson,
richard.l.maliszewski, boris.ostrovsky, Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 711 bytes --]
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.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:51 ` Konrad Rzeszutek Wilk
@ 2013-10-22 15:39 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 15:39 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: keir, david.woodhouse, stefano.stabellini, Daniel Kiper,
linux-kernel, xen-devel, Jan Beulich, ross.philipson,
richard.l.maliszewski, boris.ostrovsky, Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 15:39 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 15:39 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Konrad Rzeszutek Wilk, Ian Campbell, keir, david.woodhouse,
stefano.stabellini, Daniel Kiper, linux-kernel, xen-devel,
Jan Beulich, ross.philipson, boris.ostrovsky,
richard.l.maliszewski
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:39 ` Vladimir 'φ-coder/phcoder' Serbinenko
(?)
@ 2013-10-22 16:31 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:31 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: The development of GNU GRUB, keir, Ian Campbell,
stefano.stabellini, Daniel Kiper, linux-kernel, xen-devel,
Jan Beulich, ross.philipson, richard.l.maliszewski,
boris.ostrovsky, david.woodhouse
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 <mjg@redhat.com>
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 <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:39 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2013-10-22 16:31 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:31 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: The development of GNU GRUB, keir, Ian Campbell,
stefano.stabellini, Daniel Kiper, linux-kernel, xen-devel,
Jan Beulich, ross.philipson, richard.l.maliszewski,
boris.ostrovsky, david.woodhouse
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 <mjg@redhat.com>
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 <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com
>
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:31 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:31 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: The development of GNU GRUB, Ian Campbell, keir, david.woodhouse,
stefano.stabellini, Daniel Kiper, linux-kernel, xen-devel,
Jan Beulich, ross.philipson, boris.ostrovsky,
richard.l.maliszewski
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 <mjg@redhat.com>
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 <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-22 14:24 ` Ian Campbell
@ 2013-10-22 15:22 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, richard.l.maliszewski, boris.ostrovsky
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 15:22 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:22 ` Ian Campbell
(?)
@ 2013-10-22 16:26 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:26 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Peter Jones, Jan Beulich,
ross.philipson, richard.l.maliszewski, boris.ostrovsky
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-22 15:22 ` Ian Campbell
@ 2013-10-22 16:26 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:26 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, richard.l.maliszewski, boris.ostrovsky
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:26 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:26 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:26 ` Konrad Rzeszutek Wilk
(?)
@ 2013-10-23 8:32 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-23 8:32 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, Matthew Garrett, xen-devel,
Peter Jones, Jan Beulich, ross.philipson, richard.l.maliszewski,
boris.ostrovsky
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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-22 16:26 ` Konrad Rzeszutek Wilk
@ 2013-10-23 8:32 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-23 8:32 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, Matthew Garrett, xen-devel,
Jan Beulich, ross.philipson, richard.l.maliszewski,
boris.ostrovsky
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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 8:32 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-23 8:32 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski,
Matthew Garrett
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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 8:32 ` Ian Campbell
(?)
@ 2013-10-23 13:13 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-23 13:13 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, Matthew Garrett, xen-devel,
Peter Jones, Jan Beulich, ross.philipson, richard.l.maliszewski,
boris.ostrovsky
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 :-)
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-23 8:32 ` Ian Campbell
@ 2013-10-23 13:13 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-23 13:13 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, Matthew Garrett, xen-devel,
Jan Beulich, ross.philipson, richard.l.maliszewski,
boris.ostrovsky
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 :-)
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 13:13 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-23 13:13 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski,
Matthew Garrett
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 :-)
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-23 13:13 ` Konrad Rzeszutek Wilk
@ 2013-10-23 14:07 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-23 14:07 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Matthew Garrett, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, richard.l.maliszewski, boris.ostrovsky,
Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 14:07 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-23 14:07 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Konrad Rzeszutek Wilk, Ian Campbell, keir, david.woodhouse,
stefano.stabellini, Daniel Kiper, linux-kernel, Matthew Garrett,
xen-devel, Jan Beulich, ross.philipson, richard.l.maliszewski,
boris.ostrovsky
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 14:07 ` Vladimir 'φ-coder/phcoder' Serbinenko
(?)
@ 2013-10-23 17:13 ` Andrey Borzenkov
-1 siblings, 0 replies; 238+ messages in thread
From: Andrey Borzenkov @ 2013-10-23 17:13 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Matthew Garrett, keir, david.woodhouse, stefano.stabellini,
phcoder, Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, richard.l.maliszewski, boris.ostrovsky,
Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 537 bytes --]
В Wed, 23 Oct 2013 16:07:38 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> > - 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).
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-23 14:07 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2013-10-23 17:13 ` Andrey Borzenkov
-1 siblings, 0 replies; 238+ messages in thread
From: Andrey Borzenkov @ 2013-10-23 17:13 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Matthew Garrett, keir, david.woodhouse, stefano.stabellini,
phcoder, Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, richard.l.maliszewski, boris.ostrovsky,
Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
В Wed, 23 Oct 2013 16:07:38 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> > - 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).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 17:13 ` Andrey Borzenkov
0 siblings, 0 replies; 238+ messages in thread
From: Andrey Borzenkov @ 2013-10-23 17:13 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: phcoder, Matthew Garrett, keir, david.woodhouse,
stefano.stabellini, Daniel Kiper, linux-kernel, xen-devel,
Jan Beulich, ross.philipson, richard.l.maliszewski,
boris.ostrovsky, Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
В Wed, 23 Oct 2013 16:07:38 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> > - 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).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 13:13 ` Konrad Rzeszutek Wilk
(?)
(?)
@ 2013-10-23 14:07 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-23 14:07 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Matthew Garrett, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Jan Beulich,
ross.philipson, richard.l.maliszewski, boris.ostrovsky,
Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 714 bytes --]
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.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-23 13:13 ` Konrad Rzeszutek Wilk
@ 2013-10-23 16:17 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-23 16:17 UTC (permalink / raw)
To: ian.campbell, konrad.wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
daniel.kiper, linux-kernel, mjg59, xen-devel, ross.philipson,
boris.ostrovsky, richard.l.maliszewski
>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 16:17 ` Jan Beulich
0 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-23 16:17 UTC (permalink / raw)
To: ian.campbell, konrad.wilk
Cc: ross.philipson, stefano.stabellini, grub-devel, david.woodhouse,
richard.l.maliszewski, xen-devel, boris.ostrovsky, daniel.kiper,
pjones, mjg59, linux-kernel, keir
>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 13:13 ` Konrad Rzeszutek Wilk
` (3 preceding siblings ...)
(?)
@ 2013-10-23 16:17 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-23 16:17 UTC (permalink / raw)
To: ian.campbell, konrad.wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
daniel.kiper, linux-kernel, mjg59, xen-devel, pjones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-23 8:32 ` Ian Campbell
@ 2013-10-23 16:14 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-23 16:14 UTC (permalink / raw)
To: ian.campbell, konrad.wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
daniel.kiper, linux-kernel, mjg59, xen-devel, ross.philipson,
boris.ostrovsky, richard.l.maliszewski
>>> Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 16:14 ` Jan Beulich
0 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-23 16:14 UTC (permalink / raw)
To: ian.campbell, konrad.wilk
Cc: ross.philipson, stefano.stabellini, grub-devel, david.woodhouse,
richard.l.maliszewski, xen-devel, boris.ostrovsky, daniel.kiper,
pjones, mjg59, linux-kernel, keir
>>> Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 16:14 ` Jan Beulich
(?)
@ 2013-10-23 17:01 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-23 17:01 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: mjg59, keir, david.woodhouse, stefano.stabellini, daniel.kiper,
linux-kernel, xen-devel, Jan Beulich, ross.philipson,
richard.l.maliszewski, boris.ostrovsky, ian.campbell
[-- Attachment #1.1: Type: text/plain, Size: 502 bytes --]
> 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.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-23 16:14 ` Jan Beulich
@ 2013-10-23 17:01 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-23 17:01 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: mjg59, keir, david.woodhouse, stefano.stabellini, daniel.kiper,
linux-kernel, xen-devel, Jan Beulich, ross.philipson,
richard.l.maliszewski, boris.ostrovsky, ian.campbell
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
> 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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 17:01 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-23 17:01 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Jan Beulich, ian.campbell, konrad.wilk, keir, david.woodhouse,
stefano.stabellini, daniel.kiper, linux-kernel, mjg59, xen-devel,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
> 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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
2013-10-23 17:01 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2013-10-24 6:53 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-24 6:53 UTC (permalink / raw)
To: phcoder, grub-devel
Cc: mjg59, keir, david.woodhouse, stefano.stabellini, daniel.kiper,
linux-kernel, xen-devel, ross.philipson, boris.ostrovsky,
richard.l.maliszewski, ian.campbell
>>> Vladimir 'φ-coder/phcoder' Serbinenko<phcoder@gmail.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
@ 2013-10-24 6:53 ` Jan Beulich
0 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-24 6:53 UTC (permalink / raw)
To: phcoder, grub-devel
Cc: ian.campbell, ross.philipson, stefano.stabellini, david.woodhouse,
richard.l.maliszewski, xen-devel, boris.ostrovsky, daniel.kiper,
konrad.wilk, mjg59, linux-kernel, keir
>>> Vladimir 'φ-coder/phcoder' Serbinenko<phcoder@gmail.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 17:01 ` Vladimir 'φ-coder/phcoder' Serbinenko
(?)
(?)
@ 2013-10-24 6:53 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-24 6:53 UTC (permalink / raw)
To: phcoder, grub-devel
Cc: mjg59, keir, david.woodhouse, stefano.stabellini, daniel.kiper,
linux-kernel, xen-devel, ross.philipson, boris.ostrovsky,
richard.l.maliszewski, ian.campbell
>>> Vladimir 'φ-coder/phcoder' Serbinenko<phcoder@gmail.com> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 8:32 ` Ian Campbell
` (3 preceding siblings ...)
(?)
@ 2013-10-23 16:14 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-23 16:14 UTC (permalink / raw)
To: ian.campbell, konrad.wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
daniel.kiper, linux-kernel, mjg59, xen-devel, pjones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
>>> Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:24 ` Ian Campbell
` (3 preceding siblings ...)
(?)
@ 2013-10-22 15:22 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Peter Jones, Jan Beulich,
ross.philipson, richard.l.maliszewski, boris.ostrovsky
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:53 ` Ian Campbell
` (2 preceding siblings ...)
(?)
@ 2013-10-22 14:10 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-22 14:10 UTC (permalink / raw)
To: Ian Campbell, Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski
>>> On 22.10.13 at 15:53, Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:53 ` Ian Campbell
@ 2013-10-22 14:10 ` Jan Beulich
-1 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-22 14:10 UTC (permalink / raw)
To: Ian Campbell, Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, ross.philipson,
boris.ostrovsky, richard.l.maliszewski
>>> On 22.10.13 at 15:53, Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 14:10 ` Jan Beulich
0 siblings, 0 replies; 238+ messages in thread
From: Jan Beulich @ 2013-10-22 14:10 UTC (permalink / raw)
To: Ian Campbell, Konrad Rzeszutek Wilk
Cc: ross.philipson, stefano.stabellini, grub-devel, david.woodhouse,
richard.l.maliszewski, xen-devel, boris.ostrovsky, Daniel Kiper,
Peter Jones, linux-kernel, keir
>>> On 22.10.13 at 15:53, Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:53 ` Ian Campbell
@ 2013-10-22 14:18 ` Woodhouse, David
-1 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 14:18 UTC (permalink / raw)
To: Ian Campbell, Konrad Rzeszutek Wilk
Cc: grub-devel@gnu.org, keir@xen.org, Jan Beulich,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
ross.philipson@citrix.com, boris.ostrovsky@oracle.com,
Maliszewski, Richard L
> 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 <ian.campbell@citrix.com>
Date: 22/10/2013 2:53 PM (GMT+00:00)
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>,ross.philipson@citrix.com,stefano.stabellini@eu.citrix.com,grub-devel@gnu.org,"Woodhouse, David" <david.woodhouse@intel.com>,"Maliszewski, Richard L" <richard.l.maliszewski@intel.com>,xen-devel@lists.xen.org,boris.ostrovsky@oracle.com,Daniel Kiper <daniel.kiper@oracle.com>,Peter Jones <pjones@redhat.com>,linux-kernel@vger.kernel.org,keir@xen.org
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 14:18 ` Woodhouse, David
0 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 14:18 UTC (permalink / raw)
To: Ian Campbell, Konrad Rzeszutek Wilk
Cc: Jan Beulich, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Daniel Kiper, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
> 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 <ian.campbell@citrix.com>
Date: 22/10/2013 2:53 PM (GMT+00:00)
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>,ross.philipson@citrix.com,stefano.stabellini@eu.citrix.com,grub-devel@gnu.org,"Woodhouse, David" <david.woodhouse@intel.com>,"Maliszewski, Richard L" <richard.l.maliszewski@intel.com>,xen-devel@lists.xen.org,boris.ostrovsky@oracle.com,Daniel Kiper <daniel.kiper@oracle.com>,Peter Jones <pjones@redhat.com>,linux-kernel@vger.kernel.org,keir@xen.org
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:18 ` Woodhouse, David
@ 2013-10-22 14:57 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:57 UTC (permalink / raw)
To: Woodhouse, David
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Jan Beulich, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
Maliszewski, Richard L
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!
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 14:57 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:57 UTC (permalink / raw)
To: Woodhouse, David
Cc: Ian Campbell, Jan Beulich, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Daniel Kiper, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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!
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:57 ` Konrad Rzeszutek Wilk
@ 2013-10-22 15:21 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:21 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel@gnu.org, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Jan Beulich, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
Maliszewski, Richard L
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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 15:21 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:21 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Woodhouse, David, Jan Beulich, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Daniel Kiper, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:21 ` Ian Campbell
@ 2013-10-22 16:24 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:24 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel@gnu.org, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Jan Beulich, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
Maliszewski, Richard L
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.
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:24 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:24 UTC (permalink / raw)
To: Ian Campbell
Cc: Woodhouse, David, Jan Beulich, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Daniel Kiper, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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.
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:24 ` Konrad Rzeszutek Wilk
@ 2013-10-22 16:27 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:27 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel@gnu.org, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Jan Beulich, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
Maliszewski, Richard L
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.
> >
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:27 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:27 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Woodhouse, David, Jan Beulich, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Daniel Kiper, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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.
> >
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:24 ` Konrad Rzeszutek Wilk
(?)
(?)
@ 2013-10-22 16:27 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:27 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel@gnu.org, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Peter Jones, Jan Beulich, boris.ostrovsky@oracle.com,
xen-devel@lists.xen.org, Maliszewski, Richard L
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.
> >
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:21 ` Ian Campbell
(?)
(?)
@ 2013-10-22 16:24 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:24 UTC (permalink / raw)
To: Ian Campbell
Cc: grub-devel@gnu.org, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Peter Jones, Jan Beulich, boris.ostrovsky@oracle.com,
xen-devel@lists.xen.org, Maliszewski, Richard L
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.
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:57 ` Konrad Rzeszutek Wilk
(?)
(?)
@ 2013-10-22 15:21 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:21 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel@gnu.org, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Peter Jones, Jan Beulich, boris.ostrovsky@oracle.com,
xen-devel@lists.xen.org, Maliszewski, Richard L
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:18 ` Woodhouse, David
(?)
(?)
@ 2013-10-22 14:57 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:57 UTC (permalink / raw)
To: Woodhouse, David
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Peter Jones, Jan Beulich, boris.ostrovsky@oracle.com,
xen-devel@lists.xen.org, Maliszewski, Richard L
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!
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:18 ` Woodhouse, David
@ 2013-10-22 15:23 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:23 UTC (permalink / raw)
To: Woodhouse, David
Cc: grub-devel@gnu.org, keir@xen.org, Jan Beulich,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
ross.philipson@citrix.com, boris.ostrovsky@oracle.com,
Maliszewski, Richard L
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 15:23 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:23 UTC (permalink / raw)
To: Woodhouse, David
Cc: Konrad Rzeszutek Wilk, Jan Beulich, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Daniel Kiper, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:18 ` Woodhouse, David
` (3 preceding siblings ...)
(?)
@ 2013-10-22 15:23 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 15:23 UTC (permalink / raw)
To: Woodhouse, David
Cc: grub-devel@gnu.org, keir@xen.org, Jan Beulich,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Peter Jones, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:53 ` Ian Campbell
` (5 preceding siblings ...)
(?)
@ 2013-10-22 14:18 ` Woodhouse, David
-1 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 14:18 UTC (permalink / raw)
To: Ian Campbell, Konrad Rzeszutek Wilk
Cc: grub-devel@gnu.org, keir@xen.org, Jan Beulich,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Peter Jones, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
> 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 <ian.campbell@citrix.com>
Date: 22/10/2013 2:53 PM (GMT+00:00)
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>,ross.philipson@citrix.com,stefano.stabellini@eu.citrix.com,grub-devel@gnu.org,"Woodhouse, David" <david.woodhouse@intel.com>,"Maliszewski, Richard L" <richard.l.maliszewski@intel.com>,xen-devel@lists.xen.org,boris.ostrovsky@oracle.com,Daniel Kiper <daniel.kiper@oracle.com>,Peter Jones <pjones@redhat.com>,linux-kernel@vger.kernel.org,keir@xen.org
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:42 ` Konrad Rzeszutek Wilk
` (2 preceding siblings ...)
(?)
@ 2013-10-22 14:43 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:43 UTC (permalink / raw)
To: Jan Beulich
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, Peter Jones,
ross.philipson, boris.ostrovsky, richard.l.maliszewski,
Ian Campbell
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 <ian.campbell@citrix.com> wrote:
> > > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> > >> >>> On 22.10.13 at 11:26, Ian Campbell <ian.campbell@citrix.com> 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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:42 ` Konrad Rzeszutek Wilk
@ 2013-10-22 14:43 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:43 UTC (permalink / raw)
To: Jan Beulich
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
Daniel Kiper, linux-kernel, xen-devel, ross.philipson,
boris.ostrovsky, richard.l.maliszewski, Ian Campbell
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 <ian.campbell@citrix.com> wrote:
> > > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> > >> >>> On 22.10.13 at 11:26, Ian Campbell <ian.campbell@citrix.com> 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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 14:43 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 14:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Ian Campbell, ross.philipson, stefano.stabellini, grub-devel,
david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Daniel Kiper, Peter Jones, linux-kernel, keir
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 <ian.campbell@citrix.com> wrote:
> > > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> > >> >>> On 22.10.13 at 11:26, Ian Campbell <ian.campbell@citrix.com> 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.
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:43 ` Konrad Rzeszutek Wilk
@ 2013-10-22 15:25 ` Woodhouse, David
-1 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 15:25 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Jan Beulich, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
Maliszewski, Richard L
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
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
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4370 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 15:25 ` Woodhouse, David
0 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 15:25 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jan Beulich, Ian Campbell, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Daniel Kiper, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
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
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4370 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:25 ` Woodhouse, David
@ 2013-10-22 15:32 ` Matthew Garrett
-1 siblings, 0 replies; 238+ messages in thread
From: Matthew Garrett @ 2013-10-22 15:32 UTC (permalink / raw)
To: Woodhouse, David
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
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 | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 15:32 ` Matthew Garrett
0 siblings, 0 replies; 238+ messages in thread
From: Matthew Garrett @ 2013-10-22 15:32 UTC (permalink / raw)
To: Woodhouse, David
Cc: Konrad Rzeszutek Wilk, Jan Beulich, Ian Campbell,
ross.philipson@citrix.com, stefano.stabellini@eu.citrix.com,
grub-devel@gnu.org, Maliszewski, Richard L,
xen-devel@lists.xen.org, boris.ostrovsky@oracle.com, Daniel Kiper,
Peter Jones, linux-kernel@vger.kernel.org, keir@xen.org
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 | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:32 ` Matthew Garrett
@ 2013-10-22 15:42 ` Woodhouse, David
-1 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 15:42 UTC (permalink / raw)
To: Matthew Garrett
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
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
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4370 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 15:42 ` Woodhouse, David
0 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 15:42 UTC (permalink / raw)
To: Matthew Garrett
Cc: Konrad Rzeszutek Wilk, Jan Beulich, Ian Campbell,
ross.philipson@citrix.com, stefano.stabellini@eu.citrix.com,
grub-devel@gnu.org, Maliszewski, Richard L,
xen-devel@lists.xen.org, boris.ostrovsky@oracle.com, Daniel Kiper,
Peter Jones, linux-kernel@vger.kernel.org, keir@xen.org
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
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
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4370 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:42 ` Woodhouse, David
(?)
@ 2013-10-22 16:01 ` Daniel Kiper
-1 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:01 UTC (permalink / raw)
To: Woodhouse, David
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, Peter Jones,
ross.philipson@citrix.com, boris.ostrovsky@oracle.com,
Maliszewski, Richard L, grub-devel@gnu.org
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:42 ` Woodhouse, David
@ 2013-10-22 16:01 ` Daniel Kiper
-1 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:01 UTC (permalink / raw)
To: Woodhouse, David
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L,
grub-devel@gnu.org
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:01 ` Daniel Kiper
0 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:01 UTC (permalink / raw)
To: Woodhouse, David
Cc: Matthew Garrett, Konrad Rzeszutek Wilk, Jan Beulich, Ian Campbell,
ross.philipson@citrix.com, stefano.stabellini@eu.citrix.com,
grub-devel@gnu.org, Maliszewski, Richard L,
xen-devel@lists.xen.org, boris.ostrovsky@oracle.com, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:01 ` Daniel Kiper
(?)
@ 2013-10-22 16:08 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:08 UTC (permalink / raw)
To: Daniel Kiper
Cc: Matthew Garrett, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, Peter Jones,
ross.philipson@citrix.com, boris.ostrovsky@oracle.com,
Maliszewski, Richard L, grub-devel@gnu.org
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:01 ` Daniel Kiper
@ 2013-10-22 16:08 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:08 UTC (permalink / raw)
To: Daniel Kiper
Cc: Matthew Garrett, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L,
grub-devel@gnu.org
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:08 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:08 UTC (permalink / raw)
To: Daniel Kiper
Cc: Woodhouse, David, Matthew Garrett, Konrad Rzeszutek Wilk,
Jan Beulich, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:08 ` Ian Campbell
@ 2013-10-22 16:14 ` Daniel Kiper
-1 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:14 UTC (permalink / raw)
To: Ian Campbell
Cc: Matthew Garrett, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L,
grub-devel@gnu.org
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:14 ` Daniel Kiper
0 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:14 UTC (permalink / raw)
To: Ian Campbell
Cc: Woodhouse, David, Matthew Garrett, Konrad Rzeszutek Wilk,
Jan Beulich, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:14 ` Daniel Kiper
(?)
@ 2013-10-22 16:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 16:25 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com, Maliszewski, Richard L,
boris.ostrovsky@oracle.com, Woodhouse, David
[-- Attachment #1.1: Type: text/plain, Size: 520 bytes --]
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)
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:14 ` Daniel Kiper
@ 2013-10-22 16:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 16:25 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com, Maliszewski, Richard L,
boris.ostrovsky@oracle.com, Woodhouse, David
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
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)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 16:25 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Daniel Kiper, Ian Campbell, Matthew Garrett, keir@xen.org,
Woodhouse, David, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
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)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
(?)
@ 2013-10-22 16:31 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:31 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: The development of GNU GRUB, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, Matthew Garrett,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
Maliszewski, Richard L, boris.ostrovsky@oracle.com
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2013-10-22 16:31 ` Ian Campbell
-1 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:31 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: The development of GNU GRUB, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, Matthew Garrett,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
Maliszewski, Richard L, boris.ostrovsky@oracle.com
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:31 ` Ian Campbell
0 siblings, 0 replies; 238+ messages in thread
From: Ian Campbell @ 2013-10-22 16:31 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: The development of GNU GRUB, Daniel Kiper, Matthew Garrett,
keir@xen.org, Woodhouse, David, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
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.
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:14 ` Daniel Kiper
@ 2013-10-22 16:38 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:38 UTC (permalink / raw)
To: Daniel Kiper
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L,
grub-devel@gnu.org, Woodhouse, David
> > 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:38 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:38 UTC (permalink / raw)
To: Daniel Kiper
Cc: Ian Campbell, Woodhouse, David, Matthew Garrett, Jan Beulich,
ross.philipson@citrix.com, stefano.stabellini@eu.citrix.com,
grub-devel@gnu.org, Maliszewski, Richard L,
xen-devel@lists.xen.org, boris.ostrovsky@oracle.com, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
> > 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:14 ` Daniel Kiper
` (3 preceding siblings ...)
(?)
@ 2013-10-22 16:38 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:38 UTC (permalink / raw)
To: Daniel Kiper
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, Peter Jones,
ross.philipson@citrix.com, boris.ostrovsky@oracle.com,
Maliszewski, Richard L, grub-devel@gnu.org, Woodhouse, David
> > 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:08 ` Ian Campbell
(?)
(?)
@ 2013-10-22 16:14 ` Daniel Kiper
-1 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:14 UTC (permalink / raw)
To: Ian Campbell
Cc: Matthew Garrett, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, Peter Jones,
ross.philipson@citrix.com, boris.ostrovsky@oracle.com,
Maliszewski, Richard L, grub-devel@gnu.org
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:01 ` Daniel Kiper
@ 2013-10-22 16:24 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 16:24 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Matthew Garrett, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com, Maliszewski, Richard L,
boris.ostrovsky@oracle.com, Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:24 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 16:24 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Daniel Kiper, Woodhouse, David, Matthew Garrett, keir@xen.org,
Ian Campbell, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:24 ` Vladimir 'φ-coder/phcoder' Serbinenko
(?)
@ 2013-10-22 16:36 ` Maliszewski, Richard L
-1 siblings, 0 replies; 238+ messages in thread
From: Maliszewski, Richard L @ 2013-10-22 16:36 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko,
The development of GNU GRUB
Cc: Matthew Garrett, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Ian Campbell
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 'φ-coder/phcoder' Serbinenko"
<phcoder@gmail.com> 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
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:24 ` Vladimir 'φ-coder/phcoder' Serbinenko
(?)
(?)
@ 2013-10-22 16:36 ` Maliszewski, Richard L
2013-10-22 16:51 ` Daniel Kiper
2013-10-22 16:51 ` Daniel Kiper
-1 siblings, 2 replies; 238+ messages in thread
From: Maliszewski, Richard L @ 2013-10-22 16:36 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko,
The development of GNU GRUB
Cc: Daniel Kiper, Woodhouse, David, Matthew Garrett, keir@xen.org,
Ian Campbell, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com
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 'φ-coder/phcoder' Serbinenko"
<phcoder@gmail.com> 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
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:36 ` Maliszewski, Richard L
@ 2013-10-22 16:51 ` Daniel Kiper
2013-10-22 16:51 ` Daniel Kiper
1 sibling, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:51 UTC (permalink / raw)
To: Maliszewski, Richard L
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
The development of GNU GRUB,
Vladimir 'φ-coder/phcoder' Serbinenko,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Woodhouse, David
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:51 ` Daniel Kiper
0 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:51 UTC (permalink / raw)
To: Maliszewski, Richard L
Cc: Vladimir 'φ-coder/phcoder' Serbinenko,
The development of GNU GRUB, Woodhouse, David, Matthew Garrett,
keir@xen.org, Ian Campbell, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:51 ` Daniel Kiper
(?)
@ 2013-10-22 17:09 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 17:09 UTC (permalink / raw)
To: Daniel Kiper
Cc: The development of GNU GRUB, keir@xen.org, Ian Campbell,
Matthew Garrett, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com, Maliszewski, Richard L,
boris.ostrovsky@oracle.com, Woodhouse, David
[-- Attachment #1.1: Type: text/plain, Size: 870 bytes --]
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.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:51 ` Daniel Kiper
@ 2013-10-22 17:09 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 17:09 UTC (permalink / raw)
To: Daniel Kiper
Cc: The development of GNU GRUB, keir@xen.org, Ian Campbell,
Matthew Garrett, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com, Maliszewski, Richard L,
boris.ostrovsky@oracle.com, Woodhouse, David
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 17:09 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 17:09 UTC (permalink / raw)
To: Daniel Kiper
Cc: Maliszewski, Richard L, The development of GNU GRUB,
Woodhouse, David, Matthew Garrett, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:51 ` Daniel Kiper
` (2 preceding siblings ...)
(?)
@ 2013-10-22 17:21 ` Maliszewski, Richard L
-1 siblings, 0 replies; 238+ messages in thread
From: Maliszewski, Richard L @ 2013-10-22 17:21 UTC (permalink / raw)
To: Daniel Kiper
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
The development of GNU GRUB,
Vladimir 'φ-coder/phcoder' Serbinenko,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Woodhouse, David
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" <daniel.kiper@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:51 ` Daniel Kiper
@ 2013-10-22 17:21 ` Maliszewski, Richard L
-1 siblings, 0 replies; 238+ messages in thread
From: Maliszewski, Richard L @ 2013-10-22 17:21 UTC (permalink / raw)
To: Daniel Kiper
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
The development of GNU GRUB,
Vladimir 'φ-coder/phcoder' Serbinenko,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Woodhouse, David
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" <daniel.kiper@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 17:21 ` Maliszewski, Richard L
0 siblings, 0 replies; 238+ messages in thread
From: Maliszewski, Richard L @ 2013-10-22 17:21 UTC (permalink / raw)
To: Daniel Kiper
Cc: Vladimir 'φ-coder/phcoder' Serbinenko,
The development of GNU GRUB, Woodhouse, David, Matthew Garrett,
keir@xen.org, Ian Campbell, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com
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" <daniel.kiper@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 17:21 ` Maliszewski, Richard L
@ 2013-10-23 7:53 ` Daniel Kiper
-1 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-23 7:53 UTC (permalink / raw)
To: Maliszewski, Richard L
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
The development of GNU GRUB,
Vladimir 'φ-coder/phcoder' Serbinenko,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Woodhouse, David
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" <daniel.kiper@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 7:53 ` Daniel Kiper
0 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-23 7:53 UTC (permalink / raw)
To: Maliszewski, Richard L
Cc: Vladimir 'φ-coder/phcoder' Serbinenko,
The development of GNU GRUB, Woodhouse, David, Matthew Garrett,
keir@xen.org, Ian Campbell, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com
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" <daniel.kiper@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 17:21 ` Maliszewski, Richard L
(?)
(?)
@ 2013-10-23 7:53 ` Daniel Kiper
-1 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-23 7:53 UTC (permalink / raw)
To: Maliszewski, Richard L
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
The development of GNU GRUB,
Vladimir 'φ-coder/phcoder' Serbinenko,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Woodhouse, David
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" <daniel.kiper@oracle.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:36 ` Maliszewski, Richard L
2013-10-22 16:51 ` Daniel Kiper
@ 2013-10-22 16:51 ` Daniel Kiper
1 sibling, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-22 16:51 UTC (permalink / raw)
To: Maliszewski, Richard L
Cc: Matthew Garrett, keir@xen.org, Ian Campbell,
The development of GNU GRUB,
Vladimir 'φ-coder/phcoder' Serbinenko,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Woodhouse, David
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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:01 ` Daniel Kiper
` (3 preceding siblings ...)
(?)
@ 2013-10-22 16:24 ` Vladimir 'φ-coder/phcoder' Serbinenko
-1 siblings, 0 replies; 238+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-22 16:24 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Matthew Garrett, keir@xen.org, Woodhouse, David,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, ross.philipson@citrix.com, Maliszewski, Richard L,
boris.ostrovsky@oracle.com, Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 2051 bytes --]
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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:32 ` Matthew Garrett
(?)
(?)
@ 2013-10-22 15:42 ` Woodhouse, David
-1 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 15:42 UTC (permalink / raw)
To: Matthew Garrett
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, Peter Jones, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
[-- Attachment #1.1: Type: text/plain, Size: 932 bytes --]
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
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4370 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:25 ` Woodhouse, David
(?)
(?)
@ 2013-10-22 15:32 ` Matthew Garrett
-1 siblings, 0 replies; 238+ messages in thread
From: Matthew Garrett @ 2013-10-22 15:32 UTC (permalink / raw)
To: Woodhouse, David
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Jan Beulich, Peter Jones, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L
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 | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:25 ` Woodhouse, David
@ 2013-10-22 16:35 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:35 UTC (permalink / raw)
To: Woodhouse, David
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Jan Beulich, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
Maliszewski, Richard L
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
> David.Woodhouse@intel.com Intel Corporation
>
>
>
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-22 16:35 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:35 UTC (permalink / raw)
To: Woodhouse, David
Cc: Jan Beulich, Ian Campbell, ross.philipson@citrix.com,
stefano.stabellini@eu.citrix.com, grub-devel@gnu.org,
Maliszewski, Richard L, xen-devel@lists.xen.org,
boris.ostrovsky@oracle.com, Daniel Kiper, Peter Jones,
linux-kernel@vger.kernel.org, keir@xen.org
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
> David.Woodhouse@intel.com Intel Corporation
>
>
>
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:35 ` Konrad Rzeszutek Wilk
@ 2013-10-23 6:49 ` Michael Chang
-1 siblings, 0 replies; 238+ messages in thread
From: Michael Chang @ 2013-10-23 6:49 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: keir@xen.org, Woodhouse, David, stefano.stabellini@eu.citrix.com,
Daniel Kiper, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L, Ian Campbell
2013/10/23 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> 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
>> David.Woodhouse@intel.com Intel Corporation
>>
>>
>>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 6:49 ` Michael Chang
0 siblings, 0 replies; 238+ messages in thread
From: Michael Chang @ 2013-10-23 6:49 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Woodhouse, David, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Jan Beulich, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
Maliszewski, Richard L
2013/10/23 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> 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
>> David.Woodhouse@intel.com Intel Corporation
>>
>>
>>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 6:49 ` Michael Chang
@ 2013-10-23 6:51 ` Michael Chang
-1 siblings, 0 replies; 238+ messages in thread
From: Michael Chang @ 2013-10-23 6:51 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: keir@xen.org, Woodhouse, David, stefano.stabellini@eu.citrix.com,
Daniel Kiper, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L, Ian Campbell
2013/10/23 Michael Chang <mchang@suse.com>:
> 2013/10/23 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
>> 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
>>> David.Woodhouse@intel.com Intel Corporation
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 6:51 ` Michael Chang
0 siblings, 0 replies; 238+ messages in thread
From: Michael Chang @ 2013-10-23 6:51 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Woodhouse, David, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Jan Beulich, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
Maliszewski, Richard L
2013/10/23 Michael Chang <mchang@suse.com>:
> 2013/10/23 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
>> 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
>>> David.Woodhouse@intel.com Intel Corporation
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-23 6:49 ` Michael Chang
(?)
(?)
@ 2013-10-23 6:51 ` Michael Chang
-1 siblings, 0 replies; 238+ messages in thread
From: Michael Chang @ 2013-10-23 6:51 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: keir@xen.org, Woodhouse, David, stefano.stabellini@eu.citrix.com,
Daniel Kiper, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L, Ian Campbell
2013/10/23 Michael Chang <mchang@suse.com>:
> 2013/10/23 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
>> 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
>>> David.Woodhouse@intel.com Intel Corporation
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 16:35 ` Konrad Rzeszutek Wilk
(?)
(?)
@ 2013-10-23 6:49 ` Michael Chang
-1 siblings, 0 replies; 238+ messages in thread
From: Michael Chang @ 2013-10-23 6:49 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: keir@xen.org, Woodhouse, David, stefano.stabellini@eu.citrix.com,
Daniel Kiper, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org, Jan Beulich, ross.philipson@citrix.com,
boris.ostrovsky@oracle.com, Maliszewski, Richard L, Ian Campbell
2013/10/23 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> 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
>> David.Woodhouse@intel.com Intel Corporation
>>
>>
>>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 15:25 ` Woodhouse, David
` (3 preceding siblings ...)
(?)
@ 2013-10-22 16:35 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 238+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-10-22 16:35 UTC (permalink / raw)
To: Woodhouse, David
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Peter Jones, Jan Beulich, boris.ostrovsky@oracle.com,
xen-devel@lists.xen.org, Maliszewski, Richard L
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
> David.Woodhouse@intel.com Intel Corporation
>
>
>
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 14:43 ` Konrad Rzeszutek Wilk
(?)
(?)
@ 2013-10-22 15:25 ` Woodhouse, David
-1 siblings, 0 replies; 238+ messages in thread
From: Woodhouse, David @ 2013-10-22 15:25 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel@gnu.org, keir@xen.org, Ian Campbell,
stefano.stabellini@eu.citrix.com, Daniel Kiper,
linux-kernel@vger.kernel.org, ross.philipson@citrix.com,
Peter Jones, Jan Beulich, boris.ostrovsky@oracle.com,
xen-devel@lists.xen.org, Maliszewski, Richard L
[-- Attachment #1.1: Type: text/plain, Size: 1485 bytes --]
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
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4370 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:42 ` Konrad Rzeszutek Wilk
` (4 preceding siblings ...)
(?)
@ 2013-10-23 6:56 ` Daniel Kiper
-1 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-23 6:56 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
linux-kernel, ross.philipson, Peter Jones, Jan Beulich,
boris.ostrovsky, xen-devel, richard.l.maliszewski, Ian Campbell
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 <ian.campbell@citrix.com> wrote:
> > > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> > >> >>> On 22.10.13 at 11:26, Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread* Re: EFI and multiboot2 devlopment work for Xen
2013-10-22 13:42 ` Konrad Rzeszutek Wilk
@ 2013-10-23 6:56 ` Daniel Kiper
-1 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-23 6:56 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: grub-devel, keir, david.woodhouse, stefano.stabellini,
linux-kernel, ross.philipson, Jan Beulich, boris.ostrovsky,
xen-devel, richard.l.maliszewski, Ian Campbell
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 <ian.campbell@citrix.com> wrote:
> > > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> > >> >>> On 22.10.13 at 11:26, Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread
* Re: EFI and multiboot2 devlopment work for Xen
@ 2013-10-23 6:56 ` Daniel Kiper
0 siblings, 0 replies; 238+ messages in thread
From: Daniel Kiper @ 2013-10-23 6:56 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jan Beulich, Ian Campbell, ross.philipson, stefano.stabellini,
grub-devel, david.woodhouse, richard.l.maliszewski, xen-devel,
boris.ostrovsky, Peter Jones, linux-kernel, keir
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 <ian.campbell@citrix.com> wrote:
> > > On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
> > >> >>> On 22.10.13 at 11:26, Ian Campbell <ian.campbell@citrix.com> 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
^ permalink raw reply [flat|nested] 238+ messages in thread