Changes in Makefile

909639aa - x86/cpufeatures: Rename X86_CMPXCHG64 to X86_CX8

Fri, 28 Feb 2025 08:23:34 +0000

x86/cpufeatures: Rename X86_CMPXCHG64 to X86_CX8Replace X86_CMPXCHG64 with X86_CX8, as CX8 is the name of the CPUIDflag, thus to make it consistent with X86_FEATURE_CX8 defined in.No functional change intended.Signed-off-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li (Intel) Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ingo Molnar Link: https://lore.kernel.org/r/20250228082338.73859-2-xin@zytor.com List of files: /linux-6.15/arch/x86/lib/Makefile

b815f687 - x86/bhi: Add BHI stubs

Mon, 24 Feb 2025 12:37:11 +0000

x86/bhi: Add BHI stubsAdd an array of code thunks, to be called from the FineIBT preamble,clobbering the first 'n' argument registers for speculative execution.Notably the 0th entry will clobber no argument registers and will neverbe used, it exists so the array can be naturally indexed, while the 7thentry will clobber all the 6 argument registers and also RSP in order tomess up stack based arguments.Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20250224124200.717378681@infradead.org List of files: /linux-6.15/arch/x86/lib/Makefile

4ffd5086 - x86/crc64: implement crc64_be and crc64_nvme using new template

Mon, 10 Feb 2025 17:26:45 +0000

