<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/x86/coco, branch v6.19.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-02T11:25:44+00:00</updated>
<entry>
<title>x86/fred: Fix early boot failures on SEV-ES/SNP guests</title>
<updated>2026-04-02T11:25:44+00:00</updated>
<author>
<name>Nikunj A Dadhania</name>
<email>nikunj@amd.com</email>
</author>
<published>2026-03-18T07:56:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c12ab54cdd3ec183fa865f8c9da138f2f9b90b4f'/>
<id>urn:sha1:c12ab54cdd3ec183fa865f8c9da138f2f9b90b4f</id>
<content type='text'>
commit 3645eb7e3915990a149460c151a00894cb586253 upstream.

FRED-enabled SEV-(ES,SNP) guests fail to boot due to the following issues
in the early boot sequence:

* FRED does not have a #VC exception handler in the dispatch logic

* Early FRED #VC exceptions attempt to use uninitialized per-CPU GHCBs
  instead of boot_ghcb

Add X86_TRAP_VC case to fred_hwexc() with a new exc_vmm_communication()
function that provides the unified entry point FRED requires, dispatching
to existing user/kernel handlers based on privilege level. The function is
already declared via DECLARE_IDTENTRY_VC().

Fix early GHCB access by falling back to boot_ghcb in
__sev_{get,put}_ghcb() when per-CPU GHCBs are not yet initialized.

Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Signed-off-by: Nikunj A Dadhania &lt;nikunj@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: &lt;stable@kernel.org&gt;  # 6.12+
Link: https://patch.msgid.link/20260318075654.1792916-4-nikunj@amd.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>x86/sev: Allow IBPB-on-Entry feature for SNP guests</title>
<updated>2026-03-12T11:09:31+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@amd.com</email>
</author>
<published>2026-02-03T22:24:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b91d180a3a3e96da092e9e50663a29190df5266c'/>
<id>urn:sha1:b91d180a3a3e96da092e9e50663a29190df5266c</id>
<content type='text'>
commit 9073428bb204d921ae15326bb7d4558d9d269aab upstream.

The SEV-SNP IBPB-on-Entry feature does not require a guest-side
implementation. It was added in Zen5 h/w, after the first SNP Zen
implementation, and thus was not accounted for when the initial set of SNP
features were added to the kernel.

In its abundant precaution, commit

  8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support")

included SEV_STATUS' IBPB-on-Entry bit as a reserved bit, thereby masking
guests from using the feature.

Allow guests to make use of IBPB-on-Entry when supported by the hypervisor, as
the bit is now architecturally defined and safe to expose.

Fixes: 8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support")
Signed-off-by: Kim Phillips &lt;kim.phillips@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Reviewed-by: Nikunj A Dadhania &lt;nikunj@amd.com&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: stable@kernel.org
Link: https://patch.msgid.link/20260203222405.4065706-2-kim.phillips@amd.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>x86/sev: Use kfree_sensitive() when freeing a SNP message descriptor</title>
<updated>2026-03-04T12:19:47+00:00</updated>
<author>
<name>Borislav Petkov (AMD)</name>
<email>bp@alien8.de</email>
</author>
<published>2026-01-12T11:37:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=930df4b25b21ea8b8af74e1d0b897fd22bd66ea1'/>
<id>urn:sha1:930df4b25b21ea8b8af74e1d0b897fd22bd66ea1</id>
<content type='text'>
[ Upstream commit af05e558988ed004a20fc4de7d0f80cfbba663f0 ]

Use the proper helper instead of an open-coded variant.

Closes: https://lore.kernel.org/r/202512202235.WHPQkLZu-lkp@intel.com
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Reported-by: Julia Lawall &lt;julia.lawall@inria.fr&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://patch.msgid.link/20260112114147.GBaWTd-8HSy_Xp4S3X@fat_crate.local
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/sev: Disable GCOV on noinstr object</title>
<updated>2026-01-05T09:22:48+00:00</updated>
<author>
<name>Brendan Jackman</name>
<email>jackmanb@google.com</email>
</author>
<published>2025-12-16T10:16:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9efb74f84ba82a9de81fc921baf3c5e2decf8256'/>
<id>urn:sha1:9efb74f84ba82a9de81fc921baf3c5e2decf8256</id>
<content type='text'>
With Debian clang version 19.1.7 (3+build5) there are calls to
kasan_check_write() from __sev_es_nmi_complete(), which violates noinstr.  Fix
it by disabling GCOV for the noinstr object, as has been done for previous
such instrumentation issues.

Note that this file already disables __SANITIZE_ADDRESS__ and
__SANITIZE_THREAD__, thus calls like kasan_check_write() ought to be nops
regardless of GCOV. This has been fixed in other patches. However, to avoid
any other accidental instrumentation showing up, (and since, in principle GCOV
is instrumentation and hence should be disabled for noinstr code anyway),
disable GCOV overall as well.

