kernel.git/arch/x86/kernel/cpu/microcode/amd.c, branch linux-6.4.y

x86/microcode/AMD: Load late on both threads too

2023-07-01T11:12:37Z

commit a32b0f0db3f396f1c9be2fe621e77c09ec3d8e7d upstream. Do the same as early loading - load on both threads. Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://lore.kernel.org/r/20230605141332.25948-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman

docs: move x86 documentation into Documentation/arch/

2023-03-30T18:58:51Z

Move the x86 documentation under Documentation/arch/ as a way of cleaning up the top-level directory and making the structure of our docs more closely match the structure of the source directories it describes. All in-kernel references to the old paths have been updated. Acked-by: Dave Hansen Cc: linux-arch@vger.kernel.org Cc: x86@kernel.org Cc: Borislav Petkov Cc: Thomas Gleixner Link: https://lore.kernel.org/lkml/20230315211523.108836-1-corbet@lwn.net/ Signed-off-by: Jonathan Corbet

x86/microcode/AMD: Fix mixed steppings support

2023-02-06T12:40:16Z

The AMD side of the loader has always claimed to support mixed steppings. But somewhere along the way, it broke that by assuming that the cached patch blob is a single one instead of it being one per *node*. So turn it into a per-node one so that each node can stash the blob relevant for it. [ NB: Fixes tag is not really the exactly correct one but it is good enough. ] Fixes: fe055896c040 ("x86/microcode: Merge the early microcode loader") Signed-off-by: Borislav Petkov (AMD) Cc: # 2355370cd941 ("x86/microcode/amd: Remove load_microcode_amd()'s bsp parameter") Cc: # a5ad92134bd1 ("x86/microcode/AMD: Add a @cpu parameter to the reloading functions") Link: https://lore.kernel.org/r/20230130161709.11615-4-bp@alien8.de

x86/microcode/AMD: Add a @cpu parameter to the reloading functions

2023-02-06T11:14:20Z

Will be used in a subsequent change. Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230130161709.11615-3-bp@alien8.de

x86/microcode/amd: Remove load_microcode_amd()'s bsp parameter

2023-02-06T10:13:04Z

It is always the BSP. No functional changes. Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230130161709.11615-2-bp@alien8.de

x86/microcode/AMD: Handle multiple glued containers properly

2022-12-26T05:41:05Z

It can happen that - especially during testing - the microcode blobs of all families are all glued together in the initrd. The current code doesn't check whether the current container matched a microcode patch and continues to the next one, which leads to save_microcode_in_initrd_amd() to look at the next and thus wrong one: microcode: parse_container: ucode: 0xffff88807e9d9082 microcode: verify_patch: buf: 0xffff88807e9d90ce, buf_size: 26428 microcode: verify_patch: proc_id: 0x8082, patch_fam: 0x17, this family: 0x17 microcode: verify_patch: buf: 0xffff88807e9d9d56, buf_size: 23220 microcode: verify_patch: proc_id: 0x8012, patch_fam: 0x17, this family: 0x17 microcode: parse_container: MATCH: eq_id: 0x8012, patch proc_rev_id: 0x8012 <-- matching patch found microcode: verify_patch: buf: 0xffff88807e9da9de, buf_size: 20012 microcode: verify_patch: proc_id: 0x8310, patch_fam: 0x17, this family: 0x17 microcode: verify_patch: buf: 0xffff88807e9db666, buf_size: 16804 microcode: Invalid type field (0x414d44) in container file section header. microcode: Patch section fail <-- checking chokes on the microcode magic value of the next container. microcode: parse_container: saving container 0xffff88807e9d9082 microcode: save_microcode_in_initrd_amd: scanned containers, data: 0xffff88807e9d9082, size: 9700a and now if there's a next (and last container) it'll use that in save_microcode_in_initrd_amd() and not find a proper patch, ofc. Fix that by moving the out: label up, before the desc->mc check which jots down the pointer of the matching patch and is used to signal to the caller that it has found a matching patch in the current container. Signed-off-by: Borislav Petkov Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20221219210656.5140-2-bp@alien8.de

