| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20131022144309.GA18547@phenom.dumpdata.com>
Date: Tue, 22 Oct 2013 10:43:09 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Jan Beulich <JBeulich@...e.com>
Cc: Ian Campbell <ian.campbell@...rix.com>, ross.philipson@...rix.com,
stefano.stabellini@...citrix.com, grub-devel@....org,
david.woodhouse@...el.com, richard.l.maliszewski@...el.com,
xen-devel@...ts.xen.org, boris.ostrovsky@...cle.com,
Daniel Kiper <daniel.kiper@...cle.com>,
Peter Jones <pjones@...hat.com>, linux-kernel@...r.kernel.org,
keir@....org
Subject: Re: EFI and multiboot2 devlopment work for Xen
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@...rix.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@...rix.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists