| af05e558 | 12-Jan-2026 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/sev: Use kfree_sensitive() when freeing a SNP message descriptor
Use the proper helper instead of an open-coded variant.
Closes: https://lore.kernel.org/r/202512202235.WHPQkLZu-lkp@intel.com Re
x86/sev: Use kfree_sensitive() when freeing a SNP message descriptor
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 <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260112114147.GBaWTd-8HSy_Xp4S3X@fat_crate.local
show more ...
|
| 9183c97e | 19-Jan-2026 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/sev: Rename sev_es_ghcb_handle_msr() to __vc_handle_msr()
Forgot to do that during the Secure AVIC review. :-\
No functional changes.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Review
x86/sev: Rename sev_es_ghcb_handle_msr() to __vc_handle_msr()
Forgot to do that during the Secure AVIC review. :-\
No functional changes.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260119141310.29605-1-bp@kernel.org
show more ...
|
| e21279b7 | 04-Dec-2025 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/sev: Carve out the SVSM code into a separate compilation unit
Move the SVSM-related machinery into a separate compilation unit in order to keep sev/core.c slim and "on-topic".
No functional cha
x86/sev: Carve out the SVSM code into a separate compilation unit
Move the SVSM-related machinery into a separate compilation unit in order to keep sev/core.c slim and "on-topic".
No functional changes.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251204124809.31783-4-bp@kernel.org
show more ...
|
| f01c6489 | 04-Dec-2025 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/sev: Add internal header guards
All headers need guards ifdeffery.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.ms
x86/sev: Add internal header guards
All headers need guards ifdeffery.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251204124809.31783-3-bp@kernel.org
show more ...
|
| b2c1dd6c | 30-Oct-2025 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/coco/sev: Convert has_cpuflag() to use cpu_feature_enabled()
Drop one redundant definition, while at it.
There should be no functional changes.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.
x86/coco/sev: Convert has_cpuflag() to use cpu_feature_enabled()
Drop one redundant definition, while at it.
There should be no functional changes.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251031122122.GKaQSpwhLvkinKKbjG@fat_crate.local
show more ...
|
| d4bc3b11 | 03-Sep-2025 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/apic/savic: Do not use snp_abort()
This function is going away so replace the callsites with the equivalent functionality. Add a new SAVIC-specific termination reason. If more granularity is nee
x86/apic/savic: Do not use snp_abort()
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) <bp@alien8.de>
show more ...
|
| 7b38dec3 | 28-Aug-2025 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Create a confined code area for startup code
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
x86/boot: Create a confined code area for startup code
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 <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-43-ardb+git@google.com
show more ...
|
| d4077e6a | 28-Aug-2025 |
Ard Biesheuvel <ardb@kernel.org> |
x86/sev: Move __sev_[get|put]_ghcb() into separate noinstr object
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
x86/sev: Move __sev_[get|put]_ghcb() into separate noinstr object
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 <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-37-ardb+git@google.com
show more ...
|
| 9723dd0c | 28-Aug-2025 |
Ard Biesheuvel <ardb@kernel.org> |
x86/sev: Provide PIC aliases for SEV related data objects
Provide PIC aliases for data objects that are shared between the SEV startup code and the SEV code that executes later. This is needed so th
x86/sev: Provide PIC aliases for SEV related data objects
Provide PIC aliases for data objects that are shared between the SEV startup code and the SEV code that executes later. This is needed so that the confined startup code is permitted to access them.
This requires some of these variables to be moved into a source file that is not part of the startup code, as the PIC alias is already implied, and exporting variables in the opposite direction is not supported.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-36-ardb+git@google.com
show more ...
|
| c54604fb | 28-Aug-2025 |
Ard Biesheuvel <ardb@kernel.org> |
x86/sev: Use boot SVSM CA for all startup and init code
To avoid having to reason about whether or not to use the per-CPU SVSM calling area when running startup and init code on the boot CPU, reuse
x86/sev: Use boot SVSM CA for all startup and init code
To avoid having to reason about whether or not to use the per-CPU SVSM calling area when running startup and init code on the boot CPU, reuse the boot SVSM calling area as the per-CPU area for the BSP.
Thus, remove the need to make the per-CPU variables and associated state in sev_cfg accessible to the startup code once confined.
[ bp: Massage commit message. ]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-33-ardb+git@google.com
show more ...
|
| 00d25566 | 28-Aug-2025 |
Ard Biesheuvel <ardb@kernel.org> |
x86/sev: Pass SVSM calling area down to early page state change API
The early page state change API is mostly only used very early, when only the boot time SVSM calling area is in use. However, this
x86/sev: Pass SVSM calling area down to early page state change API
The early page state change API is mostly only used very early, when only the boot time SVSM calling area is in use. However, this API is also called by the kexec finishing code, which runs very late, and potentially from a different CPU (which uses a different calling area).
To avoid pulling the per-CPU SVSM calling area pointers and related SEV state into the startup code, refactor the page state change API so the SVSM calling area virtual and physical addresses can be provided by the caller.
No functional change intended.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-32-ardb+git@google.com
show more ...
|
| a5f03880 | 28-Aug-2025 |
Ard Biesheuvel <ardb@kernel.org> |
x86/sev: Avoid global variable to store virtual address of SVSM area
The boottime SVSM calling area is used both by the startup code running from a 1:1 mapping, and potentially later on running from
x86/sev: Avoid global variable to store virtual address of SVSM area
The boottime SVSM calling area is used both by the startup code running from a 1:1 mapping, and potentially later on running from the ordinary kernel mapping.
This SVSM calling area is statically allocated, and so its physical address doesn't change. However, its virtual address depends on the calling context (1:1 mapping or kernel virtual mapping), and even though the variable that holds the virtual address of this calling area gets updated from 1:1 address to kernel address during the boot, it is hard to reason about why this is guaranteed to be safe.
So instead, take the RIP-relative address of the boottime SVSM calling area whenever its virtual address is required, and only use a global variable for the physical address.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/20250828102202.1849035-30-ardb+git@google.com
show more ...
|
| 37dbd78f | 28-Aug-2025 |
Ard Biesheuvel <ardb@kernel.org> |
x86/sev: Move GHCB page based HV communication out of startup code
Both the decompressor and the core kernel implement an early #VC handler, which only deals with CPUID instructions, and full featur
x86/sev: Move GHCB page based HV communication out of startup code
Both the decompressor and the core kernel implement an early #VC handler, which only deals with CPUID instructions, and full featured one, which can handle any #VC exception.
The former communicates with the hypervisor using the MSR based protocol, whereas the latter uses a shared GHCB page, which is configured a bit later during the boot, when the kernel runs from its ordinary virtual mapping, rather than the 1:1 mapping that the startup code uses.
Accessing this shared GHCB page from the core kernel's startup code is problematic, because it involves converting the GHCB address provided by the caller to a physical address. In the startup code, virtual to physical address translations are problematic, given that the virtual address might be a 1:1 mapped address, and such translations should therefore be avoided.
This means that exposing startup code dealing with the GHCB to callers that execute from the ordinary kernel virtual mapping should be avoided too. So move all GHCB page based communication out of the startup code, now that all communication occurring before the kernel virtual mapping is up relies on the MSR protocol only.
As an exception, add a flag representing the need to apply the coherency fix in order to avoid exporting CPUID* helpers because of the code running too early for the *cpu_has* infrastructure.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-29-ardb+git@google.com
show more ...
|
| 952aefee | 28-Aug-2025 |
Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> |
x86/sev: Prevent SECURE_AVIC_CONTROL MSR interception for Secure AVIC guests
The SECURE_AVIC_CONTROL MSR holds the GPA of the guest APIC backing page and bitfields to control enablement of Secure AV
x86/sev: Prevent SECURE_AVIC_CONTROL MSR interception for Secure AVIC guests
The SECURE_AVIC_CONTROL MSR holds the GPA of the guest APIC backing page and bitfields to control enablement of Secure AVIC and whether the guest allows NMIs to be injected by the hypervisor.
This MSR is populated by the guest and can be read by the guest to get the GPA of the APIC backing page. The MSR can only be accessed in Secure AVIC mode. Any attempt to access it when not in Secure AVIC mode results in #GP. So, the hypervisor should not intercept it. A #VC exception will be generated otherwise. If this occurs and Secure AVIC is enabled, terminate the guest execution.
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tianyu Lan <tiala@microsoft.com> Link: https://lore.kernel.org/20250828113119.209135-1-Neeraj.Upadhyay@amd.com
show more ...
|
| c8018325 | 28-Aug-2025 |
Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> |
x86/apic: Add kexec support for Secure AVIC
Add a apic->teardown() callback to disable Secure AVIC before rebooting into the new kernel. This ensures that the new kernel does not access the old APIC
x86/apic: Add kexec support for Secure AVIC
Add a apic->teardown() callback to disable Secure AVIC before rebooting into the new kernel. This ensures that the new kernel does not access the old APIC backing page which was allocated by the previous kernel.
Such accesses can happen if there are any APIC accesses done during the guest boot before Secure AVIC driver probe is done by the new kernel (as Secure AVIC would have remained enabled in the Secure AVIC control MSR).
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828112008.209013-1-Neeraj.Upadhyay@amd.com
show more ...
|
| 28bbfad2 | 28-Aug-2025 |
Kishon Vijay Abraham I <kvijayab@amd.com> |
x86/sev: Enable NMI support for Secure AVIC
Now that support to send NMI IPI and support to inject NMI from the hypervisor has been added, set V_NMI_ENABLE in the VINTR_CTRL field of the VMSA to ena
x86/sev: Enable NMI support for Secure AVIC
Now that support to send NMI IPI and support to inject NMI from the hypervisor has been added, set V_NMI_ENABLE in the VINTR_CTRL field of the VMSA to enable NMI for Secure AVIC guests.
[ bp: Zap useless brackets. ]
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com> Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tianyu Lan <tiala@microsoft.com> Link: https://lore.kernel.org/20250828111315.208959-1-Neeraj.Upadhyay@amd.com
show more ...
|