Re: [PATCH] x86/uaccess: Avoid barrier_nospec() in copy_from_user()

On Mon, Oct 14, 2024 at 04:39:26PM +0100, Andrew Cooper wrote: > On 14/10/2024 1:30 pm, Kirill A. Shutemov wrote: > > +++ b/arch/x86/lib/getuser.S > > @@ -37,9 +37,14 @@ > > +#define SHIFT_LEFT_TO_MSB ALTERNATIVE \ > > + "shl $(64 - 48), %rdx", \ > > + "shl $(64 - 57), %rdx", X86_FEATURE_LA57 >

Re: [PATCH] x86/uaccess: Avoid barrier_nospec() in copy_from_user()

On Sun, 20 Oct 2024 at 15:44, Josh Poimboeuf wrote: > > Anyway, I'd really like to make forward progress on getting rid of the > LFENCEs in copy_from_user() and __get_user(), so until if/when we hear > back from both vendors, how about we avoid noncanonical exceptions > altogether (along with the

Re: [PATCH] x86/uaccess: Avoid barrier_nospec() in copy_from_user()

On Sun, Oct 20, 2024 at 03:59:25PM -0700, Linus Torvalds wrote: > On Sun, 20 Oct 2024 at 15:44, Josh Poimboeuf wrote: > > > > Anyway, I'd really like to make forward progress on getting rid of the > > LFENCEs in copy_from_user() and __get_user(), so until if/when we hear > > back from both vendors

Re: [PATCH] x86/uaccess: Avoid barrier_nospec() in copy_from_user()

On Sun, Oct 20, 2024 at 04:11:25PM -0700, Josh Poimboeuf wrote: > #define FORCE_CANONICAL > \ > ALTERNATIVE_2 > \ > "shl $(64 - 48), %rdx",

Re: [PATCH] x86/uaccess: Avoid barrier_nospec() in copy_from_user()

On Sun, 20 Oct 2024 at 16:11, Josh Poimboeuf wrote: > > Until it's s/think/know/ can we please put something in place? Honestly, I'm pretty damn fed up with buggy hardware and completely theoretical attacks that have never actually shown themselves to be used in practice. So I think this time we

[PATCH 05/15] mips/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the mips CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the ar

[PATCH 12/15] lib/crc32: make crc32c() go directly to lib

From: Eric Biggers Now that the lower level __crc32c_le() library function is optimized for each architecture, make crc32c() just call that instead of taking an inefficient and error-prone detour through the shash API. Note: a future cleanup should make crc32c_le() be the actual library function

[PATCH 00/15] Wire up CRC32 library functions to arch-optimized code

This patchset is also available in git via: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git crc32-lib-v1 CRC32 is a family of common non-cryptographic integrity check algorithms that are fairly fast with a portable C implementation and become far faster still wit

[PATCH 03/15] arm/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the arm CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the arc

[PATCH 02/15] lib/crc32: improve support for arch-specific overrides

From: Eric Biggers Currently the CRC32 library functions are defined as weak symbols, and the arm64 and riscv architectures override them. This method of arch-specific overrides has the limitation that it only works when both the base and arch code is built-in. Also, it makes the arch-specific

[PATCH 10/15] x86/crc32: update prototype for crc32_pclmul_le_16()

From: Eric Biggers - Change the len parameter from unsigned int to size_t, so that the library function which takes a size_t can safely use this code. - Move the crc parameter to the front, as this is the usual convention. Signed-off-by: Eric Biggers --- arch/x86/crypto/crc32-pclmul_asm.S

[PATCH 06/15] powerpc/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the powerpc CRC32C assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all th

[PATCH 01/15] lib/crc32: drop leading underscores from __crc32c_le_base

From: Eric Biggers Remove the leading underscores from __crc32c_le_base(). This is in preparation for adding crc32c_le_arch() and eventually renaming __crc32c_le() to crc32c_le(). Signed-off-by: Eric Biggers --- arch/arm64/lib/crc32-glue.c | 2 +- arch/riscv/lib/crc32.c | 2 +- crypto/cr

[PATCH 09/15] x86/crc32: update prototype for crc_pcl()

From: Eric Biggers - Change the len parameter from unsigned int to size_t, so that the library function which takes a size_t can safely use this code. - Rename to crc32c_x86_3way() which is much clearer. - Move the crc parameter to the front, as this is the usual convention. Signed-off-by: E

[PATCH 15/15] f2fs: switch to using the crc32 library

From: Eric Biggers Now that the crc32() library function takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Signed-off-by: Eric B

[PATCH 07/15] s390/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the s390 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the ar

[PATCH 14/15] jbd2: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Signed-off

[PATCH 11/15] x86/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the x86 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the arc

[PATCH 13/15] ext4: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Signed-off

[PATCH 08/15] sparc/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the sparc CRC32C assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH 04/15] loongarch/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the loongarch CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all t

Re: [PATCH] powerpc/crash: Allow direct printing on kexec

Hi Ryo, On 2024-10-20, Ryo Takakura wrote: > Let legacy consoles print directly so that we can see messages on kexec, as > the commit b6cf8b3f3312 ("printk: add lockless ringbuffer") turned printk > ring buffer lockless and there should be no worries panicked CPU > deadlocking writing into ringb

[PATCH] powerpc/crash: Allow direct printing on kexec

Since the commit af2876b501e4 ("powerpc/crash: Use NMI context for printk when starting to crash"), printing has been deferred before shutting down non-panicked CPU on kexec to avoid deadlock on logbuf_lock. It is deferred until the shutdown of the first kernel and starts booting into the second ke