linux-kernel - Re: [Xen-devel] [PATCH v1 04/12] 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: <56A8DCFD.6040603@oracle.com>
Date:	Wed, 27 Jan 2016 10:06:37 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"Luis R. Rodriguez" <mcgrof@...il.com>
Cc:	Juergen Gross <jgross@...e.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	"H. Peter Anvin" <hpa@...or.com>, xen-devel@...ts.xenproject.org,
	Borislav Petkov <bp@...e.de>,
	Roger Pau Monné <roger.pau@...rix.com>
Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/27/2016 09:50 AM, David Vrabel wrote:
> On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
>> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
>>> On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" <mcgrof@...e.com> wrote:
>>>> On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez <mcgrof@...e.com>
>>> wrote:
>>>>> You go:
>>>>>
>>>>> hvmlite_start_xen() -->
>>>>>          HVM stub
>>>>>          startup_64() | (startup_32()
>>>> Hrm, does HVMlite work well with load_ucode_bsp(), note the patches to
>>>> rebrand pv_enabled() to pv_legacy() or whatever, this PV type will not
>>>> be legacy or crap / old, so we'd need a way to catch it if we should
>>>> not use that code for this PV type. This begs the question, are you
>>>> also sure other callers in startup_32() or startup_64() might be OK as
>>>> well where previously guarded with pv_enabled() ?
>>> Actually this call can't be used, and if early code used it prior to
>>> setup_arch() it'd be a bug as its only properly set until later. Vetting
>>> for correctness of all code call is still required though and perhaps we do
>>> need something to catch now this PV type on early code such as this one if
>>> we don't want it. From what I've gathered before on other bsp ucode we
>>> don't want ucode loaded for PV guest types through these mechanisms.
>> It may help to not think of PVH/hvmlite as PV. It really is HVM with a lot
>> of emulated devices removed.
>>
>> How does early microcode work on EFI? Does the EFI stub code have an early
>> microcode loading code ?
> Surely the interesting comparison here is how is (early) microcode
> loading disabled in KVM guests?  We should use the same mechanism for
> HVMlite guests.


Why would we ever want to have a guest load microcode during boot? I can 
see how a (privileged) guest may want to load microcode from a shell 
(via microcode driver).

-boris