linux-kernel - Re: 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: <5270EF9F.4040906@gmail.com>
Date:	Wed, 30 Oct 2013 12:38:07 +0100
From:	Vladimir 'φ-coder/phcoder' Serbinenko 
	<phcoder@...il.com>
To:	Daniel Kiper <daniel.kiper@...cle.com>
CC:	Jan Beulich <JBeulich@...e.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: Re: Is: Wrap-up Was: Re: EFI and multiboot2 devlopment work for Xen

On 30.10.2013 12:19, Daniel Kiper wrote:
> Hi,
> multiboot2 protocol requires some more changes. However, about 80% of code
> is ready. In this case Xen and modules are loaded by GRUB2 itself. It means
> that all images could be placed on any filesystem recognized by GRUB2. Options
> for Xen and modules are passed separately which simplifies command line editing
> in boot loader and parsing. multiboot2 protocol is very flexible and could be
> easily extended in the future if a need arises. Support for secure boot and
> shim loader could be added. However, it was not implemented yet. Probably
> linuxefi module could be used as a reference or even as a base for development.
> However, I do not know are there plans to support such solution by GRUB2
> community. Currently, support for native PE images signatures and GPG signatures
> is under development for GRUB2 upstream.
> 
GPG signatures are supported already. My plan is as follows:
- Implement PE signatures upstream.
- Uplift as much of secureboot to upstream as policy permits. I would
like to be in partnership over this with some distro people so that they
can carry remaining part (unless FSF allows secureboot per policy)
> There is still open question that ExitBootServices() should be called by GRUB2
> loader or by loaded image itself on EFI platform. UEFI spec 2.4 states in many
> places that it is "OS loader" or "Operating System" responsibility. However,
> I think that "OS loader" should be understood as a integral piece of "Operating
> System" responsible for its load into memory without usage of any additional
> loader like GRUB2.
"Operating system" isn't just kernel. Everything you get in base install
is "Operating system" including i.a. shell or bootloader.
However this is kind of decision that couldn't be taken based on spec
alone. The bugs in real-world EFI implementations play more role in
design solutions that EFI specification.
> There is also third solution for issues with ExitBootServices(). In case
> of multiboot2 protocol OS could request that EFI should be left as is.
> Solution was proposed by Vladimir and I think that it makes sense.
I will write the specification draft for it then but probably not today.
> However,
> this does not solve problem with ExitBootServices() in case of other
> boot loaders/protocols.
multiboot2 was designed in a way not to be limited to GRUB2. It can be
added to other bootloaders as well.
> So we should take a decision accordingly to above
> considerations in regards to linux, chainloader and similar stuff.
> 
> Daniel
> 



Download attachment "signature.asc" of type "application/pgp-signature" (292 bytes)