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]
Message-ID: <ZhfGHpAz7W7d/pSa@chao-email>
Date: Thu, 11 Apr 2024 19:14:38 +0800
From: Chao Gao <chao.gao@...el.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>
CC: Alexandre Chartre <alexandre.chartre@...cle.com>, <x86@...nel.org>,
	<kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<daniel.sneddon@...ux.intel.com>, <pawan.kumar.gupta@...ux.intel.com>,
	<tglx@...utronix.de>, <konrad.wilk@...cle.com>, <peterz@...radead.org>,
	<gregkh@...uxfoundation.org>, <seanjc@...gle.com>,
	<dave.hansen@...ux.intel.com>, <nik.borisov@...e.com>, <kpsingh@...nel.org>,
	<longman@...hat.com>, <bp@...en8.de>, <pbonzini@...hat.com>
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected
 by BHI

>> The problem is that we can end up with a guest running extra BHI
>> mitigations
>> while this is not needed. Could we inform the guest that eIBRS is not
>> available
>> on the system so a Linux guest doesn't run with extra BHI mitigations?
>
>Well, that's why Intel specified some MSRs at 0x5000xxxx.

Yes. But note that there is a subtle difference. Those MSRs are used for guest
to communicate in-used software mitigations to the host. Such information is
stable across migration. Here we need the host to communicate that eIBRS isn't
available to the guest. this isn't stable as the guest may be migrated from
a host without eIBRS to one with it.

>
>Except I don't know anyone currently interested in implementing them,
>and I'm still not sure if they work correctly for some of the more
>complicated migration cases.

Looks you have the same opinion on the Intel-defined virtual MSRs as Sean.
If we all agree the issue here and the effectivenss problem of the short
BHB-clearing sequence need to be resolved and don't think the Intel-defined
virtual MSRs can handle all cases correctly, we have to define a better
interface through community collaboration as Sean suggested.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