linux-kernel - Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt

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:	Mon, 8 Feb 2016 10:39:43 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@...capital.net>
Cc:	"Luis R. Rodriguez" <mcgrof@...e.com>,
	"Luis R. Rodriguez" <mcgrof@...nel.org>, cocci@...teme.lip6.fr,
	Juergen Gross <jgross@...e.com>, mcb30@...e.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Joerg Roedel <joro@...tes.org>,
	Robert Moore <robert.moore@...el.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Xen Devel <xen-devel@...ts.xensource.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jan Beulich <JBeulich@...e.com>, Lv Zheng <lv.zheng@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	long.wanglong@...wei.com, Fengguang Wu <fengguang.wu@...el.com>,
	qiuxishi@...wei.com, Andrey Ryabinin <ryabinin.a.a@...il.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	david.e.box@...el.com, X86 ML <x86@...nel.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to
 paravirt_legacy



On 02/06/2016 05:04 PM, Borislav Petkov wrote:
> On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote:
>> int __init microcode_init(void)
>> {
>>          [...]
>>          if (paravirt_enabled() || dis_ucode_ldr)
>>                  return -EINVAL;
>>
>> This is also asking "are we the natively booted kernel?"  This is
>> plausibly useful for real.  (Borislav, is this actually necessary?)
> There was some breakage on 32-bit pvops with that.
>
>> Seems to me there should be a function is_native_root_kernel() or
>> similar.  Obviously it could have false positives and code will have
>> to deal with that.  (This also could be entirely wrong.  What code is
>> responsible for CPU microcode updates on Xen?  For all I know, dom0 is
>> *supposed* to apply microcode updates, in which case that check really
>> should be deleted.
> So there are two aspects:
>
> - the guest loading the microcode driver. Xen should behave like
> qemu+kvm does: emulate the MSR accesses the microcode loader does.

It does. Very much IIRC, the problem was not caused by an access to MSR 
but rather some sort of address not being available somewhere.

>
> - microcode application on Xen: we've had this before. The hypervisor
> should do that (if it doesn't do so already).

it does.

>
> So yes, that paravirt_enabled() thing should go away. Even more so if we
> have CPUID leaf 0x4... reserved for hypervisors.

I actually think this was the original proposal until we realized we had 
paravirt_enabled(). So we can go back to checking CPUID 0x40000000.

We might also be able to test for (x86_hyper!=NULL) and have guests that 
do microcode management prior to init_hypervisor() rely on hypervisors 
ignoring MSR accesses (as they do today).

-boris