Received-SPF: pass (google.com: domain of linux-kernel+bounces-159160-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Thu, 25 Apr 2024 16:45:10 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alexandre Chartre <alexandre.chartre@oracle.com>, dave.hansen@intel.com,
        x86@kernel.org
Cc: Dave Hansen <dave.hansen@intel.com>, Chao Gao <chao.gao@intel.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>, x86@kernel.org,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        daniel.sneddon@linux.intel.com, pawan.kumar.gupta@linux.intel.com,
        tglx@linutronix.de, peterz@infradead.org, gregkh@linuxfoundation.org,
        seanjc@google.com, dave.hansen@linux.intel.com, nik.borisov@suse.com,
        kpsingh@kernel.org, longman@redhat.com, bp@alien8.de,
        pbonzini@redhat.com
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected
 by BHI
Message-ID: <ZirA1v5VL7Tdk0ej@char.us.oracle.com>
References: <20240411072445.522731-1-alexandre.chartre@oracle.com>
 <7f1faa48-6252-4409-aefc-2ed2f38fb1c3@citrix.com>
 <caa51938-c587-4403-a9cd-16e8b585bc13@oracle.com>
 <d47dcc77-3c8b-4f78-954a-a64d3a905224@citrix.com>
 <ZhfGHpAz7W7d/pSa@chao-email>
 <95902795-0c2c-43cc-8d87-89302a2eed2b@oracle.com>
 <2af16cb4-32ed-4b91-872b-f0cc9ed92e59@oracle.com>
 <a8af757b-a40a-40dd-a543-99a39a0fe8ad@intel.com>
 <2154b190-9cd1-4b24-83bb-460a708a45a3@oracle.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2154b190-9cd1-4b24-83bb-460a708a45a3@oracle.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?iso-8859-1?Q?46CspKdV+bAYrcssCnQt3thOpYOiXzJteHRFN/G+18mskR0shXjyJJ4aiq?=
 =?iso-8859-1?Q?lBEVBakBBj6yK6DLBdQFvTkhN734rmmZL4VgbXd9CSOPtlBXkrVTHT/M5i?=
 =?iso-8859-1?Q?vCWx+jgdLnnFnGv1E8m/Q2paHFbF3V4H73Cpg9huM12wuc37I8EK9yA0wE?=
 =?iso-8859-1?Q?cDCU1h2ZL0KZHhINjSDuEPGKE00/ej9K7xHjYWA+BNucdULBm0AOI5BvCo?=
 =?iso-8859-1?Q?FVCB3F8ma+XvZZkpqFhmcDpBsitIqbeTs2ZwMVxZZawIJVxkzFQGE/rnhl?=
 =?iso-8859-1?Q?H04WsDDkilGDe+Xhg/B3RgfVczS22MRGIICpmWl7YUjNu5we1VJ1hAfH1E?=
 =?iso-8859-1?Q?NQaDUQz9zBZ5RjxIAWGl6e49wIqmb2szKeSGcGS0XtkzGheZm6bJUX85Li?=
 =?iso-8859-1?Q?bdM7RhQRgUez1b+T+/SY15RdzWLwGBNC6B2inQ05sC5EApyAOmpjzK/nTL?=
 =?iso-8859-1?Q?3wdMGvrEWTpfmGclouvdfs28gsZqr/x6gLYn8DaUxb0mlFz2uM74mdz45/?=
 =?iso-8859-1?Q?PXmQrpnxejvtwgLTqYZ6eAeIYMby20FwLa8cJljnf5lqkFweJl86R1GmZW?=
 =?iso-8859-1?Q?E0wgZh0Eu1WZT92+Q90Wz37xKtzbWhq6sS+nFI3ku9t8n4MZHqG/SGaZfv?=
 =?iso-8859-1?Q?+Jis836UAkP8T3j+y+628PonimaOcd231A6q0UR+xYADDCjKHrSNUC4f9+?=
 =?iso-8859-1?Q?/POh8KeFRH1241YKUYx0RYZ/kMoQevzx4Bp2OLLs+OwmzxsmptyCneO0Bm?=
 =?iso-8859-1?Q?F/Qy/AYRrNmJBoZXIsYliC9Ow+yyKOp44SA8sTXmrOow78pZN9+w9U45Yv?=
 =?iso-8859-1?Q?b0nBFFGQ6Fh+qMN0UU9Ct5p7y8N1inbHJJoMVMIQlYV/nZVbNN1dDfZNEg?=
 =?iso-8859-1?Q?NPqZpSiD+cwoJ5pldJH3LKvR/FrxXNGjTXZrdfq4ehc1mzPcaRG8uGNzEm?=
 =?iso-8859-1?Q?yUdEiCpYejYuNMksDIYIlf6O4qYTfvzk0S/67KyJ3AJfolrx6+/HDFWTW6?=
 =?iso-8859-1?Q?30U2zR6fxSnH7u6uwdFow1UPV3y9GD37ikqRr/g01avAlC3RvXFsPKVGPw?=
 =?iso-8859-1?Q?eslxpAYIRJolX3vWniifQz/7+IgKOkGNS92weP2xRUt4zoJollulBQIddN?=
 =?iso-8859-1?Q?pfIvrPJSJgy8AN4Mk4qTFNgRgEqakgv5fYjKn3PPf71BrcMvM03BZwQTaO?=
 =?iso-8859-1?Q?EveeybUcfCw4ajMN7Qf/O7tu7hF8sSHbBzXdWJVw14B5BcGZfLPMKmbMsw?=
 =?iso-8859-1?Q?ammPt+XvglTT4yqGGyMIKjL+oKRGwHBnu+nmRLDV/AtAYSoT/tQ+5+Y21R?=
 =?iso-8859-1?Q?ftQ5aWD7OhN5VmeSMQ6delyXXJYkeT2OEzvz8UX0YZZtX4LWTMUC/na3yP?=
 =?iso-8859-1?Q?LNCdksnJLzSkRhOLcWCNBHVwNXNkfsORbD7ZrqO3AjPdq6/oLPn3lvxZFc?=
 =?iso-8859-1?Q?N5umLXGDOfCdhegUdSqj2Q4quUm9pBbjYkuJtA/+GOcd8ECrocbDY+OQRX?=
 =?iso-8859-1?Q?X+ryajvylSXX6RtFjXhvS1hFvaOGUS2/y7l5UuZwoSvH74/AQrWOTcnt6z?=
 =?iso-8859-1?Q?xnPey3cG1dVjIqZNnSJmqOlxxy7ndZLFNDEUkPFqRJ4frKpIW6RRCX5NQt?=
 =?iso-8859-1?Q?3DnEpB9RDRjSlZjB8eWHZ2uRNH3omf773Hg1o2a7rujsJDS+Rkcj7ksA?=
 =?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	Sh1NY996jFSnJbSVRHMpDT/khwi/OCUGH8kp4fvswjzeSG+V/nyp45NXGlCpmtYwQIE6mDMKFsP16ajMaq3CwQPaJVI9w0Pr9KwviOgyIlI1yZtRocVSIUoreT6E/p8cPS6f33ebt8ky7djECtxSUlYQyTXSM3yuflGL8bXNE3lwO/voepuwkZKaCkBDRwiGPrHseIqFmJ+wlGfyaX3TDdWVJe9TVAfkUw+7mdYPhBiA+uBlGRC75uQVx0bem6BE/9r5adkTdNjW2q9xMC55ew7rmUe8tNzIO6WSoQLWwU2/UPgUDiwJEXkkrVAem9wpI3YYgvv0NcxUKGUPoPZyl2j6HyD8ryOLYvA6OZG8NKwquzP+Qg9yNmEz7weQTkDPxBTOqx61hCx/LfMyM7nCVmeOk7LqbQUAhMbdSZvPae+q8fNBvb8EU7vW9gllPeC95xbt6Ekl8XC49oV10m16T7kxO+5c5f7PTvJ6NM2DGXhmJzJorxyOxjcPp+oOk4PiszL3GAnlI57NSU7vJtJ0xLaqd2yxLCAwfZdjC6KjYb0cfJhWW/DYr1lx7XD5g65xZtCEPavywRUL6mNLtUzlD7x0kQyn763tvTExtQr8RlM=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cd781d24-c00d-4d77-973a-08dc6568a2d9
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB6719.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2024 20:45:26.5076
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UTheU/iARQWGjLiHEyItKV+uZZd/oETdLQ+Eh8qfy4QYFxDhjcZ83vAvKGHcYHAIuF6Jwxcw8TLEB9RMQuP3bw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR10MB7909
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26
 definitions=2024-04-25_20,2024-04-25_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 bulkscore=0
 mlxlogscore=999 spamscore=0 malwarescore=0 mlxscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000
 definitions=main-2404250150
X-Proofpoint-ORIG-GUID: -OZK4OrK-yyzX-InlIerqv16xC7bbg0J
X-Proofpoint-GUID: -OZK4OrK-yyzX-InlIerqv16xC7bbg0J

On Tue, Apr 16, 2024 at 10:41:58AM +0200, Alexandre Chartre wrote:
> 
> On 4/15/24 19:17, Dave Hansen wrote:
> > > +?????? /*
> > > +??????? * The following Intel CPUs are affected by BHI, but they don't have
> > > +??????? * the eIBRS feature. In that case, the default Spectre v2 mitigations
> > > +??????? * are enough to also mitigate BHI. We mark these CPUs with NO_BHI so
> > > +??????? * that X86_BUG_BHI doesn't get set and no extra BHI mitigation is
> > > +??????? * enabled.
> > > +??????? *
> > > +??????? * This avoids guest VMs from enabling extra BHI mitigation when this
> > > +??????? * is not needed. For guest, X86_BUG_BHI is never set for CPUs which
> > > +??????? * don't have the eIBRS feature. But this doesn't happen in guest VMs
> > > +??????? * as the virtualization can hide the eIBRS feature.
> > > +??????? */
> > > +?????? VULNWL_INTEL(IVYBRIDGE_X,?????????????? NO_BHI),
> > > +?????? VULNWL_INTEL(HASWELL_X,???????????????? NO_BHI),
> > > +?????? VULNWL_INTEL(BROADWELL_X,?????????????? NO_BHI),
> > > +?????? VULNWL_INTEL(SKYLAKE_X,???????????????? NO_BHI),
> > > +?????? VULNWL_INTEL(SKYLAKE_X,???????????????? NO_BHI),
> > 
> > Isn't this at odds with the existing comment?
> > 
> >          /* When virtualized, eIBRS could be hidden, assume vulnerable */
> > 
> > Because it seems now that we've got two relatively conflicting pieces of
> > vulnerability information when running under a hypervisor.
> 
> It's not at odd, it's an additional information. The comment covers the general
> case.
> 
> When running under a hypervisor then the kernel can't rely on CPU features to
> find if the server has eIBRS or not, because the virtualization can be hiding
> eIBRS. And that's the problem because the kernel might enable BHI mitigation
> while it's not needed.
> 
> For example on Skylake: on the host, the kernel won't see eIBRS so it won't set
> X86_BUG_BHI. But in a guest on the same platform, the kernel will set X86_BUG_BHI
> because it doesn't know if the server doesn't effectively have eIBRS or if eIBRS
> is hidden by virtualization.
> 
> With the patch, the kernel can know if the CPU it is running on (e.g. Skylake)
> needs extra BHI mitigation or not. Then it can safely not enable BHI mitigation
> no matter if it is running on host or in guest.

Where do we want to go with this one?

The problem (which I think is not understood) is that on Skylake there
is no Enhanced IBRS support. There is either IBRS or retpoline - and when IBRS
is enabled it does the job of mitigating against BHI.

And as of right now on Skylake guests we enable BHI _and_ IBRS for extra
slowdown.

We can't disable IBRS as it mitigates against other bugs too, so how do
you folks want to disable automatically BHI on Skylake with the least
amount of code?