Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hey again Thomas, On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote: > > Hi Thomas, > > I'm trying to optimize this for crypto performance while still taking > into account preemption concerns. I'm having a bit of trouble figuring > out a way to determine numerically wha

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hey again Thomas, On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote: > > Hi Thomas, > > I'm trying to optimize this for crypto performance while still taking > into account preemption concerns. I'm having a bit of trouble figuring > out a way to determine numerically wha

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hi Thomas, I'm trying to optimize this for crypto performance while still taking into account preemption concerns. I'm having a bit of trouble figuring out a way to determine numerically what the upper bounds for this stuff looks like. I'm sure I could pick a pretty sane number that's arguably

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hi Thomas, I'm trying to optimize this for crypto performance while still taking into account preemption concerns. I'm having a bit of trouble figuring out a way to determine numerically what the upper bounds for this stuff looks like. I'm sure I could pick a pretty sane number that's arguably

[PATCH] arm: support big-endian for the virt architecture

This architecture, used for running in QEMU, runs just fine when compiled in big-endian mode. So enable it. This is enabled in exactly the same way that it is for other platforms (such as vexpress) that also support big-endian mode in QEMU successfully. Signed-off-by: Jason A. Donenfeld

[PATCH] arm: support big-endian for the virt architecture

This architecture, used for running in QEMU, runs just fine when compiled in big-endian mode. So enable it. This is enabled in exactly the same way that it is for other platforms (such as vexpress) that also support big-endian mode in QEMU successfully. Signed-off-by: Jason A. Donenfeld

[PATCH net-next v6 09/23] zinc: Poly1305 generic C implementations and selftest

/zinc/poly1305.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ +/* + * Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights Reserved. + */ + +#ifndef _ZINC_POLY1305_H +#define _ZINC_POLY1305_H + +#include +#include + +enum poly1305_lengths { + POLY1305_BLOCK_SIZE = 16

[PATCH net-next v6 09/23] zinc: Poly1305 generic C implementations and selftest

/zinc/poly1305.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ +/* + * Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights Reserved. + */ + +#ifndef _ZINC_POLY1305_H +#define _ZINC_POLY1305_H + +#include +#include + +enum poly1305_lengths { + POLY1305_BLOCK_SIZE = 16

[PATCH] framewarn: expand KASAN_EXTRA exception to KASAN

It turns out that KASAN in general will bloat stack frames in unexpected ways, not just KASAN_EXTRA. So, this patch trivially changes that default to be associated with KASAN instead of KASAN_EXTRA. Signed-off-by: Jason A. Donenfeld --- lib/Kconfig.debug | 2 +- 1 file changed, 1 insertion

[PATCH] framewarn: expand KASAN_EXTRA exception to KASAN

It turns out that KASAN in general will bloat stack frames in unexpected ways, not just KASAN_EXTRA. So, this patch trivially changes that default to be associated with KASAN instead of KASAN_EXTRA. Signed-off-by: Jason A. Donenfeld --- lib/Kconfig.debug | 2 +- 1 file changed, 1 insertion

[PATCH net-next v5 16/20] zinc: Curve25519 ARM implementation

This comes from Dan Bernstein and Peter Schwabe's public domain NEON code, and has been modified to be friendly for kernel space, as well as removing some qhasm strangeness to be more idiomatic. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean

[PATCH net-next v5 16/20] zinc: Curve25519 ARM implementation

This comes from Dan Bernstein and Peter Schwabe's public domain NEON code, and has been modified to be friendly for kernel space, as well as removing some qhasm strangeness to be more idiomatic. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean

[PATCH net-next v5 15/20] zinc: Curve25519 x86_64 implementation

with contributions (upstream) from Samuel Neves and me, in addition to further changes in the kernel implementation from us. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson Cc: Armando Faz-Hernández Cc: Thomas Gleixner Cc: Ingo

[PATCH net-next v5 15/20] zinc: Curve25519 x86_64 implementation

with contributions (upstream) from Samuel Neves and me, in addition to further changes in the kernel implementation from us. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson Cc: Armando Faz-Hernández Cc: Thomas Gleixner Cc: Ingo

[PATCH net-next v5 02/20] zinc: introduce minimal cryptography library

