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: <570F65F7.5050108@citrix.com>
Date:	Thu, 14 Apr 2016 10:42:15 +0100
From:	George Dunlap <george.dunlap@...rix.com>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>
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>,
	Juergen Gross <jgross@...e.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Julien Grall <julien.grall@...aro.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>,
	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 13/04/16 19:54, Luis R. Rodriguez wrote:
> On Wed, Apr 13, 2016 at 11:05:00AM +0100, George Dunlap wrote:
>> On Tue, Apr 12, 2016 at 11:12 PM, Luis R. Rodriguez <mcgrof@...nel.org> wrote:
>>> 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.
>>
>> I'm not sure how this is relevant to anything.
> 
> You brought DT as a reason why ARM was able to use the native point.
> I'm clarifying DT has nothing to do as a restriction on x86.

No, DT isn't the reason Xen is able to use the native entry point on
ARM.  The reason is, to quote myself: "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 that's three things:
1. DT is available to be used
2. DT is expected as the main thing that entry point accepts
3. There are no assumptions about what hardware is or is not present in
the system
4. Everything that needs to be communicated about what is or is not
present can be passed in DT.

Are #2, #3, and #4 true on x86?  If not then #1 is irrelevant.

[snip from another thread]

> One. CE4100.
>
> arch/x86/platform/ce4100/falconfalls.dt

You CC'd me on some patches related to that.  I don't know anything
about the code, but it looked like CE4100 is a subarch, and in response
to that thread Ingo specifically asked you to add a comment saying
basically "Don't add any more subarches".

And not only that, but the ugly, nasty legacy PV boot path we're trying
to get rid of IS ALSO A SUBARCH.  So instead of a quick stub with an
extra EFI flag, you're proposing we consider add yet another Xen PV subarch?

>> What we're talking about is how to get from Xen to a point in the
>> Linux kernel where everything can Just Work.  The proposed feature is
>> a mini trampoline that (as I understand it):
>> 1. Tells Xen where to jump to (via ELF note)
>> 2. Sets up some basic modes and pagetables and then jumps to the zero
>> page so Linux can just carry on.
> 
> Right, and the my goal is to see to it we do enough homework to
> ensure we reviewed all possibilities to share as much code as possible
> already and looked at all options before saying we certainly need yet
> another entry point. I am not convinced yet this has been done.

I think we have different ideas about what an appropriate amount of
homework is. :-)  Everything you've put forward has been given
consideration and judged unlikely to be promising; and your suggestions
for further possibilities (like this one) keep getting more and more
obviously unsuitable.  We shouldn't be required to actually post code
for every single other option just to prove how ugly they are,
particularly when there's nothing particularly wrong with the code we have.

 -George