Signed-off-by: Brendan Jackman &lt;jackmanb@google.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Acked-by: Marco Elver &lt;elver@google.com&gt;
Link: https://patch.msgid.link/20251216-gcov-inline-noinstr-v3-3-10244d154451@google.com
</content>
</entry>
<entry>
<title>x86/coco/sev: Convert has_cpuflag() to use cpu_feature_enabled()</title>
<updated>2025-11-11T15:42:31+00:00</updated>
<author>
<name>Borislav Petkov (AMD)</name>
<email>bp@alien8.de</email>
</author>
<published>2025-10-30T16:59:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b2c1dd6c6f70a5a519532227358c82d4cfda5b36'/>
<id>urn:sha1:b2c1dd6c6f70a5a519532227358c82d4cfda5b36</id>
<content type='text'>
Drop one redundant definition, while at it.

There should be no functional changes.

Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://patch.msgid.link/20251031122122.GKaQSpwhLvkinKKbjG@fat_crate.local
</content>
</entry>
<entry>
<title>x86/sev: Include XSS value in GHCB CPUID request</title>
<updated>2025-10-30T16:47:49+00:00</updated>
<author>
<name>John Allen</name>
<email>john.allen@amd.com</email>
</author>
<published>2025-09-24T20:08:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=92ad6505a4b5e28afcc8cf5f4dd3fd137e58026b'/>
<id>urn:sha1:92ad6505a4b5e28afcc8cf5f4dd3fd137e58026b</id>
<content type='text'>
When a guest issues a CPUID instruction for Fn0000000D_x01, the hypervisor may
be intercepting the CPUID instruction and need to access the guest XSS value.
For SEV-ES, the XSS value is encrypted and needs to be included in the GHCB to
be visible to the hypervisor.

Signed-off-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://patch.msgid.link/all/20250924200852.4452-3-john.allen@amd.com/
</content>
</entry>
<entry>
<title>Merge branch 'x86/apic' into x86/sev, to resolve conflict</title>
<updated>2025-09-05T07:01:42+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2025-09-05T07:01:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0ca77f8d33e8136b8926775380506f78a8d04811'/>
<id>urn:sha1:0ca77f8d33e8136b8926775380506f78a8d04811</id>
<content type='text'>
 Conflicts:
	arch/x86/include/asm/sev-internal.h

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/apic/savic: Do not use snp_abort()</title>
<updated>2025-09-04T11:12:51+00:00</updated>
<author>
<name>Borislav Petkov (AMD)</name>
<email>bp@alien8.de</email>
</author>
<published>2025-09-03T15:42:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d4bc3b11c12b41fdb5650f5ad797de97f8dce869'/>
<id>urn:sha1:d4bc3b11c12b41fdb5650f5ad797de97f8dce869</id>
<content type='text'>
This function is going away so replace the callsites with the equivalent
functionality. Add a new SAVIC-specific termination reason. If more
granularity is needed there, it will be revisited in the future.

Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
</content>
</entry>
<entry>
<title>x86/boot: Create a confined code area for startup code</title>
<updated>2025-09-03T16:00:01+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2025-08-28T10:22:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b38dec3c5af54665a4b29483aa02bd1c1e71cf1'/>
<id>urn:sha1:7b38dec3c5af54665a4b29483aa02bd1c1e71cf1</id>
<content type='text'>
In order to be able to have tight control over which code may execute
from the early 1:1 mapping of memory, but still link vmlinux as a single
executable, prefix all symbol references in startup code with __pi_, and
invoke it from outside using the __pi_ prefix.

Use objtool to check that no absolute symbol references are present in
the startup code, as these cannot be used from code running from the 1:1
mapping.

Note that this also requires disabling the latent-entropy GCC plugin, as
the global symbol references that it injects would require explicit
exports, and given that the startup code rarely executes more than once,
it is not a useful source of entropy anyway.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://lore.kernel.org/20250828102202.1849035-43-ardb+git@google.com
</content>
</entry>
<entry>
<title>x86/sev: Move __sev_[get|put]_ghcb() into separate noinstr object</title>
<updated>2025-09-03T15:59:46+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2025-08-28T10:22:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d4077e6ad35121b97f3233da5d60763de3d23df9'/>
<id>urn:sha1:d4077e6ad35121b97f3233da5d60763de3d23df9</id>
<content type='text'>
Rename sev-nmi.c to noinstr.c, and move the get/put GHCB routines into it too,
which are also annotated as 'noinstr' and suffer from the same problem as the
NMI code, i.e., that GCC may ignore the __no_sanitize_address__ function
attribute implied by 'noinstr' and insert KASAN instrumentation anyway.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://lore.kernel.org/20250828102202.1849035-37-ardb+git@google.com
</content>
</entry>
</feed>
