kernel.git/arch/x86/kernel/cpu/sgx/main.c, branch master

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00Z

This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

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

2025-12-02T22:16:42Z

Pull misc x86 updates from Dave Hansen: "The most significant are some changes to ensure that symbols exported for KVM are used only by KVM modules themselves, along with some related cleanups. In true x86/misc fashion, the other patch is completely unrelated and just enhances an existing pr_warn() to make it clear to users how they have tainted their kernel when something is mucking with MSRs. Summary: - Make MSR-induced taint easier for users to track down - Restrict KVM-specific exports to KVM itself" * tag 'x86_misc_for_6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86: Restrict KVM-induced symbol exports to KVM modules where obvious/possible x86/mm: Drop unnecessary export of "ptdump_walk_pgd_level_debugfs" x86/mtrr: Drop unnecessary export of "mtrr_state" x86/bugs: Drop unnecessary export of "x86_spec_ctrl_base" x86/msr: Add CPU_OUT_OF_SPEC taint name to "unrecognized" pr_warn(msg)

x86: Restrict KVM-induced symbol exports to KVM modules where obvious/possible

2025-11-12T23:29:38Z

Extend KVM's export macro framework to provide EXPORT_SYMBOL_FOR_KVM(), and use the helper macro to export symbols for KVM throughout x86 if and only if KVM will build one or more modules, and only for those modules. To avoid unnecessary exports when CONFIG_KVM=m but kvm.ko will not be built (because no vendor modules are selected), let arch code #define EXPORT_SYMBOL_FOR_KVM to suppress/override the exports. Note, the set of symbols to restrict to KVM was generated by manual search and audit; any "misses" are due to human error, not some grand plan. Signed-off-by: Sean Christopherson Signed-off-by: Dave Hansen Acked-by: Kai Huang Tested-by: Kai Huang Link: https://patch.msgid.link/20251112173944.1380633-5-seanjc%40google.com

x86/sgx: Enable automatic SVN updates for SGX enclaves

2025-10-16T21:42:09Z

== Background == ENCLS[EUPDATESVN] is a new SGX instruction [1] which allows enclave attestation to include information about updated microcode SVN without a reboot. Before an EUPDATESVN operation can be successful, all SGX memory (aka. EPC) must be marked as “unused” in the SGX hardware metadata (aka.EPCM). This requirement ensures that no compromised enclave can survive the EUPDATESVN procedure and provides an opportunity to generate new cryptographic assets. == Solution == Attempt to execute ENCLS[EUPDATESVN] every time the first file descriptor is obtained via sgx_(vepc_)open(). In the most common case the microcode SVN is already up-to-date, and the operation succeeds without updating SVN. Note: while in such cases the underlying crypto assets are regenerated, it does not affect enclaves' visible keys obtained via EGETKEY instruction. If it fails with any other error code than SGX_INSUFFICIENT_ENTROPY, this is considered unexpected and the *open() returns an error. This should not happen in practice. On contrary, SGX_INSUFFICIENT_ENTROPY might happen due to a pressure on the system's DRNG (RDSEED) and therefore the *open() can be safely retried to allow normal enclave operation. [1] Runtime Microcode Updates with Intel Software Guard Extensions, https://cdrdv2.intel.com/v1/dl/getContent/648682 Signed-off-by: Elena Reshetova Signed-off-by: Dave Hansen Reviewed-by: Kai Huang Reviewed-by: Jarkko Sakkinen Tested-by: Nataliia Bondarevska

x86/sgx: Implement ENCLS[EUPDATESVN]

2025-10-16T21:42:09Z

