linux-kernel - Re: [Xen-devel] HVMLite / PVHv2

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: <CAFLBxZbeL9pLn7U8V+f49AJEFN_chRW-AmriyR7trwWwyF3SpA@mail.gmail.com>
Date:	Wed, 13 Apr 2016 12:12:28 +0100
From:	George Dunlap <george.dunlap@...rix.com>
To:	Matt Fleming <matt@...eblueprint.co.uk>
CC:	Roger Pau Monné <roger.pau@...rix.com>,
	Michael Chang <MChang@...e.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jim Fehlig <jfehlig@...e.com>, Jan Beulich <JBeulich@...e.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	X86 ML <x86@...nel.org>,
	Vojtěch Pavlík <vojtech@...e.cz>,
	Gary Lin <GLin@...e.com>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
	Jeffrey Cheung <JCheung@...e.com>,
	"Charles Arndol" <carnold@...e.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	joeyli <jlee@...e.com>, Borislav Petkov <bp@...en8.de>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Juergen Gross <jgross@...e.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Julien Grall <julien.grall@....com>,
	Andy Lutomirski <luto@...capital.net>,
	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	David Vrabel <david.vrabel@...rix.com>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 13, 2016 at 11:15 AM, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> For 1. we'd basically be using the PE/COFF file format with the EFI
> ABI as an OS agnostic boot protocol, but not as a full firmware
> runtime environment.

But we still have the issue here that the now the EFI entry point in
Linux has to figure out, "Am I running in a full firmware runtime
environment, or am I running under Xen?", and then change behavior
appropriately.  Then we get back to Juergen's comment:  "[The EFI
proposal] should be evaluated how much of the early EFI boot path
would be common to the HVMlite one. What would be gained by using the
same entry but having two different boot paths after it?"

> 2. is also interesting, though I think less so than 1. I agree that
> making OVMF work as a PVH guest is probably the right way to go, even
> for Dom0, not least because you'd have a much cleaner/less buggy
> implementation than what we see in the real world ;)

So rather than just add an extra entry point and a Xen-to-zero-page
stub, you're going to ask Xen on dom0 to import a full OVMF binary?
Or have the bootloader entries include xen, linux, the initrd, *and*
ovmf?  That seems a bit extreme. :-)

Keep in mind also that PVH needs to support not only the traditional
VM use-case (e.g., booting a full distro), but the small service VM
usecase (a la unikernels).  Booting a traditional distro as a domU via
OVMF -> EFI Linux makes sense; it reduces the distro's test burden,
and the OVMF doesn't add a lot to the memory or boot time compared to
the size and boot time of a full distro.  But booting tiny service
VMs, sometimes with not even any disk of their own (other than a
ramdisk), the extra cost of including OVMF in the guest address space
can be a non-negligible addition to the memory requirements and
boot-up time.

One of the reasons Xen on ARM prioritized getting EFI working for
domUs was that a representative from a certain distro vendor made it
absolutely clear that *their* distro would *only* support booting via
EFI on ARM.  But you can still, as I understand it, use uBoot with DT
to boot a lightweight domU if you want.

 -George