From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f73.google.com (mail-ej1-f73.google.com [209.85.218.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B28E1BD9C9 for ; Fri, 14 Nov 2025 12:55:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763124913; cv=none; b=TF0SRLqlT3QEqomZVO102c1qO/O0lIMarThv0V5EBTowIx1Yua6GiCjuJj4QxS30r/IF1ThwxAp6SvFtdSUBEdxQMaFRu0P4LmEWE0DQ7Dn0CHOqn+k+UzP5r97dJEqFza8j7YjS8lKG9HJlv9QfM8IrMrjqDJT6o4OZT9rZB8k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763124913; c=relaxed/simple; bh=sySqVUk457bLkhWa1tebcUxVXEN11B88TtIPHU4/kCA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=phhuDvCkPdsRcBvK3fxSt9MD7Aif+4IjdfJuTxswlvKnMrVc1LgfuzJq85cN+I1qDFj8vNN2kXE1f03gCIS6cLqeyNnP9kVIziBBq2kqRjaqTccVSiqbbgVRjPYSzX6JqSQuMBRi+jhyLMZ5991rjEFj/BALaRGrPzyl85i7upw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=sXI29/qw; arc=none smtp.client-ip=209.85.218.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sXI29/qw" Received: by mail-ej1-f73.google.com with SMTP id a640c23a62f3a-b72a95dc686so156721266b.3 for ; Fri, 14 Nov 2025 04:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1763124910; x=1763729710; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=2HxCD0Qsgw0zxEHnyBGjV1RcHkNO4co8KVcOu35c6Ak=; b=sXI29/qw6RAfNMYnl56IGo1Ub/R2UXNbQO1TduF6XrGZxARpDplXkNp9nhUCjVHV3/ kDtUQtgLQaCWKeyZoTSrex+QsqQxd/3z8H57j3Yzhvr52Rj4Hr04LioQ5ZjQfigqgAQE S2UixjlQylfxdhtHsWDvpuwQHRRXtrzJhzvGKOuHec297Dm4RV7WZkcuIZ2zFTNLQAoP DHEtfBu6f46Zj+6IEytXkE8D3pJtZF/L/WbzNIWFremtiB/5CDGso7ItZCo9XKvW/i7o cM2T7NLtB6hPpCIR1eQtwBHDmKQ+/7xU6Avpwq6dFRsPxL0EddHVsnXKrL7xtGI9LFy1 4W9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763124910; x=1763729710; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2HxCD0Qsgw0zxEHnyBGjV1RcHkNO4co8KVcOu35c6Ak=; b=WXMhrO/YZHGWd8bw6pbmZAFAPbulJ4myn91aX/I+ADGpPB5R1dThKZU8GWp7cqjciy V9bj6iGBG+0U4EuxGaf4R9MhqdhAYdufcTu/i8+MDMVZ6i74SIOV69XLdhK1x9BLUYjj pKtx96qE6uSLXhBYBopgXzJlyMQNiyEuTtGOT+W0le5Q0syb9DWCd41KeHtVjGXk5euD +d4LY7YmENladqYorRi0B9668kGkJ8+EBdRyBeIl7C7HAY/vc4CkWH7GuNLZD6q8v6DT kKvWzpbktSB1NHRXZEM3AwoJWG0dgiVdnz0+qF5fR690Lp1cjnZE4vhfIJNLweIZkrZg 7OYw== X-Forwarded-Encrypted: i=1; AJvYcCWj9zIYpzjHPcpRQuGo8R/jjwFdUzJ/Wl4tXLF+16h47Fdr7AtHgTaxpV0UBsVjXI7nTB6zHqKxu1td6no=@vger.kernel.org X-Gm-Message-State: AOJu0YxFdh27ncCdyY12VVc8ABr4361UAM5COpLqTGK0R00QDvW0mm5I 8XcPFBNccDmYwPDu4kevzZdhel6p4ph6sVnWGwENlP9dOs/scZ+cU0EANVLSv3mJXL1SK7TILpD b9lyPB56p3drBDg== X-Google-Smtp-Source: AGHT+IEYjPBWhz3rzNNbkakQj9ptp4kfVtNX/+ZocC5LUv3BmWKToHZPCwYhsFf7lsQT6XRasLB0eZNdlcjtJw== X-Received: from ejctb22.prod.google.com ([2002:a17:907:8b96:b0:b72:41e4:7562]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a17:906:f299:b0:b73:6d2f:4bb8 with SMTP id a640c23a62f3a-b736d2f577bmr150843766b.2.1763124910000; Fri, 14 Nov 2025 04:55:10 -0800 (PST) Date: Fri, 14 Nov 2025 12:55:09 +0000 In-Reply-To: <20251113233746.1703361-6-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251113233746.1703361-1-seanjc@google.com> <20251113233746.1703361-6-seanjc@google.com> X-Mailer: aerc 0.21.0 Message-ID: Subject: Re: [PATCH v5 5/9] KVM: VMX: Handle MMIO Stale Data in VM-Enter assembly via ALTERNATIVES_2 From: Brendan Jackman To: Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Borislav Petkov , Peter Zijlstra , Josh Poimboeuf Cc: , , Pawan Gupta , Brendan Jackman Content-Type: text/plain; charset="UTF-8" On Thu Nov 13, 2025 at 11:37 PM UTC, Sean Christopherson wrote: > Rework the handling of the MMIO Stale Data mitigation to clear CPU buffers > immediately prior to VM-Enter, i.e. in the same location that KVM emits a > VERW for unconditional (at runtime) clearing. Co-locating the code and > using a single ALTERNATIVES_2 makes it more obvious how VMX mitigates the > various vulnerabilities. > > Deliberately order the alternatives as: > > 0. Do nothing > 1. Clear if vCPU can access MMIO > 2. Clear always > > since the last alternative wins in ALTERNATIVES_2(), i.e. so that KVM will > honor the strictest mitigation (always clear CPU buffers) if multiple > mitigations are selected. E.g. even if the kernel chooses to mitigate > MMIO Stale Data via X86_FEATURE_CLEAR_CPU_BUF_VM_MMIO, another mitigation > may enable X86_FEATURE_CLEAR_CPU_BUF_VM, and that other thing needs to win. > > Note, decoupling the MMIO mitigation from the L1TF mitigation also fixes > a mostly-benign flaw where KVM wouldn't do any clearing/flushing if the > L1TF mitigation is configured to conditionally flush the L1D, and the MMIO > mitigation but not any other "clear CPU buffers" mitigation is enabled. > For that specific scenario, KVM would skip clearing CPU buffers for the > MMIO mitigation even though the kernel requested a clear on every VM-Enter. > > Note #2, the flaw goes back to the introduction of the MDS mitigation. The > MDS mitigation was inadvertently fixed by commit 43fb862de8f6 ("KVM/VMX: > Move VERW closer to VMentry for MDS mitigation"), but previous kernels > that flush CPU buffers in vmx_vcpu_enter_exit() are affected (though it's > unlikely the flaw is meaningfully exploitable even older kernels). > > Fixes: 650b68a0622f ("x86/kvm/vmx: Add MDS protection when L1D Flush is not active") > Suggested-by: Pawan Gupta > Reviewed-by: Pawan Gupta > Signed-off-by: Sean Christopherson Reviewed-by: Brendan Jackman