linux-kernel - Re: EFI and multiboot2 devlopment work for Xen

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131023065640.GP3626@debian70-amd64.local.net-space.pl>
Date:	Wed, 23 Oct 2013 08:56:40 +0200
From:	Daniel Kiper <daniel.kiper@...cle.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	Jan Beulich <JBeulich@...e.com>,
	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, 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.

[...]

> 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
--
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/