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:	Thu, 14 Apr 2016 23:12:01 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	George Dunlap <george.dunlap@...rix.com>,
	Matt Fleming <matt@...eblueprint.co.uk>, jeffm@...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>,
	Charles Arndol <carnold@...e.com>,
	Julien Grall <julien.grall@....com>,
	Stefano Stabellini <stefano.stabellini@...citrix.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>,
	Michael Chang <MChang@...e.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 Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote:
> > 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.
> 
> There are two different things in my mind about this conversation:
> 
>  1). semantics of low-level code wrapped around pvops. On baremetal
>    it is easy - just look at Intel and AMD SDM.
>    And this is exactly what running in HVM or HVMLite mode will do -
>    all those low-level operations will have the same exact semantic
>    as baremetal.

Today Linux is KVM stupid for early boot code. I've pointed this out
before, but again, there has been no reason found to need this. Perhaps
for HVMLite we won't need this...

>    There is no hope for the pv_ops to fix that.

Actually I beg to differ. See my patches and ongoing work.

>    And I am pretty sure the HVMLite in 5 years will have no
>    trouble in this as it will be running in VMX mode (HVM).

HVMLite may still use PV drivers for some things, its not super
obvious to me that low level semantics will not be needed yet.

>  2). Boot entry.
> 
>    The semantics on Linux are well known - they are documented in
>    Documentation/x86/boot.txt.
> 
>    HVMLite Linux guests have to somehow provide that.
> 
>    And how it is done seems to be tied around:
> 
>    a) Use existing boot paths - which means making some
>       extra stub code to call in those existing boot paths
>       (for example Xen could bundle with an GRUB2-alike
>        code to be run when booting Linux using that boot-path).
> 
>       Or EFI (for a ton more code). Granted not all OSes
>       support those, so not very OS agnostic.

What other OSes do is something to consider but if they don't
do it because they are slacking in one domain should by no means
be a reason to not evaluate the long term possible gains.
Specially if we have reasons to believe more architectures will
consider it and standardize on it.

It'd be silly not to take this a bit more seriously.

>        Hard part - if the bootparams change then have to
>       rev up the code in there. May be out of sync
>       with Linux bootparams.

If we are going to ultimately standardize on EFI boot for new
hardware it'd be rather silly to extend the boot params further.

>    b) Add another simpler boot entry point which has to copy
>      "some" strings from its format in bootparams.
> 
> 
>    So this part of the discussion does not fall in the
>    hardware assumptions. Intel SDM or AMD mention nothing about
>    boot loaders or how to boot an OS - that is all in realms
>    of how software talks to software.

Right -- so one question to ask here is what other uses are there
for this outside of say HVMLite. You mentioned Multiboot so far.

>  3). And there is the discussion on man-power to make this
>    happen.

Sure.

>  4). Lastly which one is simpler and involves less code so
>     that there is a less chance of bitrot.

Indeed.

You also forgot the tie-in between dead-code and semantics but
that clearly is not on your mind. But I'd say this is a good
summary.

  Luis