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

On Wed, Apr 6, 2016 at 3:40 AM, Luis R. Rodriguez <mcgrof@...nel.org> wrote:
> A huge summary of the discussion over EFI boot option for HVMLite is now on a
> wiki [2], below I'll just provide the outline of the discussion. Consider this a
> request for more public review, feel free to take any of the items below and
> elaborate on it as you see fit.
[snip]
>   * Issues with boot x86 boot entries
>     * Small x86 zero page stubs
[snip]
>   * Points against using EFI
>     * Nulling the claimed boot loader effect

I'm a bit confused about this. You list exactly two arguments against
the proposed stub in the "con" section:
1. Bootloaders may not be able to use the extra entry point
2. It's an extra entry point

And then later, in another section, you actually list the reason #1 is
irrelevant: bootloaders don't matter because the stub is there to boot
from the Xen hypervisor.

So the only actual argument you have against the proposed PVH stub in
the linked document is that it's an extra entry point.

>   * Why use EFI for HVMlite
>     * EFI calling conventions are standardized
>     * EFI entry generalizes what new HVMLite entry proposes
>     * Further semantics may be needed
>     * Match Xen ARM's clean solution
>     * You don't need full EFI emulation
>       * Minimal EFI stubs for guests
>         * GetMemoryMap()
>         * ExitBootServices()
>       * EFI stubs which may be needed for guests
>         * Exit()
>         * Variable operation functions
>       * EFI stubs not needed for guests
>         * GetTime()/SetTime()
>         * SetVirtualAddressMap()
>         * ResetSystem()
>       * dom0 EFI
>       * domU EFI emulation possibilities
>         * Xen implements its own EFI environment for guests
>         * Xen uses Tianocore / OVMF

So rather than make a new entry point which does just the minimal
amount of work to run on a software interface (Xen), you want to take
an interface designed for hardware (EFI) and put in hacks so that it
knows that sometimes some EFI services are not available?  That sounds
like it's going to make the EFI path just as unmanageable as the
current PV path.

Using the EFI entry point would certainly make sense if it was
actually simpler than the proposed extra entry point.  But it sounds
like it's going to be more complicated, not only for Xen, but also for
Linux.

 -George