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]

Message-ID: <20160406150240.GO2701@codeblueprint.co.uk>
Date:	Wed, 6 Apr 2016 16:02:40 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	George Dunlap <george.dunlap@...rix.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	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>,
	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, 06 Apr, at 12:07:36PM, George Dunlap wrote:
> 
> 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.

Requiring code in the new entry point to manipulate control registers
and do the switch to long-mode does not seem like a minimal amount of
code to me,

  http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00134.html

What's likely to happen in the future is that startup_(32|64) will be
entered with different settings depending on whether coming from
HVMlite or bare metal, due to the natural tendency for these kinds of
code paths to diverge.

Sometimes EFI runtime services are not available on bare metal
hardware too, for example, when booting 32-bit kernels on 64-bit EFI
or 64-bit kernels on 32-bit EFI without CONFIG_EFI_MIXED. Or when
booting with the "noefi" kernel command line parameter. That's how
things work today when booting Xen, we disable the runtime services.

EFI boot services are a different story however, and the EFI boot stub
would need to be changed to handle that. Though honestly, it would
make more sense to provide EFI services stubs in the kernel image
itself that are implemented using hypercalls, and assuming you can run
hypercalls that early in boot.

One place that struck me as suitable for this "hypercall in an EFI
service stub" approach is the trouble with doing ACPI reboot as
documented here,

  http://lists.xen.org/archives/html/xen-devel/2016-02/msg01609.html

Performing the reset hypercall from within HVMlite's custom EfiReset()
service would avoid having to touch ACPICA at all, and would be
indistinguishable from bare metal.

> 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.

Until someone sits down and writes the code I think we're going to be
arguing back and forth over this particular point.