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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Apr 2016 00:12:25 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:	George Dunlap <george.dunlap@...rix.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Michael Chang <MChang@...e.com>,
	Julien Grall <julien.grall@....com>,
	Jan Beulich <JBeulich@...e.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	the arch/x86 maintainers <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>,
	Charles Arndol <carnold@...e.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Jim Fehlig <jfehlig@...e.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>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	David Vrabel <david.vrabel@...rix.com>,
	Roger Pau Monné <roger.pau@...rix.com>,
	Takashi Iwai <tiwai@...e.de>, jeffm@...e.com,
	torvalds@...ux-foundation.org,
	Julien Grall <julien.grall@...aro.org>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote:
> On Fri, Apr 08, 2016 at 03:16:14PM +0100, George Dunlap wrote:
> > On 07/04/16 19:51, Luis R. Rodriguez wrote:
> > > While Andrew's position is right in that perhaps only Xen tools have to deal
> > > with the HVMLite specific entry, it would also still mean diverging from ARM's
> > > own EFI entry only position, which I'd like to clarify that ARM has no custom
> > > Xen entry, we should strive to match that. Anything far from that to me really
> > > deserves an explanation, specially if we are going to argue that HVMLite is
> > > the best that x86 Xen can do.
> > > 
> > > Ultimately unifying entry approaches for Xen in a streamlined fashion seems
> > > like a sensible thing to strive for. Anything we push in the other direction,
> > > as small as it can be, should deserve at least a 'hey, wait a minute'...
> > 
> > Quick factual correction here.
> > 
> > "Since ARM guests only use the EFI entry point, x86 guests should also
> > only use the EFI entry point" is certainly a reasonable argument to make.
> > 
> > However, dom0 on ARM does not use the EFI entry point.  When starting
> > dom0, Xen uses the native entry point (the one that UBoot uses) and
> > hands dom0 a device-tree node.  The reason this is possible on ARM is
> > that there are no assumptions made about what hardware is or is not
> > present on the system -- everything that needs to be communicated about
> > what is or is not present can be passed in DT.
> > 
> > So it is incorrect to say that ARM has an "EFI entry only" position.
> > 
> > (On ACPI systems, it does apparently generate some UEFI informational
> > tables, which it passes to the dom0 kernel via DT; and the kernel
> > unpacks and puts in the right place.  Normal Xen ARM guests can use EFI,
> > but that's because we start OVMF in the guest context to provide the EFI
> > services.  These may be where the idea that ARM guests use only the UEFI
> > entry point came from.)
> > 
> > Obviously it would be nice if we could use the native entry point on x86
> > as well, but there's decades of legacy hardware and backwards
> > compatibility to deal with there.
> 
> OK thanks for the clarification -- still no custom entries for Xen!
> We should strive for that, at the very least.
> 
> You do have a point about the legacy stuff. There are two options there:
> 
>   * Fold legacy support under HVMLite -- which seems to be what we
>     currently want to do (we should evaluate the implications and
>     requirements here for that); or
> 
>   * Leave legacy stuff on the old PV path; this may be something to
>     bring to the table if we had in place a proactive solution to
>     avoid further fallout from the architecture of the huge differences
>     on the entries. The work I'm doing should help with that. (We should
>     also evaluate the implications and requirements here for that as
>     well).

Also, x86 does have a history of short DT use. Just pointing that its there as
an option as well. I'll Cc you on some thread about that.

  Luis