blaster4385/linux-IllusionX/arch/x86/coco, branch v6.13

Merge tag 'x86_tdx_for_6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2024-11-22T21:07:19Z

Pull tdx updates from Dave Hansen: "These essentially refine some interactions between TDX guests and VMMs. The first leverages a new TDX module feature to runtime disable the ability for a VM to inject #VE exceptions. Before this feature, there was only a static on/off switch and the guest had to panic if it was configured in a bad state. The second lets the guest opt in to be able to access the topology CPUID leaves. Before this, accesses to those leaves would #VE. For both of these, it would have been nicest to just change the default behavior, but some pesky "other" OSes evidently need to retain the legacy behavior. Summary: - Add new infrastructure for reading TDX metadata - Use the newly-available metadata to: - Disable potentially nasty #VE exceptions - Get more complete CPU topology information from the VMM" * tag 'x86_tdx_for_6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/tdx: Enable CPU topology enumeration x86/tdx: Dynamically disable SEPT violations from causing #VEs x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup() x86/tdx: Introduce wrappers to read and write TD metadata

x86/tdx: Enable CPU topology enumeration

2024-11-07T18:27:45Z

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 Signed-off-by: Dave Hansen Acked-by: Kai Huang Link: https://lore.kernel.org/all/20241104103803.195705-5-kirill.shutemov%40linux.intel.com

x86/tdx: Dynamically disable SEPT violations from causing #VEs

2024-11-07T18:27:38Z

Memory access #VEs are hard for Linux to handle in contexts like the entry code or NMIs. But other OSes need them for functionality. There's a static (pre-guest-boot) way for a VMM to choose one or the other. But VMMs don't always know which OS they are booting, so they choose to deliver those #VEs so the "other" OSes will work. That, unfortunately has left us in the lurch and exposed to these hard-to-handle #VEs. The TDX module has introduced a new feature. Even if the static configuration is set to "send nasty #VEs", the kernel can dynamically request that they be disabled. Once they are disabled, access to private memory that is not in the Mapped state in the Secure-EPT (SEPT) will result in an exit to the VMM rather than injecting a #VE. Check if the feature is available and disable SEPT #VE if possible. If the TD is allowed to disable/enable SEPT #VEs, the ATTR_SEPT_VE_DISABLE attribute is no longer reliable. It reflects the initial state of the control for the TD, but it will not be updated if someone (e.g. bootloader) changes it before the kernel starts. Kernel must check TDCS_TD_CTLS bit to determine if SEPT #VEs are enabled or disabled. [ dhansen: remove 'return' at end of function ] Fixes: 373e715e31bf ("x86/tdx: Panic on bad configs that #VE on "private" memory access") Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Acked-by: Kai Huang Link: https://lore.kernel.org/all/20241104103803.195705-4-kirill.shutemov%40linux.intel.com

x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()

2024-11-07T18:26:37Z

Rename tdx_parse_tdinfo() to tdx_setup() and move setting NOTIFY_ENABLES there. The function will be extended to adjust TD configuration. Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Kai Huang Link: https://lore.kernel.org/all/20241104103803.195705-3-kirill.shutemov%40linux.intel.com

x86/tdx: Introduce wrappers to read and write TD metadata

2024-11-07T18:26:16Z

The TDG_VM_WR TDCALL is used to ask the TDX module to change some TD-specific VM configuration. There is currently only one user in the kernel of this TDCALL leaf. More will be added shortly. Refactor to make way for more users of TDG_VM_WR who will need to modify other TD configuration values. Add a wrapper for the TDG_VM_RD TDCALL that requests TD-specific metadata from the TDX module. There are currently no users for TDG_VM_RD. Mark it as __maybe_unused until the first user appears. This is preparation for enumeration and enabling optional TD features. Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Kai Huang Reviewed-by: Kuppuswamy Sathyanarayanan Link: https://lore.kernel.org/all/20241104103803.195705-2-kirill.shutemov%40linux.intel.com

x86/sev: Cleanup vc_handle_msr()

2024-11-07T11:10:01Z

Carve out the MSR_SVSM_CAA into a helper with the suggestion that upcoming future users should do the same. Rename that silly exit_info_1 into what it actually means in this function - whether the MSR access is a read or a write. No functional changes. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Reviewed-by: Pankaj Gupta Link: https://lore.kernel.org/r/20241106172647.GAZyum1zngPDwyD2IJ@fat_crate.local

x86/sev: Convert shared memory back to private on kexec

2024-10-28T17:06:54Z

SNP guests allocate shared buffers to perform I/O. It is done by allocating pages normally from the buddy allocator and converting them to shared with set_memory_decrypted(). The second, kexec-ed, kernel has no idea what memory is converted this way. It only sees E820_TYPE_RAM. Accessing shared memory via private mapping will cause unrecoverable RMP page-faults. On kexec, walk direct mapping and convert all shared memory back to private. It makes all RAM private again and second kernel may use it normally. Additionally, for SNP guests, convert all bss decrypted section pages back to private. The conversion occurs in two steps: stopping new conversions and unsharing all memory. In the case of normal kexec, the stopping of conversions takes place while scheduling is still functioning. This allows for waiting until any ongoing conversions are finished. The second step is carried out when all CPUs except one are inactive and interrupts are disabled. This prevents any conflicts with code that may access shared memory. Co-developed-by: Borislav Petkov (AMD) Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ashish Kalra Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/05a8c15fb665dbb062b04a8cb3d592a63f235937.1722520012.git.ashish.kalra@amd.com

virt: sev-guest: Consolidate SNP guest messaging parameters to a struct

2024-10-16T16:30:40Z

Add a snp_guest_req structure to eliminate the need to pass a long list of parameters. This structure will be used to call the SNP Guest message request API, simplifying the function arguments. Update the snp_issue_guest_request() prototype to include the new guest request structure. Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20241009092850.197575-5-nikunj@amd.com

x86/sev: Cache the secrets page address

2024-10-16T16:24:51Z

Instead of calling get_secrets_page(), which parses the CC blob every time to get the secrets page physical address (secrets_pa), save the secrets page physical address during snp_init() from the CC blob. Since get_secrets_page() is no longer used, remove the function. Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20241009092850.197575-4-nikunj@amd.com

x86/virt: Move SEV-specific parsing into arch/x86/virt/svm

2024-10-15T17:54:42Z

Move SEV-specific kernel command line option parsing support from arch/x86/coco/sev/core.c to arch/x86/virt/svm/cmdline.c so that both host and guest related SEV command line options can be supported. No functional changes intended. Signed-off-by: Pavan Kumar Paluri Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20241014130948.1476946-2-papaluri@amd.com