/mac.html [7] https://blake2.net/ [8] https://tools.ietf.org/html/rfc8439 [9] https://github.com/google/wycheproof Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson --- MAINTAINERS | 8 lib/Kconfig

[PATCH net-next v5 02/20] zinc: introduce minimal cryptography library

/mac.html [7] https://blake2.net/ [8] https://tools.ietf.org/html/rfc8439 [9] https://github.com/google/wycheproof Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson --- MAINTAINERS | 8 lib/Kconfig

Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc

Hey Martin, Thanks for running these and pointing this out. I've replicated the results with tcrypt and fixed some issues, and the next patch series should be a lot closer to what you'd expect, instead of the regression you noticed. Most of the slowdown happened as a result of over-eager XSAVEs,

Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc

Hey Martin, Thanks for running these and pointing this out. I've replicated the results with tcrypt and fixed some issues, and the next patch series should be a lot closer to what you'd expect, instead of the regression you noticed. Most of the slowdown happened as a result of over-eager XSAVEs,

Re: [PATCH net-next v4 17/20] crypto: port Poly1305 to Zinc

Greetings Mr. Ro Bot, Another one of your robot friends also caught this, and the offending code has been removed for v5. Thanks for botting, Jason

Re: [PATCH net-next v4 17/20] crypto: port Poly1305 to Zinc

Greetings Mr. Ro Bot, Another one of your robot friends also caught this, and the offending code has been removed for v5. Thanks for botting, Jason

[PATCH net-next v4 16/20] zinc: Curve25519 x86_64 implementation

with contributions (upstream) from Samuel Neves and me, in addition to further changes in the kernel implementation from us. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson Cc: Armando Faz-Hernández Cc: Thomas Gleixner Cc: Ingo

[PATCH net-next v4 17/20] crypto: port Poly1305 to Zinc

Now that Poly1305 is in Zinc, we can have the crypto API code simply call into it. We have to do a little bit of book keeping here, because the crypto API receives the key in the first few calls to update. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc

[PATCH net-next v4 16/20] zinc: Curve25519 x86_64 implementation

with contributions (upstream) from Samuel Neves and me, in addition to further changes in the kernel implementation from us. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson Cc: Armando Faz-Hernández Cc: Thomas Gleixner Cc: Ingo

[PATCH net-next v4 17/20] crypto: port Poly1305 to Zinc

Now that Poly1305 is in Zinc, we can have the crypto API code simply call into it. We have to do a little bit of book keeping here, because the crypto API receives the key in the first few calls to update. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc

[PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc

Now that ChaCha20 is in Zinc, we can have the crypto API code simply call into it. The crypto API expects to have a stored key per instance and independent nonces, so we follow suite and store the key and initialize the nonce independently. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc

[PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc

Now that ChaCha20 is in Zinc, we can have the crypto API code simply call into it. The crypto API expects to have a stored key per instance and independent nonces, so we follow suite and store the key and initialize the nonce independently. Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc

[PATCH net-next v4 08/20] zinc: Poly1305 ARM and ARM64 implementations

/ write result ret +ENDPROC(poly1305_emit_neon) Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson Cc: Andy Polyakov Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org --- lib/zinc/Makefile |8 + lib

[PATCH net-next v4 08/20] zinc: Poly1305 ARM and ARM64 implementations

/ write result ret +ENDPROC(poly1305_emit_neon) Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson Cc: Andy Polyakov Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org --- lib/zinc/Makefile |8 + lib

Re: [PATCH net-next v3 01/17] asm: simd context helper API

On Thu, Sep 13, 2018 at 7:03 AM Kevin Easton wrote: > Yes. It's also how most get/put APIs already work in the kernel, eg > kref_get/put (mostly because they tend to be 'getting/putting' an > already-initialized object, though). Right; in this case the object wouldn't be initialized yet, which

Re: [PATCH net-next v3 01/17] asm: simd context helper API

On Thu, Sep 13, 2018 at 7:03 AM Kevin Easton wrote: > Yes. It's also how most get/put APIs already work in the kernel, eg > kref_get/put (mostly because they tend to be 'getting/putting' an > already-initialized object, though). Right; in this case the object wouldn't be initialized yet, which

Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library

Hey Andy, Eric, & all, I've started the work of separating this out into 16 individual commits, have addressed numerous other things brought up like the ifdef maze, and have begun rewriting (parts of) the original commit message. It's still a work in progress, and I still have some work to do,

Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library

Hey Andy, Eric, & all, I've started the work of separating this out into 16 individual commits, have addressed numerous other things brought up like the ifdef maze, and have begun rewriting (parts of) the original commit message. It's still a work in progress, and I still have some work to do,

Accuracy bounds of ktime_get_boot_fast_ns

Hi, In my driver, I am constantly concerned with determining for how long a certain object has been alive, in real time, because the lifetime needs to be more or less synchronized with others on a network. For this, I'm generally using a formulation like: void foobar_create(struct foobar *f) {

Accuracy bounds of ktime_get_boot_fast_ns

Hi, In my driver, I am constantly concerned with determining for how long a certain object has been alive, in real time, because the lifetime needs to be more or less synchronized with others on a network. For this, I'm generally using a formulation like: void foobar_create(struct foobar *f) {

[PATCH] kasan: depend on CONFIG_SLUB_DEBUG

: f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()") Cc: Shakeel Butt Cc: David Rientjes Cc: Christoph Lameter Cc: Pekka Enberg Cc: Joonsoo Kim Cc: Andrew Morton Cc: Andrey Ryabinin Cc: Cc: Cc: Signed-off-by: Jason A. Donenfeld --- lib/Kconfig.kasan | 1 + 1 file

[PATCH] kasan: depend on CONFIG_SLUB_DEBUG

: f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()") Cc: Shakeel Butt Cc: David Rientjes Cc: Christoph Lameter Cc: Pekka Enberg Cc: Joonsoo Kim Cc: Andrew Morton Cc: Andrey Ryabinin Cc: Cc: Cc: Signed-off-by: Jason A. Donenfeld --- lib/Kconfig.kasan | 1 + 1 file

[PATCH] module: print sensible error code

Printing "err 0" to the user in the warning message is not particularly useful, especially when this gets transformed into a -ENOENT for the remainder of the call chain. Signed-off-by: Jason A. Donenfeld --- kernel/module.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH] module: print sensible error code

Printing "err 0" to the user in the warning message is not particularly useful, especially when this gets transformed into a -ENOENT for the remainder of the call chain. Signed-off-by: Jason A. Donenfeld --- kernel/module.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] slub: fix __kmem_cache_empty for !CONFIG_SLUB_DEBUG

ary kasan_cache_shutdown()") > Signed-off-by: Shakeel Butt > Reported-by: Jason A . Donenfeld > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Andrew Morton > Cc: > --- > mm/slub.c | 16 +++- > 1 file

Re: [PATCH] slub: fix __kmem_cache_empty for !CONFIG_SLUB_DEBUG

ary kasan_cache_shutdown()") > Signed-off-by: Shakeel Butt > Reported-by: Jason A . Donenfeld > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Andrew Morton > Cc: > --- > mm/slub.c | 16 +++- > 1 file

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

Hi Shakeel, On Tue, Jun 19, 2018 at 9:21 PM Shakeel Butt wrote: > Jason, can you try the following patch? Your patch also fixed the problem, which was also fixed by enabling CONFIG_SLUB_DEBUG, per the other email. I haven't checked to see if your patch is simply a subset of what SLUB_DEBUG is

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

Hi Shakeel, On Tue, Jun 19, 2018 at 9:21 PM Shakeel Butt wrote: > Jason, can you try the following patch? Your patch also fixed the problem, which was also fixed by enabling CONFIG_SLUB_DEBUG, per the other email. I haven't checked to see if your patch is simply a subset of what SLUB_DEBUG is

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

Hi Andrey, On Tue, Jun 19, 2018 at 7:33 PM Andrey Ryabinin wrote: > What's the status of CONFIG_SLUB_DEBUG in your config? > > AFAICS __kmem_cache_empty() is broken for CONFIG_SLUB_DEBUG=n. We use > slabs_node() there > which is always 0 for CONFIG_SLUB_DEBUG=n. > > The problem seems not

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