All running enclaves and cryptographic assets (such as internal SGX encryption keys) are assumed to be compromised whenever an SGX-related microcode update occurs. To mitigate this assumed compromise the new supervisor SGX instruction ENCLS[EUPDATESVN] can generate fresh cryptographic assets. Before executing EUPDATESVN, all SGX memory must be marked as unused. This requirement ensures that no potentially compromised enclave survives the update and allows the system to safely regenerate cryptographic assets. Add the method to perform ENCLS[EUPDATESVN]. However, until the follow up patch that wires calling sgx_update_svn() from sgx_inc_usage_count(), this code is not reachable. Signed-off-by: Elena Reshetova Signed-off-by: Dave Hansen Reviewed-by: Kai Huang Reviewed-by: Jarkko Sakkinen Tested-by: Nataliia Bondarevska

x86/sgx: Introduce functions to count the sgx_(vepc_)open()

2025-10-16T21:42:08Z

Currently, when SGX is compromised and the microcode update fix is applied, the machine needs to be rebooted to invalidate old SGX crypto-assets and make SGX be in an updated safe state. It's not friendly for the cloud. To avoid having to reboot, a new ENCLS[EUPDATESVN] is introduced to update SGX environment at runtime. This process needs to be done when there's no SGX users to make sure no compromised enclaves can survive from the update and allow the system to regenerate crypto-assets. For now there's no counter to track the active SGX users of host enclave and virtual EPC. Introduce such counter mechanism so that the EUPDATESVN can be done only when there's no SGX users. Define placeholder functions sgx_inc/dec_usage_count() that are used to increment and decrement such a counter. Also, wire the call sites for these functions. Encapsulate the current sgx_(vepc_)open() to __sgx_(vepc_)open() to make the new sgx_(vepc_)open() easy to read. The definition of the counter itself and the actual implementation of sgx_inc/dec_usage_count() functions come next. Note: The EUPDATESVN, which may fail, will be done in sgx_inc_usage_count(). Make it return 'int' to make subsequent patches which implement EUPDATESVN easier to review. For now it always returns success. Suggested-by: Sean Christopherson Signed-off-by: Elena Reshetova Signed-off-by: Dave Hansen Reviewed-by: Kai Huang Reviewed-by: Jarkko Sakkinen Tested-by: Nataliia Bondarevska

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

2025-05-30T04:13:17Z

Pull Intel software guard extension (SGX) updates from Dave Hansen: "A couple of x86/sgx changes. The first one is a no-brainer to use the (simple) SHA-256 library. For the second one, some folks doing testing noticed that SGX systems under memory pressure were inducing fatal machine checks at pretty unnerving rates, despite the SGX code having _some_ awareness of memory poison. It turns out that the SGX reclaim path was not checking for poison _and_ it always accesses memory to copy it around. Make sure that poisoned pages are not reclaimed" * tag 'x86_sgx_for_6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sgx: Prevent attempts to reclaim poisoned pages x86/sgx: Use SHA-256 library API instead of crypto_shash API

x86/sgx: Prevent attempts to reclaim poisoned pages

2025-05-15T17:01:45Z

TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a "TBD" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply. This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment. Signed-off-by: Andrew Zaborowski Signed-off-by: Ingo Molnar Acked-by: Dave Hansen Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Tony Luck Cc: balrogg@gmail.com Cc: linux-sgx@vger.kernel.org Link: https://lore.kernel.org/r/20250508230429.456271-1-andrew.zaborowski@intel.com

x86/msr: Add explicit includes of

2025-05-02T08:23:47Z

For historic reasons there are some TSC-related functions in the header, even though there's an header. To facilitate the relocation of rdtsc{,_ordered}() from to and to eventually eliminate the inclusion of in , add an explicit dependency to the source files that reference definitions from . [ mingo: Clarified the changelog. ] Signed-off-by: Xin Li (Intel) Signed-off-by: Ingo Molnar Acked-by: Dave Hansen Acked-by: Peter Zijlstra (Intel) Acked-by: Ilpo Järvinen Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Kees Cook Cc: Peter Zijlstra Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Josh Poimboeuf Cc: Uros Bizjak Link: https://lore.kernel.org/r/20250501054241.1245648-1-xin@zytor.com