x86/crc64: implement crc64_be and crc64_nvme using new templateAdd x86_64 [V]PCLMULQDQ optimized implementations of crc64_be() andcrc64_nvme() by wiring them up to crc-pclmul-template.S.crc64_be() is used by bcache and bcachefs, and crc64_nvme() is used byblk-integrity. Both features can CRC large amounts of data, and thedevelopers of both features have expressed interest in having these CRCsbe optimized. So this optimization should be worthwhile. (Seehttps://lore.kernel.org/r/v36sousjd5ukqlkpdxslvpu7l37zbu7d7slgc2trjjqwty2bny@qgzew34feo2randhttps://lore.kernel.org/r/20220222163144.1782447-11-kbusch@kernel.org)Benchmark results on AMD Ryzen 9 9950X (Zen 5) using crc_kunit:crc64_be: Length Before After ------ ------ ----- 1 633 MB/s 477 MB/s 16 717 MB/s 2517 MB/s 64 715 MB/s 7525 MB/s 127 714 MB/s 10002 MB/s 128 713 MB/s 13344 MB/s 200 715 MB/s 15752 MB/s 256 714 MB/s 22933 MB/s 511 715 MB/s 28025 MB/s 512 714 MB/s 49772 MB/s 1024 715 MB/s 65261 MB/s 3173 714 MB/s 78773 MB/s 4096 714 MB/s 83315 MB/s 16384 714 MB/s 89487 MB/scrc64_nvme: Length Before After ------ ------ ----- 1 716 MB/s 474 MB/s 16 717 MB/s 3303 MB/s 64 713 MB/s 7940 MB/s 127 715 MB/s 9867 MB/s 128 714 MB/s 13698 MB/s 200 715 MB/s 15995 MB/s 256 714 MB/s 23479 MB/s 511 714 MB/s 28013 MB/s 512 715 MB/s 51533 MB/s 1024 715 MB/s 66788 MB/s 3173 715 MB/s 79182 MB/s 4096 715 MB/s 83966 MB/s 16384 715 MB/s 89739 MB/sAcked-by: Keith Busch Reviewed-by: "Martin K. Petersen" Link: https://lore.kernel.org/r/20250210174540.161705-7-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/x86/lib/Makefile

dbdda1fd - x86/crc-t10dif: implement crc_t10dif using new template

Mon, 10 Feb 2025 17:26:45 +0000

x86/crc-t10dif: implement crc_t10dif using new templateInstantiate crc-pclmul-template.S for crc_t10dif and delete the originalPCLMULQDQ optimized implementation. This has the following advantages:- Less CRC-variant-specific code.- VPCLMULQDQ support, greatly improving performance on sufficiently long messages on newer CPUs.- A faster reduction from 128 bits to the final CRC.- Support for i386.Benchmark results on AMD Ryzen 9 9950X (Zen 5) using crc_kunit: Length Before After ------ ------ ----- 1 440 MB/s 386 MB/s 16 1865 MB/s 2008 MB/s 64 4343 MB/s 6917 MB/s 127 5440 MB/s 8909 MB/s 128 5533 MB/s 12150 MB/s 200 5908 MB/s 14423 MB/s 256 15870 MB/s 21288 MB/s 511 14219 MB/s 25840 MB/s 512 18361 MB/s 37797 MB/s 1024 19941 MB/s 61374 MB/s 3173 20461 MB/s 74909 MB/s 4096 21310 MB/s 78919 MB/s 16384 21663 MB/s 85012 MB/sAcked-by: Ard Biesheuvel Acked-by: Keith Busch Reviewed-by: "Martin K. Petersen" Link: https://lore.kernel.org/r/20250210174540.161705-6-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/x86/lib/Makefile

ed4bc981 - x86/crc-t10dif: expose CRC-T10DIF function through lib

Mon, 02 Dec 2024 01:20:48 +0000

x86/crc-t10dif: expose CRC-T10DIF function through libMove the x86 CRC-T10DIF assembly code into the lib directory and wire itup to the library interface. This allows it to be used without goingthrough the crypto API. It remains usable via the crypto API too viathe shash algorithms that use the library interface. Thus all thearch-specific "shash" code becomes unnecessary and is removed.Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20241202012056.209768-5-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/x86/lib/Makefile

55d1ecce - x86/crc32: expose CRC32 functions through lib

Mon, 02 Dec 2024 01:08:38 +0000

x86/crc32: expose CRC32 functions through libMove the x86 CRC32 assembly code into the lib directory and wire it upto the library interface. This allows it to be used without goingthrough the crypto API. It remains usable via the crypto API too viathe shash algorithms that use the library interface. Thus all thearch-specific "shash" code becomes unnecessary and is removed.Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20241202010844.144356-14-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/x86/lib/Makefile

20516d6e - x86: Stop using weak symbols for __iowrite32_copy()

Thu, 11 Apr 2024 16:46:14 +0000

x86: Stop using weak symbols for __iowrite32_copy()Start switching iomap_copy routines over to use #define and arch providedinline/macro functions instead of weak symbols.Inline functions allow more compiler optimization and this is often adriver hot path.x86 has the only weak implementation for __iowrite32_copy(), so replace itwith a static inline containing the same single instruction inlineassembly. The compiler will generate the "mov edx,ecx" in a more optimalway.Remove iomap_copy_64.SLink: https://lore.kernel.org/r/1-v3-1893cd8b9369+1925-mlx5_arm_wc_jgg@nvidia.comAcked-by: Arnd Bergmann Signed-off-by: Jason Gunthorpe List of files: /linux-6.15/arch/x86/lib/Makefile

cd0d9d92 - x86/boot: Move mem_encrypt= parsing to the decompressor

Tue, 27 Feb 2024 15:19:14 +0000

x86/boot: Move mem_encrypt= parsing to the decompressorThe early SME/SEV code parses the command line very early, in order todecide whether or not memory encryption should be enabled, which needsto occur even before the initial page tables are created.This is problematic for a number of reasons:- this early code runs from the 1:1 mapping provided by the decompressor or firmware, which uses a different translation than the one assumed by the linker, and so the code needs to be built in a special way;- parsing external input while the entire kernel image is still mapped writable is a bad idea in general, and really does not belong in security minded code;- the current code ignores the built-in command line entirely (although this appears to be the case for the entire decompressor)Given that the decompressor/EFI stub is an intrinsic part of the x86bootable kernel image, move the command line parsing there and out ofthe core kernel. This removes the need to build lib/cmdline.o in aspecial way, or to use RIP-relative LEA instructions in inline asmblocks.This involves a new xloadflag in the setup header to indicatethat mem_encrypt=on appeared on the kernel command line.Signed-off-by: Ard Biesheuvel Signed-off-by: Borislav Petkov (AMD) Tested-by: Tom Lendacky Link: https://lore.kernel.org/r/20240227151907.387873-17-ardb+git@google.com List of files: /linux-6.15/arch/x86/lib/Makefile

aefb2f2e - x86/bugs: Rename CONFIG_RETPOLINE => CONFIG_MITIGATION_RETPOLINE

Tue, 21 Nov 2023 16:07:32 +0000

x86/bugs: Rename CONFIG_RETPOLINE => CONFIG_MITIGATION_RETPOLINEStep 5/10 of the namespace unification of CPU mitigations related Kconfig options.[ mingo: Converted a few more uses in comments/messages as well. ]Suggested-by: Josh Poimboeuf Signed-off-by: Breno Leitao Signed-off-by: Ingo Molnar Reviewed-by: Ariel Miculas Acked-by: Josh Poimboeuf Cc: Linus Torvalds Link: https://lore.kernel.org/r/20231121160740.1249350-6-leitao@debian.org List of files: /linux-6.15/arch/x86/lib/Makefile

6d12c8d3 - percpu: Wire up cmpxchg128

Wed, 31 May 2023 13:08:39 +0000

percpu: Wire up cmpxchg128In order to replace cmpxchg_double() with the newly mintedcmpxchg128() family of functions, wire it up in this_cpu_cmpxchg().Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Mark Rutland Tested-by: Mark Rutland Link: https://lore.kernel.org/r/20230531132323.654945124@infradead.org List of files: /linux-6.15/arch/x86/lib/Makefile

034ff37d - x86: rewrite '__copy_user_nocache' function

Thu, 20 Apr 2023 22:13:50 +0000

x86: rewrite '__copy_user_nocache' functionI didn't really want to do this, but as part of all the other changes tothe user copy loops, I've been looking at this horror.I tried to clean it up multiple times, but every time I just found moreproblems, and the way it's written, it's just too hard to fix them.For example, the code is written to do quad-word alignment, and will useregular byte accesses to get to that point. That's fairly simple, butit means that any initial 8-byte alignment will be done with cachedcopies.However, the code then is very careful to do any 4-byte _tail_ accessesusing an uncached 4-byte write, and that was claimed to be relevant incommit a82eee742452 ("x86/uaccess/64: Handle the caching of 4-bytenocache copies properly in __copy_user_nocache()").So if you do a 4-byte copy using that function, it carefully uses a4-byte 'movnti' for the destination. But if you were to do a 12-bytecopy that is 4-byte aligned, it would _not_ do a 4-byte 'movnti'followed by a 8-byte 'movnti' to keep it all uncached.Instead, it would align the destination to 8 bytes using abyte-at-a-time loop, and then do a 8-byte 'movnti' for the final 8bytes.The main caller that cares is __copy_user_flushcache(), which knowsabout this insanity, and has odd cases for it all. But I just can'tdeal with looking at this kind of "it does one case right, and anotherrelated case entirely wrong".And the code really wasn't fixable without hard drugs, which I try toavoid.So instead, rewrite it in a form that hopefully not only gets thisright, but is a bit more maintainable. Knock wood.Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/x86/lib/Makefile

bce5a1e8 - x86/mem: Move memmove to out of line assembler

Tue, 18 Oct 2022 17:21:55 +0000

x86/mem: Move memmove to out of line assemblerWhen building ARCH=i386 with CONFIG_LTO_CLANG_FULL=y, it's possible(depending on additional configs which I have not been able to isolate)to observe a failure during register allocation: error: inline assembly requires more registers than availablewhen memmove is inlined into tcp_v4_fill_cb() or tcp_v6_fill_cb().memmove is quite large and probably shouldn't be inlined due to sizealone. A noinline function attribute would be the simplest fix, butthere's a few things that stand out with the current definition:In addition to having complex constraints that can't always be resolved,the clobber list seems to be missing %bx. By using numbered operandsrather than symbolic operands, the constraints are quite obnoxious torefactor.Having a large function be 99% inline asm is a code smell that thisfunction should simply be written in stand-alone out-of-line assembler.Moving this to out of line assembler guarantees that thecompiler cannot inline calls to memmove.This has been done previously for 64b:commit 9599ec0471de ("x86-64, mem: Convert memmove() to assembly fileand fix return value bug")That gives the opportunity for other cleanups like fixing theinconsistent use of tabs vs spaces and instruction suffixes, and thelabel 3 appearing twice. Symbolic operands, local labels, andadditional comments would provide this code with a fresh coat of paint.Finally, add a test that tickles the `rep movsl` implementation to testit for correctness, since it has implicit operands.Suggested-by: Ingo Molnar Suggested-by: David Laight Signed-off-by: Nick Desaulniers Signed-off-by: Dave Hansen Reviewed-by: Kees Cook Tested-by: Kees Cook Tested-by: Nathan Chancellor Link: https://lore.kernel.org/all/20221018172155.287409-1-ndesaulniers%40google.com List of files: /linux-6.15/arch/x86/lib/Makefile

d911c67e - x86: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSAN

Thu, 15 Sep 2022 15:04:11 +0000

x86: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSANThis is needed to allow memory tools like KASAN and KMSAN see the memoryaccesses from the checksum code. Without CONFIG_GENERIC_CSUM the toolscan't see memory accesses originating from handwritten assembly code.For KASAN it's a question of detecting more bugs, for KMSAN using the Cimplementation also helps avoid false positives originating from seeminglyuninitialized checksum values.Link: https://lkml.kernel.org/r/20220915150417.722975-38-glider@google.comSigned-off-by: Alexander Potapenko Cc: Alexander Viro Cc: Alexei Starovoitov Cc: Andrey Konovalov Cc: Andrey Konovalov Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Christoph Hellwig Cc: Christoph Lameter Cc: David Rientjes Cc: Dmitry Vyukov Cc: Eric Biggers Cc: Eric Biggers Cc: Eric Dumazet Cc: Greg Kroah-Hartman Cc: Herbert Xu Cc: Ilya Leoshkevich Cc: Ingo Molnar Cc: Jens Axboe Cc: Joonsoo Kim Cc: Kees Cook Cc: Marco Elver Cc: Mark Rutland Cc: Matthew Wilcox Cc: Michael S. Tsirkin Cc: Pekka Enberg Cc: Peter Zijlstra Cc: Petr Mladek Cc: Stephen Rothwell Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vegard Nossum Cc: Vlastimil Babka Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/x86/lib/Makefile

c6dbd3e5 - x86/mmx_32: Remove X86_USE_3DNOW

Mon, 15 Nov 2021 16:46:39 +0000

x86/mmx_32: Remove X86_USE_3DNOWThis code puts an exception table entry on the PREFETCH instruction tooverwrite it with a JMP.d8 when it triggers an exception. Except ofcourse, our code is no longer writable, also SMP.Instead of fixing this broken mess, simply take it out.Signed-off-by: Peter Zijlstra (Intel) Acked-by: Borislav Petkov Link: https://lkml.kernel.org/r/YZKQzUmeNuwyvZpk@hirez.programming.kicks-ass.net List of files: /linux-6.15/arch/x86/lib/Makefile

fb6a0408 - x86: Add support for 0x22/0x23 port I/O configuration space

Tue, 20 Jul 2021 03:27:49 +0000

x86: Add support for 0x22/0x23 port I/O configuration spaceDefine macros and accessors for the configuration space addressed indirectly with an index register and a data register at the port I/O locations of 0x22 and 0x23 respectively.This space is defined by the Intel MultiProcessor Specification for the IMCR register used to switch between the PIC and the APIC mode[1], by Cyrix processors for their configuration[2][3], and also some chipsets.Given the lack of atomicity with the indirect addressing a spinlock is required to protect accesses, although for Cyrix processors it is enough if accesses are executed with interrupts locally disabled, because the registers are local to the accessing CPU, and IMCR is only ever poked at by the BSP and early enough for interrupts not to have been configured yet. Therefore existing code does not have to change or use the new spinlock and neither it does.Put the spinlock in a library file then, so that it does not get pulled unnecessarily for configurations that do not refer it.Convert Cyrix accessors to wrappers so as to retain the brevity and clarity of the `getCx86' and `setCx86' calls.References:[1] "MultiProcessor Specification", Version 1.4, Intel Corporation, Order Number: 242016-006, May 1997, Section 3.6.2.1 "PIC Mode", pp. 3-7, 3-8[2] "5x86 Microprocessor", Cyrix Corporation, Order Number: 94192-00, July 1995, Section 2.3.2.4 "Configuration Registers", p. 2-23[3] "6x86 Processor", Cyrix Corporation, Order Number: 94175-01, March 1996, Section 2.4.4 "6x86 Configuration Registers", p. 2-23Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/alpine.DEB.2.21.2107182353140.9461@angie.orcam.me.uk List of files: /linux-6.15/arch/x86/lib/Makefile

ec6347bb - x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()

Tue, 06 Oct 2020 03:40:16 +0000

x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()In reaction to a proposal to introduce a memcpy_mcsafe_fast()implementation Linus points out that memcpy_mcsafe() is poorly namedrelative to communicating the scope of the interface. Specifically whataddresses are valid to pass as source, destination, and what faults /exceptions are handled.Of particular concern is that even though x86 might be able to handlethe semantics of copy_mc_to_user() with its common copy_user_generic()implementation other archs likely need / want an explicit path for thiscase: On Fri, May 1, 2020 at 11:28 AM Linus Torvalds wrote: > > On Thu, Apr 30, 2020 at 6:21 PM Dan Williams wrote: > > > > However now I see that copy_user_generic() works for the wrong reason. > > It works because the exception on the source address due to poison > > looks no different than a write fault on the user address to the > > caller, it's still just a short copy. So it makes copy_to_user() work > > for the wrong reason relative to the name. > > Right. > > And it won't work that way on other architectures. On x86, we have a > generic function that can take faults on either side, and we use it > for both cases (and for the "in_user" case too), but that's an > artifact of the architecture oddity. > > In fact, it's probably wrong even on x86 - because it can hide bugs - > but writing those things is painful enough that everybody prefers > having just one function.Replace a single top-level memcpy_mcsafe() with eithercopy_mc_to_user(), or copy_mc_to_kernel().Introduce an x86 copy_mc_fragile() name as the rename for thelow-level x86 implementation formerly named memcpy_mcsafe(). It is usedas the slow / careful backend that is supplanted by a fastcopy_mc_generic() in a follow-on patch.One side-effect of this reorganization is that separating copy_mc_64.Sto its own file means that perf no longer needs to track dependenciesfor its memcpy_64.S benchmarks. [ bp: Massage a bit. ]Signed-off-by: Dan Williams Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Acked-by: Michael Ellerman Cc: Link: http://lore.kernel.org/r/CAHk-=wjSqtXAqfUJxFtWNwmguFASTgB0dz1dT3V-78Quiezqbg@mail.gmail.comLink: https://lkml.kernel.org/r/160195561680.2163339.11574962055305783722.stgit@dwillia2-desk3.amr.corp.intel.com List of files: /linux-6.15/arch/x86/lib/Makefile

aef0148f - x86/cmdline: Disable jump tables for cmdline.c

Thu, 03 Sep 2020 02:30:56 +0000

x86/cmdline: Disable jump tables for cmdline.cWhen CONFIG_RETPOLINE is disabled, Clang uses a jump table for theswitch statement in cmdline_find_option (jump tables are disabled whenCONFIG_RETPOLINE is enabled). This function is called very early in bootfrom sme_enable() if CONFIG_AMD_MEM_ENCRYPT is enabled. At this time,the kernel is still executing out of the identity mapping, but the jumptable will contain virtual addresses.Fix this by disabling jump tables for cmdline.c when AMD_MEM_ENCRYPT isenabled.Signed-off-by: Arvind Sankar Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200903023056.3914690-1-nivedita@alum.mit.edu List of files: /linux-6.15/arch/x86/lib/Makefile

893ab004 - kbuild: remove cc-option test of -fno-stack-protector

Fri, 26 Jun 2020 18:59:12 +0000

kbuild: remove cc-option test of -fno-stack-protectorSome Makefiles already pass -fno-stack-protector unconditionally.For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.No problem report so far about hard-coding this option. So, we canassume all supported compilers know -fno-stack-protector.GCC 4.8 and Clang support this option (https://godbolt.org/z/_HDGzN)Get rid of cc-option from -fno-stack-protector.Remove CONFIG_CC_HAS_STACKPROTECTOR_NONE, which is always 'y'.Note:arch/mips/vdso/Makefile adds -fno-stack-protector twice, firstunconditionally, and second conditionally. I removed the second one.Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Acked-by: Ard Biesheuvel Reviewed-by: Nick Desaulniers List of files: /linux-6.15/arch/x86/lib/Makefile

f5d2313b - kcsan, trace: Make KCSAN compatible with tracing

Fri, 14 Feb 2020 21:10:35 +0000

kcsan, trace: Make KCSAN compatible with tracingPreviously the system would lock up if ftrace was enabled together withKCSAN. This is due to recursion on reporting if the tracer code isinstrumented with KCSAN.To avoid this for all types of tracing, disable KCSAN instrumentationfor all of kernel/trace.Furthermore, since KCSAN relies on udelay() to introduce delay, we haveto disable ftrace for udelay() (currently done for x86) in case KCSAN isused together with lockdep and ftrace. The reason is that it may corruptlockdep IRQ flags tracing state due to a peculiar case of recursion(details in Makefile comment).Reported-by: Qian Cai Tested-by: Qian Cai Acked-by: Steven Rostedt (VMware) Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney Signed-off-by: Ingo Molnar List of files: /linux-6.15/arch/x86/lib/Makefile

40d04110 - x86, kcsan: Enable KCSAN for x86

Thu, 14 Nov 2019 18:03:03 +0000

x86, kcsan: Enable KCSAN for x86This patch enables KCSAN for x86, with updates to build rules to not useKCSAN for several incompatible compilation units.Signed-off-by: Marco Elver Acked-by: Paul E. McKenney Signed-off-by: Paul E. McKenney List of files: /linux-6.15/arch/x86/lib/Makefile