Hi Andrey, On Tue, Jun 19, 2018 at 7:33 PM Andrey Ryabinin wrote: > What's the status of CONFIG_SLUB_DEBUG in your config? > > AFAICS __kmem_cache_empty() is broken for CONFIG_SLUB_DEBUG=n. We use > slabs_node() there > which is always 0 for CONFIG_SLUB_DEBUG=n. > > The problem seems not

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On Tue, Jun 19, 2018 at 5:08 PM Shakeel Butt wrote: > > > Are you using SLAB or SLUB? We stress kernel pretty heavily, but with > > > SLAB, and I suspect Shakeel may also be using SLAB. So if you are > > > using SLUB, there is significant chance that it's a bug in the SLUB > > > part of the

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On Tue, Jun 19, 2018 at 5:08 PM Shakeel Butt wrote: > > > Are you using SLAB or SLUB? We stress kernel pretty heavily, but with > > > SLAB, and I suspect Shakeel may also be using SLAB. So if you are > > > using SLUB, there is significant chance that it's a bug in the SLUB > > > part of the

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On Tue, Jun 19, 2018 at 3:31 PM Dmitry Vyukov wrote: > Since I already looked at the code, if init and uninit can be called > concurrently, I think there is a prominent race condition between init > and uninit: a concurrent uninit can run concurrnetly with the next > init and this will totally

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On Tue, Jun 19, 2018 at 3:31 PM Dmitry Vyukov wrote: > Since I already looked at the code, if init and uninit can be called > concurrently, I think there is a prominent race condition between init > and uninit: a concurrent uninit can run concurrnetly with the next > init and this will totally

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On Tue, Jun 19, 2018 at 7:06 AM Shakeel Butt wrote: > Currently refcnt in your > code can underflow, through it does not seem like the selftest will > cause the underflow but still you should fix it. Indeed, and if this happened this would be a bug in the caller, not the ratelimiter itself, kind

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On Tue, Jun 19, 2018 at 7:06 AM Shakeel Butt wrote: > Currently refcnt in your > code can underflow, through it does not seem like the selftest will > cause the underflow but still you should fix it. Indeed, and if this happened this would be a bug in the caller, not the ratelimiter itself, kind

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

HI Dimitry, On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote: > Your code frees all entries before freeing the cache, right? If you > add total_entries check before freeing the cache, it does not fire, > right? Yes, certainly. > Are you using SLAB or SLUB? We stress kernel pretty heavily,

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

HI Dimitry, On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote: > Your code frees all entries before freeing the cache, right? If you > add total_entries check before freeing the cache, it does not fire, > right? Yes, certainly. > Are you using SLAB or SLUB? We stress kernel pretty heavily,

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote: > Hi Jason, yes please do send me the test suite with the kernel config. $ git clone https://git.zx2c4.com/WireGuard $ cd WireGuard/src $ [[ $(gcc -v 2>&1) =~ gcc\ version\ 8\.1\.0 ]] || echo crash needs 8.1 $ export DEBUG_KERNEL=yes $ export

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote: > Hi Jason, yes please do send me the test suite with the kernel config. $ git clone https://git.zx2c4.com/WireGuard $ cd WireGuard/src $ [[ $(gcc -v 2>&1) =~ gcc\ version\ 8\.1\.0 ]] || echo crash needs 8.1 $ export DEBUG_KERNEL=yes $ export

Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

Hello Shakeel, It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has introduced a regression. I've bisected a failing test to this commit, and after staring at the my code for a long time, I'm unable to find a bug that this commit might have unearthed. Rather, it looks like this

Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

Hello Shakeel, It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has introduced a regression. I've bisected a failing test to this commit, and after staring at the my code for a long time, I'm unable to find a bug that this commit might have unearthed. Rather, it looks like this

[PATCH] random: make crng state queryable

return false; } return false; } Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 15 +++ include/linux/random.h | 1 + 2 files changed, 16 insertions(+) diff --git a/drivers/char/random.c b/drivers/char/random.c index a8fb0020ba5c..871724f7b810 100644 --- a/driver

[PATCH] random: make crng state queryable

