linux-kernel - Is: Wrap-up Was: 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: <20131030111924.GE3425@debian70-amd64.local.net-space.pl>
Date:	Wed, 30 Oct 2013 12:19:24 +0100
From:	Daniel Kiper <daniel.kiper@...cle.com>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	"Vladimir 'φ-coder/phcoder' Serbinenko" 
	<phcoder@...il.com>, ian.campbell@...rix.com,
	ross.philipson@...rix.com, stefano.stabellini@...citrix.com,
	The development of GNU GRUB <grub-devel@....org>,
	david.woodhouse@...el.com, richard.l.maliszewski@...el.com,
	xen-devel@...ts.xen.org, boris.ostrovsky@...cle.com,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	seth.goldberg@...cle.com, pjones@...hat.com,
	linux-kernel@...r.kernel.org, keir@....org, mjg59@...f.ucam.org,
	shidokht.yadegari@...cle.com, neal.pollack@...cle.com,
	arvidjaar@...il.com, mchang@...e.com, mchang.novell@...il.com
Subject: Is: Wrap-up Was: Re: EFI and multiboot2 devlopment work for Xen

Hi,

Here is a short summary of our discussion. It looks
that we have two choices right now:
  - chainloader,
  - multiboot2 protocol.

chainloader solution could be implemented quite easily. Some code should be
added for command line parsing. However, all arguments for Xen itself and
modules must be passed as single line with special separators (e.g. ///;
correct me if I am wrong). This thing makes that solution not very convenient,
especially if you would like to edit boot command line directly from boot
loader. chainloader will support PE images directly. However, it could load
only PE image with Xen. Xen image should load all other parts but they could
be loaded from FAT filesystem only. This works because it was implemented
in original Xen EFI implementation. Support for secure boot and shim loader
could be added. It was implemented by SUSE guys and is available in latest SUSE
distros. However, it is not merged into GRUB2 upstream (like linuxefi). I do
not know what are GRUB2 and SUSE guys plans to upstream this solution.

multiboot2 protocol requires some more changes. However, about 80% of code
is ready. In this case Xen and modules are loaded by GRUB2 itself. It means
that all images could be placed on any filesystem recognized by GRUB2. Options
for Xen and modules are passed separately which simplifies command line editing
in boot loader and parsing. multiboot2 protocol is very flexible and could be
easily extended in the future if a need arises. Support for secure boot and
shim loader could be added. However, it was not implemented yet. Probably
linuxefi module could be used as a reference or even as a base for development.
However, I do not know are there plans to support such solution by GRUB2
community. Currently, support for native PE images signatures and GPG signatures
is under development for GRUB2 upstream.

Personally I prefer multiboot2 protocol solution because it is much
more flexible and easier for use (even if it is more difficult to
implement).

There is still open question that ExitBootServices() should be called by GRUB2
loader or by loaded image itself on EFI platform. UEFI spec 2.4 states in many
places that it is "OS loader" or "Operating System" responsibility. However,
I think that "OS loader" should be understood as a integral piece of "Operating
System" responsible for its load into memory without usage of any additional
loader like GRUB2. So in this situation it looks that "Operating System" should
call ExitBootServices() on EFI platforms instead of GRUB2. Even if we agree that
this assumption is wrong I think that it is better to give an "Operating System"
a choice to use boot services. This way OS could decide which source of information
is more convenient in its case, do extra things with EFI platform support (e.g.
get memory map directly from EFI) and call ExitBootServices() in relevant time.

There is also third solution for issues with ExitBootServices(). In case
of multiboot2 protocol OS could request that EFI should be left as is.
Solution was proposed by Vladimir and I think that it makes sense. However,
this does not solve problem with ExitBootServices() in case of other
boot loaders/protocols. So we should take a decision accordingly to above
considerations in regards to linux, chainloader and similar stuff.

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