summaryrefslogtreecommitdiff
path: root/arch/x86/kernel/cpu/microcode/amd.c
AgeCommit message (Collapse)Author
2019-01-31x86/microcode/amd: Don't falsely trick the late loading mechanismThomas Lendacky
The load_microcode_amd() function searches for microcode patches and attempts to apply a microcode patch if it is of different level than the currently installed level. While the processor won't actually load a level that is less than what is already installed, the logic wrongly returns UCODE_NEW thus signaling to its caller reload_store() that a late loading should be attempted. If the file-system contains an older microcode revision than what is currently running, such a late microcode reload can result in these misleading messages: x86/CPU: CPU features have changed after loading microcode, but might not take effect. x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update. These messages were issued on a system where SME/SEV are not enabled by the BIOS (MSR C001_0010[23] = 0b) because during boot, early_detect_mem_encrypt() is called and cleared the SME and SEV features in this case. However, after the wrong late load attempt, get_cpu_cap() is called and reloads the SME and SEV feature bits, resulting in the messages. Update the microcode level check to not attempt microcode loading if the current level is greater than(!) and not only equal to the current patch level. [ bp: massage commit message. ] Fixes: 2613f36ed965 ("x86/microcode: Attempt late loading only when new microcode is present") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/154894518427.9406.8246222496874202773.stgit@tlendack-t1.amdoffice.net
2018-11-19x86/microcode/AMD: Update copyrightBorislav Petkov
Adjust copyright. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-17-bp@alien8.de
2018-11-19x86/microcode/AMD: Check the equivalence table size when scanning itMaciej S. Szmigiero
Currently, the code scanning the CPU equivalence table read from a microcode container file assumes that it actually contains a terminating zero entry. Check also the size of this table to make sure that no reads past its end happen, in case there's no terminating zero entry at the end of the table. [ bp: Adjust to new changes. ] Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-16-bp@alien8.de
2018-11-19x86/microcode/AMD: Convert CPU equivalence table variable into a structMaciej S. Szmigiero
Convert the CPU equivalence table into a proper struct in preparation for tracking also the size of this table. [ bp: Have functions deal with struct equiv_cpu_table pointers only. Rediff. ] Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-15-bp@alien8.de
2018-11-19x86/microcode/AMD: Check microcode container data in the late loaderMaciej S. Szmigiero
Convert the late loading path to use the newly introduced microcode container data checking functions as it was previously done for the early loader. [ bp: Keep header length addition in install_equiv_cpu_table() and rediff. ] Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-14-bp@alien8.de
2018-11-19x86/microcode/AMD: Fix container size's typeBorislav Petkov
Make it size_t everywhere as this is what we get from cpio. [ bp: Fix a smatch warning. ] Originally-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20181107170218.7596-13-bp@alien8.de
2018-11-19x86/microcode/AMD: Convert early parser to the new verification routinesBorislav Petkov
Now that they have the required functionality, use them to verify the equivalence table and each patch, thus making parse_container() more readable. Originally-by: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-12-bp@alien8.de
2018-11-19x86/microcode/AMD: Change verify_patch()'s return valueBorislav Petkov
Have it return 0 on success, positive value when the current patch should be skipped and negative on error. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-11-bp@alien8.de
2018-11-19x86/microcode/AMD: Move chipset-specific check into verify_patch()Borislav Petkov
... where it belongs. No functional changes. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org https://lkml.kernel.org/r/20181107170218.7596-10-bp@alien8.de
2018-11-19x86/microcode/AMD: Move patch family check to verify_patch()Borislav Petkov
... where all the microcode patch verification is being concentrated. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-9-bp@alien8.de
2018-11-19x86/microcode/AMD: Simplify patch family detectionBorislav Petkov
Instead of traversing the equivalence table, compute the family a patch is for, from the processor revision ID in the microcode header. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-8-bp@alien8.de
2018-11-19x86/microcode/AMD: Concentrate patch verificationBorislav Petkov
Add a verify_patch() function which tries to sanity-check many aspects of a microcode patch supplied by an outside container before attempting a load. Prepend all sub-functions' names which verify an aspect of a microcode patch with "__". Call it in verify_and_add_patch() *before* looking at the microcode header. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-7-bp@alien8.de
2018-11-19x86/microcode/AMD: Cleanup verify_patch_size() moreBorislav Petkov
Rename the variable which contains the patch size read out from the section header to sh_psize for better differentiation of all the "sizes" in that function. Also, improve the comment above it. No functional changes. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-6-bp@alien8.de
2018-11-19x86/microcode/AMD: Clean up per-family patch size checksBorislav Petkov
Starting with family 0x15, the patch size verification is not needed anymore. Thus get rid of the need to update this checking function with each new family. Keep the check for older families. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-5-bp@alien8.de
2018-11-19x86/microcode/AMD: Move verify_patch_size() up in the fileBorislav Petkov
... to enable later improvements. No functional changes. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20181107170218.7596-4-bp@alien8.de
2018-11-19x86/microcode/AMD: Add microcode container verificationMaciej S. Szmigiero
Add container and patch verification functions to the AMD microcode update driver. These functions check whether a passed buffer contains the relevant structure, whether it isn't truncated and (for actual microcode patches) whether the size of a patch is not too large for a particular CPU family. By adding these checks as separate functions the actual microcode loading code won't get interspersed with a lot of checks and so will be more readable. [ bp: Make all pr_err() calls into pr_debug() and drop the verify_patch() bits. ] Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/3014e96c82cd90761b4601bd2cfe59c4119e46a7.1529424596.git.mail@maciej.szmigiero.name
2018-11-19x86/microcode/AMD: Subtract SECTION_HDR_SIZE from file leftover lengthMaciej S. Szmigiero
verify_patch_size() verifies whether the remaining size of the microcode container file is large enough to contain a patch of the indicated size. However, the section header length is not included in this indicated size but it is present in the leftover file length so it should be subtracted from the leftover file length before passing this value to verify_patch_size(). [ bp: Split comment. ] Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/6df43f4f6a28186a13a66e8d7e61143c5e1a2324.1529424596.git.mail@maciej.szmigiero.name
2018-09-02x86/microcode: Update the new microcode revision unconditionallyFilippo Sironi
Handle the case where microcode gets loaded on the BSP's hyperthread sibling first and the boot_cpu_data's microcode revision doesn't get updated because of early exit due to the siblings sharing a microcode engine. For that, simply write the updated revision on all CPUs unconditionally. Signed-off-by: Filippo Sironi <sironi@amazon.de> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: prarit@redhat.com Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1533050970-14385-1-git-send-email-sironi@amazon.de
2018-09-02x86/microcode: Make sure boot_cpu_data.microcode is up-to-datePrarit Bhargava
When preparing an MCE record for logging, boot_cpu_data.microcode is used to read out the microcode revision on the box. However, on systems where late microcode update has happened, the microcode revision output in a MCE log record is wrong because boot_cpu_data.microcode is not updated when the microcode gets updated. But, the microcode revision saved in boot_cpu_data's microcode member should be kept up-to-date, regardless, for consistency. Make it so. Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check records") Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: sironi@amazon.de Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20180731112739.32338-1-prarit@redhat.com
2018-03-27Documentation: Fix early-microcode.txt references after file renameJaak Ristioja
The file Documentation/x86/early-microcode.txt was renamed to Documentation/x86/microcode.txt in 0e3258753f81, but it was still referenced by its old name in a three places: * Documentation/x86/00-INDEX * arch/x86/Kconfig * arch/x86/kernel/cpu/microcode/amd.c This commit updates these references accordingly. Fixes: 0e3258753f81 ("x86/microcode: Document the three loading methods") Signed-off-by: Jaak Ristioja <jaak@ristioja.ee> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2018-03-16x86/microcode: Attempt late loading only when new microcode is presentBorislav Petkov
Return UCODE_NEW from the scanning functions to denote that new microcode was found and only then attempt the expensive synchronization dance. Reported-by: Emanuel Czirai <xftroxgpx@protonmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Emanuel Czirai <xftroxgpx@protonmail.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lkml.kernel.org/r/20180314183615.17629-1-bp@alien8.de
2018-02-17x86/microcode: Propagate return value from updating functionsBorislav Petkov
... so that callers can know when microcode was updated and act accordingly. Tested-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20180216112640.11554-2-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-06x86/microcode/AMD: Add support for fam17h microcode loadingTom Lendacky
The size for the Microcode Patch Block (MPB) for an AMD family 17h processor is 3200 bytes. Add a #define for fam17h so that it does not default to 2048 bytes and fail a microcode load/update. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@alien8.de> Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdoffice.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25x86/microcode/AMD: Free unneeded patch before exit from update_cache()Shu Wang
verify_and_add_patch() allocates memory for a microcode patch and hands it down to be added to the cache of patches. However, if the cache already has the latest patch, the newly allocated one needs to be freed before returning. Do that. This issue has been found by kmemleak: unreferenced object 0xffff88010e780b40 (size 32): comm "bash", pid 860, jiffies 4294690939 (age 29.297s) backtrace: kmemleak_alloc kmem_cache_alloc_trace load_microcode_amd.isra.0 request_microcode_amd reload_store dev_attr_store sysfs_kf_write kernfs_fop_write __vfs_write vfs_write SyS_write do_syscall_64 return_from_SYSCALL_64 0xffffffffffffffff (gdb) list *0xffffffff81050d60 0xffffffff81050d60 is in load_microcode_amd (arch/x86/kernel/cpu/microcode/amd.c:616). which is this: patch = kzalloc(sizeof(*patch), GFP_KERNEL); --> if (!patch) { pr_err("Patch allocation failure.\n"); return -EINVAL; } Signed-off-by: Shu Wang <shuwang@redhat.com> [ Rewrite commit message. ] Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: chuhu@redhat.com Cc: liwang@redhat.com Link: http://lkml.kernel.org/r/20170724101228.17326-2-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-26x86/microcode: Make a couple of symbols staticColin Ian King
The helper function __load_ucode_amd() and pointer intel_ucode_patch do not need to be in global scope, so make them static. Fixes those sparse warnings: "symbol '__load_ucode_amd' was not declared. Should it be static?" "symbol 'intel_ucode_patch' was not declared. Should it be static?" Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170622095736.11937-1-colin.king@canonical.com
2017-05-29x86/microcode/AMD: Change load_microcode_amd()'s param to bool to fix ↵Borislav Petkov
preemptibility bug With CONFIG_DEBUG_PREEMPT enabled, I get: BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 caller is debug_smp_processor_id CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2 Call Trace: dump_stack check_preemption_disabled debug_smp_processor_id save_microcode_in_initrd_amd ? microcode_init save_microcode_in_initrd ... because, well, it says it above, we're using smp_processor_id() in preemptible code. But passing the CPU number is not really needed. It is only used to determine whether we're on the BSP, and, if so, to save the microcode patch for early loading. [ We don't absolutely need to do it on the BSP but we do that customarily there. ] Instead, convert that function parameter to a boolean which denotes whether the patch should be saved or not, thereby avoiding the use of smp_processor_id() in preemptible code. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170528200414.31305-1-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-12Tigran has movedAndrew Morton
Cc: Tigran Aivazian <aivazian.tigran@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-03-18x86/microcode/AMD: Remove redundant NULL check on mcColin Ian King
mc is a pointer to the static u8 array amd_ucode_patch and therefore can never be null, so the check is redundant. Remove it. Detected by CoverityScan, CID#1372871 ("Logically Dead Code") Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: kernel-janitors@vger.kernel.org Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/20170315171010.17536-1-colin.king@canonical.com Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Remove struct cont_desc.eq_idBorislav Petkov
The equivalence ID was needed outside of the container scanning logic but now, after this has been cleaned up, not anymore. Now, cont_desc.mc is used to denote whether the container we're looking at has the proper microcode patch for this CPU or not. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20170120202955.4091-17-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Remove AP scanning optimizationBorislav Petkov
The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Simplify saving from initrdBorislav Petkov
No need to use the previously stashed info in the container - simply go ahead and parse the initrd once more. It simplifies and streamlines the code a whole lot. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-15-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Unify load_ucode_amd_ap()Borislav Petkov
Use a version for both bitness by adding a helper which does the actual container finding and parsing which can be used on any CPU - BSP or AP. Streamlines the paths more. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20170120202955.4091-14-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Check patch level only on the BSPBorislav Petkov
Check final patch levels for AMD only on the BSP. This way, we decide early and only once whether to continue loading or to leave the loader disabled on such systems. Simplify a lot. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20170120202955.4091-13-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Use find_microcode_in_initrd()Borislav Petkov
Use the generic helper instead of semi-open-coding the procedure. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-11-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Get rid of global this_equiv_idBorislav Petkov
We have a container which we update/prepare each time before applying a microcode patch instead of using a global. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-10-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode: Decrease CPUID useBorislav Petkov
Get CPUID(1).EAX value once per CPU and propagate value into the callers instead of conveniently calling it every time. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-9-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Rework container parsingBorislav Petkov
It was pretty clumsy before and the whole work of parsing the microcode containers was spread around the functions wrongly. Clean it up so that there's a main scan_containers() function which iterates over the microcode blob and picks apart the containers glued together. For each container, it calls a parse_container() helper which concentrates on one container only: sanity-checking, parsing, counting microcode patches in there, etc. It makes much more sense now and it is actually very readable. Oh, and we luvz a diffstat removing more crap than adding. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20170120202955.4091-8-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Extend the container structBorislav Petkov
Make it into a container descriptor which is being passed around and stores important info like the matching container and the patch for the current CPU. Make it static too. Later patches will use this and thus get rid of a double container parsing. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-7-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Shorten function parameter's nameBorislav Petkov
The whole driver calls this "mc", do that here too. No functionality change. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-6-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-23x86/microcode/AMD: Clean up find_equiv_id()Borislav Petkov
No need to have it marked "inline" - let gcc decide. Also, shorten the argument name and simplify while-test. While at it, make it into a proper for-loop and simplify it even more, as tglx suggests. No functionality change. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20170120202955.4091-5-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-12-19x86/microcode/AMD: Use native_cpuid() in load_ucode_amd_bsp()Boris Ostrovsky
When CONFIG_PARAVIRT is selected, cpuid() becomes a call. Since for 32-bit kernels load_ucode_amd_bsp() is executed before paging is enabled the call cannot be completed (as kernel virtual addresses are not reachable yet). Use native_cpuid() instead which is an asm wrapper for the CPUID instruction. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Jürgen Gross <jgross@suse.com> Link: http://lkml.kernel.org/r/1481906392-3847-1-git-send-email-boris.ostrovsky@oracle.com Link: http://lkml.kernel.org/r/20161218164414.9649-5-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-12-19x86/microcode/AMD: Sanitize apply_microcode_early_amd()Borislav Petkov
Make it simply return bool to denote whether it found a container or not and return the pointer to the container and its size in the handed-in container pointer instead, as returning a struct was just silly. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Jürgen Gross <jgross@suse.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: http://lkml.kernel.org/r/20161218164414.9649-3-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-12-19x86/microcode/AMD: Make find_proper_container() sane againBorislav Petkov
Fixup signature and retvals, return the container struct through the passed in pointer, not as a function return value. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Jürgen Gross <jgross@suse.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: http://lkml.kernel.org/r/20161218164414.9649-2-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-10-25x86/microcode: Bump driver version, update copyrightsBorislav Petkov
Let's increment that number finally: it is long overdue. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-13-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25x86/microcode: Rework microcode loadingBorislav Petkov
Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25x86/microcode/amd: Move private inlines to .c and mark local functions staticBorislav Petkov
Make them all static as they're used in a single file now. No functionality change. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-10-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25x86/microcode/amd: Hand down the CPU familyBorislav Petkov
Will be needed in a following patch. No functionality change. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-7-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25x86/microcode: Export the microcode cache linked listBorislav Petkov
It will be used by both drivers so move it to core.c. No functionality change. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-6-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25x86/microcode: Run the AP-loading routine only on the application processorsBorislav Petkov
cpu_init() is run also on the BSP (in addition to the APs): x86_64_start_kernel |-> x86_64_start_reservations |-> start_kernel |-> trap_init |-> cpu_init |-> load_ucode_ap ... but we run the AP (Application Processors) microcode loading routine there too even though we have a BSP-specific routine for that: load_ucode_bsp(). Which is unnecessary. So let's limit the AP microcode loading routine to the APs only. Remove a useless comment while at it. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-2-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-05x86/microcode/AMD: Fix load of builtin microcode with randomized memoryBorislav Petkov
We do not need to add the randomization offset when the microcode is built in. Reported-and-tested-by: Emanuel Czirai <icanrealizeum@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20160904093736.GA11939@pd.tnic Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-31 11:55:55 +0000