return false; } return false; } Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 15 +++ include/linux/random.h | 1 + 2 files changed, 16 insertions(+) diff --git a/drivers/char/random.c b/drivers/char/random.c index a8fb0020ba5c..871724f7b810 100644 --- a/driver

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Mon, Jun 18, 2018 at 11:44 AM Peter Zijlstra wrote: > > On Fri, Jun 15, 2018 at 10:30:46PM +0200, Jason A. Donenfeld wrote: > > On Fri, Jun 15, 2018 at 9:34 PM Peter Zijlstra wrote: > > > Didn't we recently do a bunch of crypto patches to help with this? > &g

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Mon, Jun 18, 2018 at 11:44 AM Peter Zijlstra wrote: > > On Fri, Jun 15, 2018 at 10:30:46PM +0200, Jason A. Donenfeld wrote: > > On Fri, Jun 15, 2018 at 9:34 PM Peter Zijlstra wrote: > > > Didn't we recently do a bunch of crypto patches to help with this? > &g

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Fri, Jun 15, 2018 at 10:27 PM Jason A. Donenfeld wrote: > AVX512 - Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz > Inside: 634415672 > Outside: 286698960 > Percent speedup: 121 More realistic results, with turbo turned off: Inside: 616851298 Outside: 339606790 Percent speedup: 81 St

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Fri, Jun 15, 2018 at 10:27 PM Jason A. Donenfeld wrote: > AVX512 - Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz > Inside: 634415672 > Outside: 286698960 > Percent speedup: 121 More realistic results, with turbo turned off: Inside: 616851298 Outside: 339606790 Percent speedup: 81 St

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Fri, Jun 15, 2018 at 8:32 PM Andy Lutomirski wrote: > quite in the form you imagined. The idea that we've tossed around is > to restore FPU state on return to user mode. Roughly, we'd introduce > a new thread flag TIF_FPU_UNLOADED (name TBD). > prepare_exit_to_usermode() would notice this

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Fri, Jun 15, 2018 at 8:32 PM Andy Lutomirski wrote: > quite in the form you imagined. The idea that we've tossed around is > to restore FPU state on return to user mode. Roughly, we'd introduce > a new thread flag TIF_FPU_UNLOADED (name TBD). > prepare_exit_to_usermode() would notice this

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Fri, Jun 15, 2018 at 9:34 PM Peter Zijlstra wrote: > Didn't we recently do a bunch of crypto patches to help with this? > > I think they had the pattern: > > kernel_fpu_begin(); > for (units-of-work) { > do_unit_of_work(); > if (need_resched()) {

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Fri, Jun 15, 2018 at 9:34 PM Peter Zijlstra wrote: > Didn't we recently do a bunch of crypto patches to help with this? > > I think they had the pattern: > > kernel_fpu_begin(); > for (units-of-work) { > do_unit_of_work(); > if (need_resched()) {

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Fri, Jun 15, 2018 at 8:53 PM Andy Lutomirski wrote: > > On Fri, Jun 15, 2018 at 11:50 AM Dave Hansen > wrote: > Even with the modified optimization, kernel_fpu_end() still needs to > reload the state that was trashed by the kernel FPU use. If the > kernel is using something like AVX512

Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch

On Fri, Jun 15, 2018 at 8:53 PM Andy Lutomirski wrote: > > On Fri, Jun 15, 2018 at 11:50 AM Dave Hansen > wrote: > Even with the modified optimization, kernel_fpu_end() still needs to > reload the state that was trashed by the kernel FPU use. If the > kernel is using something like AVX512

Lazy FPU restoration / moving kernel_fpu_end() to context switch

