From nobody Sun Feb 8 18:32:56 2026 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (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 F1A263112B7 for ; Thu, 29 Jan 2026 15:44:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769701465; cv=none; b=C2+qUiYCa9JdZkrfMjJ4qBDE6k0DQOOZvWKaw5TYSFjIxzwE+I0mZ6tzYUOcMNzoeO6pmhRFe/SRETBPEF4jNepMvz9iOhUp0Smy+5cQ7np2Bw3fbNLphhJplgEjxRHLSjGtRWfWvoi7tr8RMYYJ58hvhWmlpLAFanA0w6OjoK0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769701465; c=relaxed/simple; bh=O4wQl6ztsVxKHCg9mpsNulwolqDv8ok2ibmwWZe5NIE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=fSxpzs/w0jXhpKQDy1cgh6YflJJtjtmPW/l2iKFyNP2LWuPAFu5QJPfrav4YUCCvmGjk8ufK8Ib98zDfNwUxa9TYcMSYStytRAt5JR4Wj7pZX/tJHz5EUFXAK+qHKfanuUg8I3GwDELPdKBA5bFVI/zjpAeNcEmqbawIE1kshLo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=cfg.kr; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.215.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=cfg.kr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-c633984fbeeso860805a12.0 for ; Thu, 29 Jan 2026 07:44:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769701463; x=1770306263; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QlWLkMnxrXvfVZhQr8oJUjU9Khbfj/+FPzf0jDICauw=; b=k8EOU4UzWnlm6Y0++dmalikaTUe248GEk5Xov0rI9xCcPHXIrVeCkwHzdc/DecZZ0d Fo1UGll4/juhRT3m8hzhhdAejTea2DKI9R6Q4kB0hBiJXTbuFiGrBX53HW3MALcug979 0FxKq2B0op9zTMbxSUQb6yxSuqq1J8/+WZoHQhOWNWWA5T3fhHipbaeBM16O4SfikNMF rduAdSkMhNStsleeQ2er2PBuoN3qN3AvztVdtvRp99cFvy1ELjCxJztCqW0JEAPymUy5 NjpRENEXnMEr9Nw3KaxQHcXA6mHHgSEVPBqWrDOA6K2X84DFcnsE1yTuqTmBMuw6TqtB zVPQ== X-Forwarded-Encrypted: i=1; AJvYcCWm2aDuubJCgjgwNr6s/vis69WWOwJGdC5S+IdMfrKtFU+aV4k1GJN4uR/R+voG/JY+KdhD/ogiEgeFsGE=@vger.kernel.org X-Gm-Message-State: AOJu0YyujS3N40+L3TWcWjM1yu/HTNL1AQ1qkIPVORfhxRwAYt5ndGLg q7ISMiaLBlWfdMPjrpXsufqksJ/4pxuI7BNO6468+NI7nH9ukFyefmj+ X-Gm-Gg: AZuq6aIoStzXcLt6jSGJJCPFc41c+3kFQKc2+l7PbK+8W5vUdvJM8+Bomau+n2Fap2k q/CCXbKMAhdRoHMq2zNR7xjAES62ZLaJVE+12TrMzGbEQifT9h7J8kgZalJz8hybm8oMllLzGMl zGIqRAfcUv+5pMdkSAM8PYZcMQNC3xUiHmPptF3XUTu6IDC0TdWNKTkcAQdnnjrvWr1NVSKfoYR eOSNEu6CJxqAsUaDt7tyo5yWLcS6odh1CboHqwU5w2Z+/Wr0SrBAzqkJcCnUUgX0IYQM3Piba9s M2Pgt9FnhMijFCBFiYQGAQL9WtTjwoqexq4pFsuEa4rJ9hVwNYboV24+7Ojd0e0Vbo7umkrrZR3 Rs1yl53kJFaC25cb8Hlv+sJyzKcIiqtCFoIIOuFpESGCJjwwZW/qH5Vb39PKL3u7rZx2A9MNLNW LV5uU= X-Received: by 2002:a17:902:d512:b0:2a0:c92e:a378 with SMTP id d9443c01a7336-2a8bd45744amr33838245ad.7.1769701463235; Thu, 29 Jan 2026 07:44:23 -0800 (PST) Received: from localhost ([211.244.25.5]) by smtp.gmail.com with UTF8SMTPSA id d9443c01a7336-2a88b5d9a7bsm53484965ad.79.2026.01.29.07.44.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jan 2026 07:44:22 -0800 (PST) From: moontorise@cfg.kr To: x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen Cc: "H . Peter Anvin" , Peter Zijlstra , Pawan Gupta , Josh Poimboeuf , linux-kernel@vger.kernel.org, Joongsun Moon-Lee Subject: [PATCH] x86/cpu/intel: Add RFDS mitigation quirk for Goldmont and Tremont-D Date: Fri, 30 Jan 2026 00:43:42 +0900 Message-ID: <20260129154342.3867-1-moontorise@cfg.kr> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Intel's "Guidance for Security Issues on Intel Processors" [1] lists Goldmont (06_5CH) and Tremont-D (06_86H) as capable of mitigating Register File Data Sampling (RFDS) [2] starting from specific microcode revisions as defined in the consolidated product CPU model table. However, unlike newer models, these processors do not enumerate the RFDS_CLEAR bit (Bit 28) in the IA32_ARCH_CAPABILITIES MSR even with the required microcode. This suggests that while the implementation for clearing the register file via VERW is present, the architectural reporting bit is missing. Consequently, these systems remain identified as "Vulnerable: No microcode" because the kernel strictly relies on the MSR bit. Introduce a quirk to explicitly set the X86_FEATURE_RFDS_CLEAR feature flag based on the microcode revisions defined in Intel's guidance [1]: - Goldmont (06_5CH): 0x28 or later - Tremont-D (06_86H) Stepping 7: 0x4c000026 or later Also, update verw_clears_cpu_reg_file() to check for this feature flag in addition to the MSR bit. Verification was performed on an Intel NUC8CCHKR (Celeron N3350 / Goldmont) with microcode 0x48, confirming the status change from "Vulnerable: No microcode" to "Mitigation: Clear Register File". [1] https://www.intel.com/content/www/us/en/developer/topic-technology/soft= ware-security-guidance/processors-affected-consolidated-product-cpu-model.h= tml#tab-blade-1-1 [2] https://www.intel.com/content/www/us/en/developer/articles/technical/so= ftware-security-guidance/advisory-guidance/register-file-data-sampling.html Signed-off-by: Joongsun Moon-Lee --- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/bugs.c | 3 ++- arch/x86/kernel/cpu/intel.c | 16 ++++++++++++++++ 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpuf= eatures.h index 63b0f9aa9b3e..3480d9ddc046 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -513,6 +513,7 @@ * and purposes if CLEAR_CPU_BUF_VM is set). */ #define X86_FEATURE_X2AVIC_EXT (21*32+20) /* AMD SVM x2AVIC support for 4= k vCPUs */ +#define X86_FEATURE_RFDS_CLEAR (21*32+21) /* Clear register file via VERW= */ =20 /* * BUG word(s) diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 83f51cab0b1e..20c1fa47f04b 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -650,7 +650,8 @@ static const char * const rfds_strings[] =3D { =20 static inline bool __init verw_clears_cpu_reg_file(void) { - return (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR); + /* Check the synthetic flag for CPUs not reporting RFDS_CLEAR via MSR. */ + return (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR) || boot_cpu_has(X86_FEATU= RE_RFDS_CLEAR); } =20 static void __init rfds_select_mitigation(void) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index 646ff33c4651..02f4ac2069f8 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -325,6 +325,22 @@ static void early_init_intel(struct cpuinfo_x86 *c) setup_clear_cpu_cap(X86_FEATURE_PGE); } =20 + /* + * Goldmont and Tremont-D support RFDS mitigation via VERW, + * but do not enumerate it in MSRs. Explicitly set the capability + * based on the microcode revision. (Tremont-D requires stepping 7). + */ + switch (c->x86_vfm) { + case INTEL_ATOM_GOLDMONT: + if (c->microcode >=3D 0x28) + set_cpu_cap(c, X86_FEATURE_RFDS_CLEAR); + break; + case INTEL_ATOM_TREMONT_D: + if (c->x86_stepping =3D=3D 7 && c->microcode >=3D 0x4c000026) + set_cpu_cap(c, X86_FEATURE_RFDS_CLEAR); + break; + } + check_memory_type_self_snoop_errata(c); =20 /* base-commit: 271605ee159b528465e451e0be90baf8103b52bc --=20 2.52.0