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]

Date:	Fri, 15 Apr 2016 07:55:39 -0700
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Julien Grall <julien.grall@....com>
Cc:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Juergen Gross <jgross@...e.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	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 <xen-devel@...ts.xenproject.org>,
	Jeffrey Cheung <JCheung@...e.com>,
	Stefano Stabellini <sstabellini@...nel.org>,
	joeyli <jlee@...e.com>, Borislav Petkov <bp@...en8.de>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Charles Arndol <carnold@...e.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Andy Lutomirski <luto@...capital.net>,
	David Vrabel <david.vrabel@...rix.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Roger Pau Monné <roger.pau@...rix.com>,
	Josh Triplett <josh@...htriplett.org>,
	Kees Cook <keescook@...omium.org>,
	Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 15, 2016 at 3:06 AM, Julien Grall <julien.grall@....com> wrote:
> On 14/04/16 21:56, Luis R. Rodriguez wrote:
>> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
>>> But to make that work you have to emulate EFI firmware in the
>>> hypervisor. Is that work you are signing up for?
>>
>> I'll do what is needed, as I have done before. If EFI is on the long
>> term roadmap for ARM perhaps there are a few birds to knock with one
>> stone here. If there is also interest to support other OSes through
>> EFI standard means this also should help make that easier.
>
> We already have a working solution for EFI on ARM which does not require to
> emulate the firmware in the hypervisor.

I get that.

> On ARM, the EFI stub is communicating with the kernel using device-tree [1].
> Once the EFI stub has ended, the native path (i.e non-UEFI) will be executed
> normally and it won't be possible to use BootServices anymore.
>
> For the guest, we provide a full support of EFI using OVMF.

I get that as well, is this the long term solution ? That still
requires OVMF, will relying on OVMF always be what is used on Xen ARM
? Was it too much of a burden to require OVMF? Is the upstream OVMF
code pulled by Xen at build time on ARM, or just wget a binary ?

> For DOM0, Xen
> will craft the UEFI system table and the UEFI memory map. The locations of
> those tables will be passed to DOM0 using a tiny device-tree [1] and the
> kernel will boot using the native path. The runtime services for DOM0 will
> be provided via hypercall.

Thanks this helps!

> The DOM0 approach has been discussed for a long time (see [3]) and I believe
> this is better than emulating UEFI firmware in Xen. We want to keep Xen on
> ARM tiny. Adding any sort of emulation will increase the attack surface and
> require more maintenance from our side.

OK thanks, would re-using OVMF (note, DT perhaps may not be ideal for
x86 for the rest though) be a reasonable solution on x86 as an option
then?

  Luis