| 82b7f88f | 06-May-2025 |
Ashish Kalra <[email protected]> |
x86/sev: Make sure pages are not skipped during kdump
When shared pages are being converted to private during kdump, additional checks are performed. They include handling the case of a GHCB page be
x86/sev: Make sure pages are not skipped during kdump
When shared pages are being converted to private during kdump, additional checks are performed. They include handling the case of a GHCB page being contained within a huge page.
Currently, this check incorrectly skips a page just below the GHCB page from being transitioned back to private during kdump preparation.
This skipped page causes a 0x404 #VC exception when it is accessed later while dumping guest memory for vmcore generation.
Correct the range to be checked for GHCB contained in a huge page. Also, ensure that the skipped huge page containing the GHCB page is transitioned back to private by applying the correct address mask later when changing GHCBs to private at end of kdump preparation.
[ bp: Massage commit message. ]
Fixes: 3074152e56c9 ("x86/sev: Convert shared memory back to private on kexec") Signed-off-by: Ashish Kalra <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Tested-by: Srikanth Aithal <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/[email protected]
show more ...
|
| 1105ab42 | 27-Jan-2025 |
Ard Biesheuvel <[email protected]> |
x86/sev: Disable jump tables in SEV startup code
When retpolines and IBT are both disabled, the compiler is free to use jump tables to optimize switch instructions. However, these are emitted by Cla
x86/sev: Disable jump tables in SEV startup code
When retpolines and IBT are both disabled, the compiler is free to use jump tables to optimize switch instructions. However, these are emitted by Clang as absolute references into .rodata:
jmp *-0x7dfffe90(,%r9,8) R_X86_64_32S .rodata+0x170
Given that this code will execute before that address in .rodata has even been mapped, it is guaranteed to crash a SEV-SNP guest in a way that is difficult to diagnose.
So disable jump tables when building this code. It would be better if we could attach this annotation to the __head macro but this appears to be impossible.
Reported-by: Linus Torvalds <[email protected]> Tested-by: Linus Torvalds <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| cf4ca806 | 07-Jan-2025 |
Ard Biesheuvel <[email protected]> |
x86/sev: Disable ftrace branch profiling in SEV startup code
Ftrace branch profiling inserts absolute references to its metadata at call sites, and this implies that this kind of instrumentation can
x86/sev: Disable ftrace branch profiling in SEV startup code
Ftrace branch profiling inserts absolute references to its metadata at call sites, and this implies that this kind of instrumentation cannot be used while executing from the 1:1 mapping of memory.
Therefore, disable ftrace branch profiling in the SEV startup routines, by disabling it for the entire SEV core source file.
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Reported-by: kernel test robot <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| 73bbf3b0 | 06-Jan-2025 |
Nikunj A Dadhania <[email protected]> |
x86/tsc: Init the TSC for Secure TSC guests
Use the GUEST_TSC_FREQ MSR to discover the TSC frequency instead of relying on kvm-clock based frequency calibration. Override both CPU and TSC frequency
x86/tsc: Init the TSC for Secure TSC guests
Use the GUEST_TSC_FREQ MSR to discover the TSC frequency instead of relying on kvm-clock based frequency calibration. Override both CPU and TSC frequency calibration callbacks with securetsc_get_tsc_khz(). Since the difference between CPU base and TSC frequency does not apply in this case, the same callback is being used.
[ bp: Carve out from https://lore.kernel.org/r/[email protected] ]
Signed-off-by: Nikunj A Dadhania <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| eef679a4 | 06-Jan-2025 |
Nikunj A Dadhania <[email protected]> |
x86/sev: Prevent RDTSC/RDTSCP interception for Secure TSC enabled guests
The hypervisor should not be intercepting RDTSC/RDTSCP when Secure TSC is enabled. A #VC exception will be generated if the R
x86/sev: Prevent RDTSC/RDTSCP interception for Secure TSC enabled guests
The hypervisor should not be intercepting RDTSC/RDTSCP when Secure TSC is enabled. A #VC exception will be generated if the RDTSC/RDTSCP instructions are being intercepted. If this should occur and Secure TSC is enabled, guest execution should be terminated as the guest cannot rely on the TSC value provided by the hypervisor.
Signed-off-by: Nikunj A Dadhania <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Tested-by: Peter Gonda <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| 38cc6495 | 06-Jan-2025 |
Nikunj A Dadhania <[email protected]> |
x86/sev: Prevent GUEST_TSC_FREQ MSR interception for Secure TSC enabled guests
The hypervisor should not be intercepting GUEST_TSC_FREQ MSR(0xcOO10134) when Secure TSC is enabled. A #VC exception wi
x86/sev: Prevent GUEST_TSC_FREQ MSR interception for Secure TSC enabled guests
The hypervisor should not be intercepting GUEST_TSC_FREQ MSR(0xcOO10134) when Secure TSC is enabled. A #VC exception will be generated otherwise. If this should occur and Secure TSC is enabled, terminate guest execution.
Signed-off-by: Nikunj A Dadhania <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| 0f0502b8 | 06-Jan-2025 |
Nikunj A Dadhania <[email protected]> |
x86/sev: Change TSC MSR behavior for Secure TSC enabled guests
Secure TSC enabled guests should not write to the MSR_IA32_TSC (0x10) register as the subsequent TSC value reads are undefined. On AMD,
x86/sev: Change TSC MSR behavior for Secure TSC enabled guests
Secure TSC enabled guests should not write to the MSR_IA32_TSC (0x10) register as the subsequent TSC value reads are undefined. On AMD, MSR_IA32_TSC is intercepted by the hypervisor by default. MSR_IA32_TSC read/write accesses should not exit to the hypervisor for such guests.
Accesses to MSR_IA32_TSC need special handling in the #VC handler for the guests with Secure TSC enabled. Writes to MSR_IA32_TSC should be ignored and flagged once with a warning, and reads of MSR_IA32_TSC should return the result of the RDTSC instruction.
[ bp: Massage commit message. ]
Suggested-by: Borislav Petkov (AMD) <[email protected]> Signed-off-by: Nikunj A Dadhania <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| 85b60ca9 | 06-Jan-2025 |
Nikunj A Dadhania <[email protected]> |
x86/sev: Add Secure TSC support for SNP guests
Add support for Secure TSC in SNP-enabled guests. Secure TSC allows guests to securely use RDTSC/RDTSCP instructions, ensuring that the parameters used
x86/sev: Add Secure TSC support for SNP guests
Add support for Secure TSC in SNP-enabled guests. Secure TSC allows guests to securely use RDTSC/RDTSCP instructions, ensuring that the parameters used cannot be altered by the hypervisor once the guest is launched.
Secure TSC-enabled guests need to query TSC information from the AMD Security Processor. This communication channel is encrypted between the AMD Security Processor and the guest, with the hypervisor acting merely as a conduit to deliver the guest messages to the AMD Security Processor. Each message is protected with AEAD (AES-256 GCM).
[ bp: Zap a stray newline over amd_cc_platform_has() while at it, simplify CC_ATTR_GUEST_SNP_SECURE_TSC check ]
Signed-off-by: Nikunj A Dadhania <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| 89393014 | 06-Jan-2025 |
Ard Biesheuvel <[email protected]> |
x86/sev: Don't hang but terminate on failure to remap SVSM CA
Commit
09d35045cd0f ("x86/sev: Avoid WARN()s and panic()s in early boot code")
replaced a panic() that could potentially hit before
x86/sev: Don't hang but terminate on failure to remap SVSM CA
Commit
09d35045cd0f ("x86/sev: Avoid WARN()s and panic()s in early boot code")
replaced a panic() that could potentially hit before the kernel is even mapped with a deadloop, to ensure that execution does not proceed when the condition in question hits.
As Tom suggests, it is better to terminate and return to the hypervisor in this case, using a newly invented failure code to describe the failure condition.
Suggested-by: Tom Lendacky <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| 1e0b23b5 | 06-Jan-2025 |
Nikunj A Dadhania <[email protected]> |
x86/sev: Relocate SNP guest messaging routines to common code
At present, the SEV guest driver exclusively handles SNP guest messaging. All routines for sending guest messages are embedded within it
x86/sev: Relocate SNP guest messaging routines to common code
At present, the SEV guest driver exclusively handles SNP guest messaging. All routines for sending guest messages are embedded within it.
To support Secure TSC, SEV-SNP guests must communicate with the AMD Security Processor during early boot. However, these guest messaging functions are not accessible during early boot since they are currently part of the guest driver.
Hence, relocate the core SNP guest messaging functions to SEV common code and provide an API for sending SNP guest messages.
No functional change, but just an export symbol added for snp_send_guest_request() and dropped the export symbol on snp_issue_guest_request() and made it static.
Signed-off-by: Nikunj A Dadhania <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| 3b6f99a9 | 05-Dec-2024 |
Ard Biesheuvel <[email protected]> |
x86/boot: Disable UBSAN in early boot code
The early boot code runs from a 1:1 mapping of memory, and may execute before the kernel virtual mapping is even up. This means absolute symbol references
x86/boot: Disable UBSAN in early boot code
The early boot code runs from a 1:1 mapping of memory, and may execute before the kernel virtual mapping is even up. This means absolute symbol references cannot be permitted in this code.
UBSAN injects references to global data structures into the code, and without -fPIC, those references are emitted as absolute references to kernel virtual addresses. Accessing those will fault before the kernel virtual mapping is up, so UBSAN needs to be disabled in early boot code.
Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| 7ae15e2f | 04-Nov-2024 |
Kirill A. Shutemov <[email protected]> |
x86/tdx: Enable CPU topology enumeration
TDX 1.0 defines baseline behaviour of TDX guest platform. TDX 1.0 generates a #VE when accessing topology-related CPUID leafs (0xB and 0x1F) and the X2APIC_A
x86/tdx: Enable CPU topology enumeration
TDX 1.0 defines baseline behaviour of TDX guest platform. TDX 1.0 generates a #VE when accessing topology-related CPUID leafs (0xB and 0x1F) and the X2APIC_APICID MSR. The kernel returns all zeros on CPUID topology. In practice, this means that the kernel can only boot with a plain topology. Any complications will cause problems.
The ENUM_TOPOLOGY feature allows the VMM to provide topology information to the guest. Enabling the feature eliminates topology-related #VEs: the TDX module virtualizes accesses to the CPUID leafs and the MSR.
Enable ENUM_TOPOLOGY if it is available.
Signed-off-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Acked-by: Kai Huang <[email protected]> Link: https://lore.kernel.org/all/20241104103803.195705-5-kirill.shutemov%40linux.intel.com
show more ...
|