Hi Andy & folks, Lots of crypto routines look like this: kernel_fpu_begin(); encrypt(); kernel_fpu_end(); If you call such a routine twice, you get: kernel_fpu_begin(); encrypt(); kernel_fpu_end(); kernel_fpu_begin(); encrypt(); kernel_fpu_end(); In a loop this looks like: for (thing) {

Lazy FPU restoration / moving kernel_fpu_end() to context switch

Hi Andy & folks, Lots of crypto routines look like this: kernel_fpu_begin(); encrypt(); kernel_fpu_end(); If you call such a routine twice, you get: kernel_fpu_begin(); encrypt(); kernel_fpu_end(); kernel_fpu_begin(); encrypt(); kernel_fpu_end(); In a loop this looks like: for (thing) {

Re: Linux messages full of `random: get_random_u32 called from`

> - if ((fast_pool->count < 64) && > - !time_after(now, fast_pool->last + HZ)) > - return; > - I suspect you still want the rate-limiting in place. But if you _do_ want to cheat like this, you could instead just modify the condition to only relax the rate limiting

Re: Linux messages full of `random: get_random_u32 called from`

> - if ((fast_pool->count < 64) && > - !time_after(now, fast_pool->last + HZ)) > - return; > - I suspect you still want the rate-limiting in place. But if you _do_ want to cheat like this, you could instead just modify the condition to only relax the rate limiting

[PATCH v2] arm64: export tishift functions to modules

, and I personally choose to relicense this as GPL2||BSD so that these symbols don't need to be export_symbol_gpl, so all modules can use the routines, since these are important general purpose compiler-generated function calls. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reported-by: Pa

[PATCH v2] arm64: export tishift functions to modules

, and I personally choose to relicense this as GPL2||BSD so that these symbols don't need to be export_symbol_gpl, so all modules can use the routines, since these are important general purpose compiler-generated function calls. Signed-off-by: Jason A. Donenfeld Reported-by: PaX Team Cc: sta

Re: Linux messages full of `random: get_random_u32 called from`

Hi Ted, Please correct me if I'm wrong, but my present understanding of this is that crng readiness used to be broken, meaning people would have a seeded rng without it actually being seeded. You fixed this bug, and now people are discovering that they don't have crng readiness during a late

Re: Linux messages full of `random: get_random_u32 called from`

Hi Ted, Please correct me if I'm wrong, but my present understanding of this is that crng readiness used to be broken, meaning people would have a seeded rng without it actually being seeded. You fixed this bug, and now people are discovering that they don't have crng readiness during a late

[PATCH] crypto: remove Speck

This NSA-designed cipher was rejected for inclusion in international standards by ISO/IEC. Before anyone actually starts using it by accident, let's just not ship it at all. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- arch/arm/crypto/Kconfig |6 - arch/arm/

[PATCH] crypto: remove Speck

This NSA-designed cipher was rejected for inclusion in international standards by ISO/IEC. Before anyone actually starts using it by accident, let's just not ship it at all. Signed-off-by: Jason A. Donenfeld --- arch/arm/crypto/Kconfig |6 - arch/arm/crypto/Makefile

Re: [PATCH] arm64: export tishift functions to modules

On Tue, Apr 24, 2018 at 5:40 PM, Will Deacon <will.dea...@arm.com> wrote: > On Tue, Apr 24, 2018 at 03:43:04PM +0200, Jason A. Donenfeld wrote: >> On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon <will.dea...@arm.com> wrote: >> > I've not run into any build issue

Re: [PATCH] arm64: export tishift functions to modules

On Tue, Apr 24, 2018 at 5:40 PM, Will Deacon wrote: > On Tue, Apr 24, 2018 at 03:43:04PM +0200, Jason A. Donenfeld wrote: >> On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote: >> > I've not run into any build issues here -- is this specifically with some >> >

Re: [PATCH] arm64: support __int128 with clang

On Tue, Apr 24, 2018 at 3:47 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > On Tue, Apr 24, 2018 at 3:35 PM, Will Deacon <will.dea...@arm.com> wrote: >> On Sun, Apr 15, 2018 at 06:20:11PM +0200, Jason A. Donenfeld wrote: >>> Would you review/merge this when yo

Re: [PATCH] arm64: support __int128 with clang

On Tue, Apr 24, 2018 at 3:47 PM, Jason A. Donenfeld wrote: > On Tue, Apr 24, 2018 at 3:35 PM, Will Deacon wrote: >> On Sun, Apr 15, 2018 at 06:20:11PM +0200, Jason A. Donenfeld wrote: >>> Would you review/merge this when you have a chance? >> >> No real objecti

Re: [PATCH] arm64: support __int128 with clang

On Tue, Apr 24, 2018 at 3:35 PM, Will Deacon <will.dea...@arm.com> wrote: > On Sun, Apr 15, 2018 at 06:20:11PM +0200, Jason A. Donenfeld wrote: >> Would you review/merge this when you have a chance? > > No real objection from me, but does the arm64 kernel actually build wit

Re: [PATCH] arm64: support __int128 with clang

On Tue, Apr 24, 2018 at 3:35 PM, Will Deacon wrote: > On Sun, Apr 15, 2018 at 06:20:11PM +0200, Jason A. Donenfeld wrote: >> Would you review/merge this when you have a chance? > > No real objection from me, but does the arm64 kernel actually build with > clang? I've been

Re: [PATCH] arm64: export tishift functions to modules

On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote: > I've not run into any build issues here -- is this specifically with some > out-of-tree module? I received a bug report email about this. I'm not sure which specific module, and I assumed from the email that it was

Re: [PATCH] arm64: export tishift functions to modules

On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote: > I've not run into any build issues here -- is this specifically with some > out-of-tree module? I received a bug report email about this. I'm not sure which specific module, and I assumed from the email that it was actually a result of

Re: [PATCH] arm64: support __int128 with clang

Hi Will, Would you review/merge this when you have a chance? Thanks, Jason On Sat, Dec 23, 2017 at 1:43 AM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > Commit fb8722735f50 ("arm64: support __int128 on gcc 5+") added support > for arm64 __int128 with gcc with

Re: [PATCH] arm64: support __int128 with clang

Hi Will, Would you review/merge this when you have a chance? Thanks, Jason On Sat, Dec 23, 2017 at 1:43 AM, Jason A. Donenfeld wrote: > Commit fb8722735f50 ("arm64: support __int128 on gcc 5+") added support > for arm64 __int128 with gcc with a version-conditional, but negle

[PATCH] arm64: export tishift functions to modules

-generated function calls. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reported-by: PaX Team <pagee...@freemail.hu> Cc: sta...@vger.kernel.org --- arch/arm64/include/asm/asm-prototypes.h | 11 +++ arch/arm64/lib/tishift.S| 19 ++- 2 files

[PATCH] arm64: export tishift functions to modules

-generated function calls. Signed-off-by: Jason A. Donenfeld Reported-by: PaX Team Cc: sta...@vger.kernel.org --- arch/arm64/include/asm/asm-prototypes.h | 11 +++ arch/arm64/lib/tishift.S| 19 ++- 2 files changed, 17 insertions(+), 13 deletions(-) create

Re: [PATCH 00/31 v2] PTI support for x86_32

Hi Linus, On Tue, Feb 13, 2018 at 6:25 PM, Linus Torvalds wrote: > So let's try to fix the iscsi and ipsec issues. Not that anybody sane > should use that overly complex ipsec thing, and I think we should > strive to merge WireGuard and get people moved over to

Re: [PATCH 00/31 v2] PTI support for x86_32

Hi Linus, On Tue, Feb 13, 2018 at 6:25 PM, Linus Torvalds wrote: > So let's try to fix the iscsi and ipsec issues. Not that anybody sane > should use that overly complex ipsec thing, and I think we should > strive to merge WireGuard and get people moved over to that instead, > but I haven't

C tricks for efficient stack zeroing

Hi list, I'm writing this email to solicit tricks for efficiently zeroing out the stack upon returning from a function. The reason this is often desirable is if the stack contains intermediate values that could assist in some form of cryptographic attack if compromised at a later point in time.

C tricks for efficient stack zeroing

Hi list, I'm writing this email to solicit tricks for efficiently zeroing out the stack upon returning from a function. The reason this is often desirable is if the stack contains intermediate values that could assist in some form of cryptographic attack if compromised at a later point in time.

Re: [PATCH] netlink: put module reference if dump start fails

Thanks! Jason

Re: [PATCH] netlink: put module reference if dump start fails

Thanks! Jason

Re: [PATCH] netlink: put module reference if dump start fails

Fixes: 41c87425a1ac ("netlink: do not set cb_running if dump's start() errs")

Re: [PATCH] netlink: put module reference if dump start fails

Fixes: 41c87425a1ac ("netlink: do not set cb_running if dump's start() errs")

Re: [PATCH] netlink: put module reference if dump start fails

On Wed, Feb 21, 2018 at 6:47 AM, Eric Dumazet wrote: >> This probably should be queued up for stable. > > When was the bug added ? This would help a lot stable teams ... This needs to be backported to 4.16-rc0+, 4.15+, 4.14+, 4.13.14+, and 4.9.63+.

Re: [PATCH] netlink: put module reference if dump start fails

On Wed, Feb 21, 2018 at 6:47 AM, Eric Dumazet wrote: >> This probably should be queued up for stable. > > When was the bug added ? This would help a lot stable teams ... This needs to be backported to 4.16-rc0+, 4.15+, 4.14+, 4.13.14+, and 4.9.63+.

<    1   2   3   4   5   6   7   8   9   10   >