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:50:25 +0200
From:	Juergen Gross <jgross@...e.com>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	George Dunlap <george.dunlap@...rix.com>
Cc:	Matt Fleming <matt@...eblueprint.co.uk>, jeffm@...e.com,
	Michael Chang <MChang@...e.com>,
	Linux Kernel Mailing List <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>,
	the arch/x86 maintainers <x86@...nel.org>,
	Takashi Iwai <tiwai@...e.de>,
	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 <stefano.stabellini@...citrix.com>,
	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>,
	Julien Grall <julien.grall@....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>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 14/04/16 21:44, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote:
>> On 13/04/16 20:52, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
>>>> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
>>>>> So more to it, if the EFI entry already provides a way into Linux
>>>>> in a more streamlined fashion bringing it closer to the bare metal
>>>>> boot entry, why *would* we add another boot entry to x86, even if
>>>>> its small and self contained ?
>>>>
>>>> We would avoid using EFI if:
>>>
>>> And this is what I was looking for, thanks!
>>>
>>>> * Being called both on real hardware and under Xen would make the EFI
>>>> entry point more complicated
>>>
>>> That's on the EFI Linux maintainer to assess. And he seems willing to
>>> consider this.
>>>
>>>> * Adding the necessary EFI support into Xen would be a significant
>>>> chunk of extra work
>>>
>>> This seems to be a good sticking point, but Andi noted another aspect
>>> of this or redundancy as well.
>>>
>>>> * Requiring PVH mode to implement EFI would make it more difficult for
>>>> other kernes (NetBSD, FreeBSD) to act as dom0s.
>>>
>>> What if this is an option only then ?
>>>
>>>>
>>>> * Requiring PVH mode to use EFI would make it more difficult to
>>>> support unikernel-style workloads for domUs.
>>>
>>> What if this is an option only then ?
>>
>> So first of all, you asked why anyone would oppose EFI, and this is part
>> of the answer to that.
>>
>> Secondly, you mean "What if this is the only thing the Linux maintainers
>> will accept?"  And you already know the answer to that.
> 
> No, I meant to ask, would it be possible to make booting HVMLite using EFI
> be optional ? That way if you already support EFI that can be used on
> your entires with some small modifications.

So you suggest to add two HVMlite modes regarding boot interface
instead of one?

I still have the impression you are suggesting by using the same entry
everything is solved in the OS. You still need the support of HVMlite
especially in the early boot path to make sure the OS won't try to use
the complete EFI standard.

> 
>> How much of a burden it would be on the rest of the open-source
>> ecosystem (Xen, *BSDs, &c) is a combination of some as-yet unknown facts
>> (i.e., what a minimal Xen/Linux EFI interface would look like) and a
>> matter of judgement (i.e., given the same interface, reasonable people
>> may come to different conclusions about whether the interface is an
>> undue burden to impose on others or not).
>>
>> But I would hope that the Linux maintainers would at least consider the
>> broader community when weighing their decisions, and not take advantage
>> of their position of dominance to simply ignore the effect of their
>> choices on everybody else.
> 
> This has nothing to do with dominance or anything nefarious, I'm asking
> simply for a full engineering evaluation of all possibilities, with
> the long term in mind. Not for now, but for hardware assumptions which
> are sensible 5 years from now.

No, they are not.

Given how long the EFI standard is available now and how buggy many
vendor's implementations are I don't expect all computers sold in 5
years will have a usable EFI. This will be true especially for
consumer devices where no EFI is available today.


Juergen