x86/microcode/AMD: Rename a couple of functions

2022-12-26T05:30:31Z

- Rename apply_microcode_early_amd() to early_apply_microcode(): simplify the name so that it is clear what it does and when does it do it. - Rename __load_ucode_amd() to find_blobs_in_containers(): the new name actually explains what it does. Document some. No functional changes. Signed-off-by: Borislav Petkov Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20221219210656.5140-1-bp@alien8.de

Merge tag 'x86_microcode_for_v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2022-12-13T23:05:29Z

Pull x86 microcode and IFS updates from Borislav Petkov: "The IFS (In-Field Scan) stuff goes through tip because the IFS driver uses the same structures and similar functionality as the microcode loader and it made sense to route it all through this branch so that there are no conflicts. - Add support for multiple testing sequences to the Intel In-Field Scan driver in order to be able to run multiple different test patterns. Rework things and remove the BROKEN dependency so that the driver can be enabled (Jithu Joseph) - Remove the subsys interface usage in the microcode loader because it is not really needed - A couple of smaller fixes and cleanups" * tag 'x86_microcode_for_v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits) x86/microcode/intel: Do not retry microcode reloading on the APs x86/microcode/intel: Do not print microcode revision and processor flags platform/x86/intel/ifs: Add missing kernel-doc entry Revert "platform/x86/intel/ifs: Mark as BROKEN" Documentation/ABI: Update IFS ABI doc platform/x86/intel/ifs: Add current_batch sysfs entry platform/x86/intel/ifs: Remove reload sysfs entry platform/x86/intel/ifs: Add metadata validation platform/x86/intel/ifs: Use generic microcode headers and functions platform/x86/intel/ifs: Add metadata support x86/microcode/intel: Use a reserved field for metasize x86/microcode/intel: Add hdr_type to intel_microcode_sanity_check() x86/microcode/intel: Reuse microcode_sanity_check() x86/microcode/intel: Use appropriate type in microcode_sanity_check() x86/microcode/intel: Reuse find_matching_signature() platform/x86/intel/ifs: Remove memory allocation from load path platform/x86/intel/ifs: Remove image loading during init platform/x86/intel/ifs: Return a more appropriate error code platform/x86/intel/ifs: Remove unused selection x86/microcode: Drop struct ucode_cpu_info.valid ...

x86/microcode: Kill refresh_fw

2022-11-02T15:45:46Z

request_microcode_fw() can always request firmware now so drop this superfluous argument. Signed-off-by: Borislav Petkov Reviewed-by: Ashok Raj Link: https://lore.kernel.org/r/20221028142638.28498-4-bp@alien8.de

x86/microcode/AMD: Apply the patch early on every logical thread

2022-10-18T09:03:27Z

Currently, the patch application logic checks whether the revision needs to be applied on each logical CPU (SMT thread). Therefore, on SMT designs where the microcode engine is shared between the two threads, the application happens only on one of them as that is enough to update the shared microcode engine. However, there are microcode patches which do per-thread modification, see Link tag below. Therefore, drop the revision check and try applying on each thread. This is what the BIOS does too so this method is very much tested. Btw, change only the early paths. On the late loading paths, there's no point in doing per-thread modification because if is it some case like in the bugzilla below - removing a CPUID flag - the kernel cannot go and un-use features it has detected are there early. For that, one should use early loading anyway. [ bp: Fixes does not contain the oldest commit which did check for equality but that is good enough. ] Fixes: 8801b3fcb574 ("x86/microcode/AMD: Rework container parsing") Reported-by: Ștefan Talpalaru Signed-off-by: Borislav Petkov Tested-by: Ștefan Talpalaru Cc: Link: https://bugzilla.kernel.org/show_bug.cgi?id=216211