linux-kernel - Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

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]

Message-ID: <20160203235908.GT20964@wotan.suse.de>
Date:	Thu, 4 Feb 2016 00:59:08 +0100
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Andrew Cooper <andrew.cooper3@...rix.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	pmonclus@...mgrid.com, GLin@...e.coma, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	David Vrabel <david.vrabel@...rix.com>, hpa@...or.com,
	xen-devel@...ts.xenproject.org, bp@...e.de, bblanco@...mgrid.com,
	roger.pau@...rix.com
Subject: Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On Wed, Feb 03, 2016 at 08:52:50PM +0000, Andrew Cooper wrote:
> On 03/02/16 18:55, Luis R. Rodriguez wrote:
> > We add new hypervisor type to close the semantic gap for hypervisor types, and
> > much like subarch enable also a subarch_data to let you pass and use your
> > hvmlite_start_info. This would not only help with the semantics but also help
> > avoid yet-another-entry point and force us to provide a well define structure
> > for considering code that should not run by pegging it as required or supported
> > for different early x86 code stubs.
> 
> Was I unclear last time?  Xen *will not* be introducing Linux-specifics
> into the HVMLite starting ABI.

This does not have to be "Linux specifics" but rather a light way to enable
a hypervisor to clue in *any* OS of its hypervisor type, guest type, and
custom hypervisor data that can be used to populate needed OS specifics
about the guest. Perhaps Xen's own loader mechanism could be extended just
slightly to become *that* standard, its just right now it doesn't seem to
enable for generalizing this in a very useful way for OSes. Its all
custom stubs.

> Your perceived problem with multiple entry points is not a problem with
> multiple entry points; It is a problem with multiple different paths
> performing the same initialisation.

Its actually more of an issue with the lack of strong general semantics
available for different hypervisors and guest types and requirements for x86's
init path. What you end up with as collateral is multiple entry points, and
these can be sloppy and as you note can perform the same initialisation.
Another issue is the inability to proactively ensure new x86 init code
addresses different x86 requirements (cr4 shadow regression and Kasan still
being broken on Xen are two examples) and it just so happens that the lack of
semantics for the different guest types required to be evaluated is one issue
for x86.

We can do better.

> The Linux entry for PV guests is indeed completely horrible.  I am not
> trying to defend it in the slightest.
> 
> However, the HVMLite entry which is a very short stub that sets up a
> zeropage and hands off to the native start routine is fine.

Its alright, and a huge stepping stone towards good architecture. We
however can do better.

> There is still just routine performing native x86 startup.
> 
> If you still desperately want to avoid multiple entry points, then just
> insist on using grub for the VM.  I expect that that is how most people
> will end up using HVMLite VMs anyway.

Are you saying Grub can do some of this heavy lifting that I am trying
to avoid? If so that'd be great news.

  Luis