Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode

2021-04-08 Thread Ard Biesheuvel
On Fri, 9 Apr 2021 at 05:03, Jason A. Donenfeld wrote: > > On Fri, Apr 09, 2021 at 10:49:07AM +0800, Hangbin Liu wrote: > > On Thu, Apr 08, 2021 at 08:44:35PM -0600, Jason A. Donenfeld wrote: > > > Since it's just a normal module library, you can simply do this in the > > > module_init function, r

[PATCH] Bluetooth: avoid u128_xor() on potentially misaligned inputs

2021-01-05 Thread Ard Biesheuvel
u128_xor() takes pointers to quantities that are assumed to be at least 64-bit aligned, which is not guaranteed to be the case in the smp_c1() routine. So switch to crypto_xor() instead. Signed-off-by: Ard Biesheuvel --- net/bluetooth/smp.c | 5 ++--- 1 file changed, 2 insertions(+), 3

Re: Why the auxiliary cipher in gss_krb5_crypto.c?

2020-12-08 Thread Ard Biesheuvel
On Tue, 8 Dec 2020 at 14:25, David Howells wrote: > > I wonder - would it make sense to reserve two arrays of scatterlist structs > and a mutex per CPU sufficient to map up to 1MiB of pages with each array > while the krb5 service is in use? > > That way sunrpc could, say, grab the mutex, map the

Re: Why the auxiliary cipher in gss_krb5_crypto.c?

2020-12-08 Thread Ard Biesheuvel
On Mon, 7 Dec 2020 at 15:15, David Howells wrote: > > Ard Biesheuvel wrote: > > > > I wonder if it would help if the input buffer and output buffer didn't > > > have to correspond exactly in usage - ie. the output buffer could be used > > > at a slower r

Re: Why the auxiliary cipher in gss_krb5_crypto.c?

2020-12-07 Thread Ard Biesheuvel
On Mon, 7 Dec 2020 at 13:02, David Howells wrote: > > Ard Biesheuvel wrote: > > > > Yeah - the problem with that is that for sunrpc, we might be dealing with > > > 1MB > > > plus bits of non-contiguous pages, requiring >8K of scatterlist elements > >

Re: Why the auxiliary cipher in gss_krb5_crypto.c?

2020-12-04 Thread Ard Biesheuvel
On Fri, 4 Dec 2020 at 18:19, David Howells wrote: > > Ard Biesheuvel wrote: > > > The tricky thing with CTS is that you have to ensure that the final > > full and partial blocks are presented to the crypto driver as one > > chunk, or it won't be able to perfo

Re: Why the auxiliary cipher in gss_krb5_crypto.c?

2020-12-04 Thread Ard Biesheuvel
On Fri, 4 Dec 2020 at 17:52, David Howells wrote: > > Bruce Fields wrote: > > > OK, I guess I don't understand the question. I haven't thought about > > this code in at least a decade. What's an auxilary cipher? Is this a > > question about why we're implementing something, or how we're > > im

Re: [PATCH cryptodev] crypto: lib/chacha20poly1305 - allow users to specify 96bit nonce

2020-11-17 Thread Ard Biesheuvel
On Tue, 17 Nov 2020 at 10:47, Antonio Quartulli wrote: > > Hi, > > > On 17/11/2020 09:31, Ard Biesheuvel wrote: > > If you are going back to the drawing board with in-kernel acceleration > > for OpenVPN, I strongly suggest to: > > a) either stick to one im

Re: [PATCH cryptodev] crypto: lib/chacha20poly1305 - allow users to specify 96bit nonce

2020-11-17 Thread Ard Biesheuvel
On Tue, 17 Nov 2020 at 03:45, Antonio Quartulli wrote: > > From: Antonio Quartulli > > The current interface limits the nonce 64bit, however, new users > may want to specify a 96bit nonce, as dictated by the > AEAD_CHACHA20_POLY1305 construction in RFC7539 Section 2.8. > > This patch changes the

Re: Re: realtek PHY commit bbc4d71d63549 causes regression

2020-11-14 Thread Ard Biesheuvel
On Sat, 14 Nov 2020 at 01:40, Andrew Lunn wrote: > > > One question that still has not been answered is how many actual > > platforms were fixed by backporting Realtek's follow up fix to > > -stable. My suspicion is none. That by itself should be enough > > justification to revert the backport of

Re: Re: realtek PHY commit bbc4d71d63549 causes regression

2020-11-13 Thread Ard Biesheuvel
On Fri, 13 Nov 2020 at 23:43, Andrew Lunn wrote: > > Hi Arnd > > > Something of that sort. I also see a similar patch in KSZ9031 > > now, see 7dd8f0ba88fc ("arm: dts: imx6qdl-udoo: fix rgmii phy-mode > > for ksz9031 phy") > > > > As this exact mismatch between rgmii and rgmii-id mode is apparently

Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-30 Thread Ard Biesheuvel
On Fri, 30 Oct 2020 at 04:22, Alexei Starovoitov wrote: > > On Thu, Oct 29, 2020 at 05:28:11PM -0700, Nick Desaulniers wrote: > > > > We already know that -fno-asynchronous-unwind-tables get dropped, > > hence this patch. > > On arm64 only. Not on x86 > > > And we know -fomit-frame-pointer or > >

Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-29 Thread Ard Biesheuvel
On Thu, 29 Oct 2020 at 21:35, Segher Boessenkool wrote: > > On Wed, Oct 28, 2020 at 10:57:45PM -0400, Arvind Sankar wrote: > > On Wed, Oct 28, 2020 at 04:20:01PM -0700, Alexei Starovoitov wrote: > > > All compilers have bugs. Kernel has bugs. What can go wrong? > > Heh. > > > +linux-toolchains. GC

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-29 Thread Ard Biesheuvel
On Thu, 29 Oct 2020 at 15:39, Andrew Lunn wrote: > > > What about reverting the realtek PHY commit from stable? > > As Ard said it doesn't really fix anything (usage wise) and causes a bunch > > of > > problems. > > > > If I understand correctly we have 3 options: > > 1. 'Hack' the drivers in st

[PATCH v2 0/2] get rid of GCC __attribute__((optimize)) for BPF

2020-10-28 Thread Ard Biesheuvel
voitov Cc: Daniel Borkmann Cc: Peter Zijlstra (Intel) Cc: Geert Uytterhoeven Cc: Kees Cook Ard Biesheuvel (2): bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE bpf: move interpreter into separate source file include/linux/compiler-gcc.h | 2 - include/linux/compile

Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-28 Thread Ard Biesheuvel
On Wed, 28 Oct 2020 at 00:04, Daniel Borkmann wrote: > > On 10/27/20 9:57 PM, Ard Biesheuvel wrote: > > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for > > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a > > function scope

Re: [PATCH] tools/perf: Remove broken __no_tail_call attribute

2020-10-28 Thread Ard Biesheuvel
On Wed, 28 Oct 2020 at 09:11, Peter Zijlstra wrote: > > On Tue, Oct 27, 2020 at 04:11:27PM -0700, Nick Desaulniers wrote: > > On Tue, Oct 27, 2020 at 4:04 PM Daniel Borkmann > > wrote: > > > > > > On 10/27/20 9:57 PM, Ard Biesheuvel wrote: > > > >

Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-28 Thread Ard Biesheuvel
On Wed, 28 Oct 2020 at 07:51, Ard Biesheuvel wrote: > > On Wed, 28 Oct 2020 at 00:04, Daniel Borkmann wrote: > > > > On 10/27/20 9:57 PM, Ard Biesheuvel wrote: > > > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for > > > ___bpf_prog_r

Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-28 Thread Ard Biesheuvel
On Wed, 28 Oct 2020 at 23:59, Alexei Starovoitov wrote: > > On Wed, Oct 28, 2020 at 11:15:04PM +0100, Ard Biesheuvel wrote: > > On Wed, 28 Oct 2020 at 22:39, Alexei Starovoitov > > wrote: > > > > > > On Wed, Oct 28, 2020 at 06:15:05PM +0100, Ard Biesheuvel w

Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-28 Thread Ard Biesheuvel
On Wed, 28 Oct 2020 at 22:39, Alexei Starovoitov wrote: > > On Wed, Oct 28, 2020 at 06:15:05PM +0100, Ard Biesheuvel wrote: > > Commit 3193c0836 ("bpf: Disable GCC -fgcse optimization for > > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a >

[PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-28 Thread Ard Biesheuvel
prog_run()") Link: https://lore.kernel.org/lkml/CAMuHMdUg0WJHEcq6to0-eODpXPOywLot6UD2=gfhpzoj_hc...@mail.gmail.com/ Signed-off-by: Ard Biesheuvel --- include/linux/compiler-gcc.h | 2 -- include/linux/compiler_types.h | 4 kernel/bpf/Makefile| 6 +- kernel/bpf/core.c

[PATCH v2 2/2] bpf: move interpreter into separate source file

2020-10-28 Thread Ard Biesheuvel
To reduce the impact of disabling certain compiler optimizations that are only needed for the interpreter, move it into its own source file, and apply the compiler command line override only to this file. Signed-off-by: Ard Biesheuvel --- include/linux/filter.h | 1 + kernel/bpf/Makefile

Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-27 Thread Ard Biesheuvel
On Tue, 27 Oct 2020 at 23:03, Nick Desaulniers wrote: > > On Tue, Oct 27, 2020 at 2:50 PM Ard Biesheuvel wrote: > > > > On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers > > wrote: > > > > > > On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:

Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-27 Thread Ard Biesheuvel
On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers wrote: > > On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote: > > > > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for > > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to

[PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE

2020-10-27 Thread Ard Biesheuvel
Nick Desaulniers Cc: Arvind Sankar Cc: Randy Dunlap Cc: Josh Poimboeuf Cc: Thomas Gleixner Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Peter Zijlstra (Intel) Cc: Geert Uytterhoeven Cc: Kees Cook Fixes: 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for ___bpf_prog_r

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-25 Thread Ard Biesheuvel
On Sun, 25 Oct 2020 at 15:29, Andrew Lunn wrote: > > On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote: > > On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote: > > > > > > > However, that leaves the question why bbc4d71d63549bcd was backported, >

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-25 Thread Ard Biesheuvel
On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote: > > > However, that leaves the question why bbc4d71d63549bcd was backported, > > although I understand why the discussion is a bit trickier there. But > > if it did not fix a regression, only broken code that never worked in > > the first place, I a

Re: [PATCH net] netsec: ignore 'phy-mode' device property on ACPI systems

2020-10-20 Thread Ard Biesheuvel
On Tue, 20 Oct 2020 at 14:49, Andrew Lunn wrote: > > > I hope Andrew is fine with the current changes > > Yes, i'm O.K. with it. Thanks > Making phy-mode optional would just make the > driver more uniform with others. > Making phy-mode optional is fine with me, but I think it would belong in a

Re: [PATCH net] netsec: ignore 'phy-mode' device property on ACPI systems

2020-10-18 Thread Ard Biesheuvel
On Sun, 18 Oct 2020 at 22:32, Ilias Apalodimas wrote: > > On Sun, Oct 18, 2020 at 07:52:18PM +0200, Andrew Lunn wrote: > > > --- a/Documentation/devicetree/bindings/net/socionext-netsec.txt > > > +++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt > > > @@ -30,7 +30,9 @@ Optional prop

[PATCH net] netsec: ignore 'phy-mode' device property on ACPI systems

2020-10-18 Thread Ard Biesheuvel
asami Hiramatsu Cc: Andrew Lunn Cc: Willy Liu Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Masahisa Kojima Cc: Serge Semin Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Ard Biesheuvel --- Related discussion here: https://lore.ker

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-18 Thread Ard Biesheuvel
On Sun, 18 Oct 2020 at 12:35, Ard Biesheuvel wrote: > > On Sun, 18 Oct 2020 at 01:02, Andrew Lunn wrote: > > > > On Sun, Oct 18, 2020 at 12:19:25AM +0200, Ard Biesheuvel wrote: > > > (cc'ing some folks who may care about functional networking on SynQuacer) >

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-18 Thread Ard Biesheuvel
On Sun, 18 Oct 2020 at 01:02, Andrew Lunn wrote: > > On Sun, Oct 18, 2020 at 12:19:25AM +0200, Ard Biesheuvel wrote: > > (cc'ing some folks who may care about functional networking on SynQuacer) > > > > On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote: > > >

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-17 Thread Ard Biesheuvel
(cc'ing some folks who may care about functional networking on SynQuacer) On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote: > > > So we can fix this firmware by just setting phy-mode to the empty > > string, right? > > I've never actually tried it, but i think so. There are no DT files > actually

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-17 Thread Ard Biesheuvel
On Sat, 17 Oct 2020 at 20:27, Andrew Lunn wrote: > > On Sat, Oct 17, 2020 at 08:11:24PM +0200, Ard Biesheuvel wrote: > > On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote: > > > > > > > I have tried this, and it seems to fix the issue. I will send out a > &

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-17 Thread Ard Biesheuvel
On Sat, 17 Oct 2020 at 20:11, Ard Biesheuvel wrote: > > On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote: > > > > > I have tried this, and it seems to fix the issue. I will send out a > > > patch against the netsec driver. > > > > Please also fix the firm

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-17 Thread Ard Biesheuvel
On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote: > > > I have tried this, and it seems to fix the issue. I will send out a > > patch against the netsec driver. > > Please also fix the firmware so it does not pass rgmii. > > If there are pure DT systems, which do require phy-mode to be used, we > w

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-17 Thread Ard Biesheuvel
On Sat, 17 Oct 2020 at 18:14, Ilias Apalodimas wrote: > > Hi Ard, > > On Sat, Oct 17, 2020 at 05:18:16PM +0200, Ard Biesheuvel wrote: > > On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote: > > > > > > On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrot

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-17 Thread Ard Biesheuvel
On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote: > > On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote: > > On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote: > > > > > > On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote: > > > >

Re: realtek PHY commit bbc4d71d63549 causes regression

2020-10-17 Thread Ard Biesheuvel
On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote: > > On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote: > > Hello all, > > > > I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network > > connectivity. > > Hi Ard > > Please coul

realtek PHY commit bbc4d71d63549 causes regression

2020-10-17 Thread Ard Biesheuvel
Hello all, I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network connectivity. This box has a on-SoC socionext 'netsec' network controller wired to a Realtek 80211e PHY, and this was working without problems until the following commit was merged commit bbc4d71d63549bcd003a430de18a

Re: [PATCH] gss_krb5: Fix memleak in krb5_make_rc4_seq_num

2020-08-31 Thread Ard Biesheuvel
On Sat, 29 Aug 2020 at 18:43, J. Bruce Fields wrote: > > This code is rarely if ever used, and there are pending patches to > remove it completely, so I don't think it's worth trying to fix a rare > memory leak at this point. > > --b. > FYI I just submitted v3 of my series removing this code to t

[PATCH v3 5/7] crypto: bcm-iproc - remove ecb(arc4) support

2020-08-31 Thread Ard Biesheuvel
Signed-off-by: Ard Biesheuvel --- drivers/crypto/bcm/cipher.c | 96 +--- drivers/crypto/bcm/cipher.h | 1 - drivers/crypto/bcm/spu.c| 23 + drivers/crypto/bcm/spu.h| 1 - drivers/crypto/bcm/spu2.c | 12 +-- drivers/crypto/bcm/spu2.h | 1 - 6 files changed, 6

[PATCH v3 7/7] crypto: arc4 - mark ecb(arc4) skcipher as obsolete

2020-08-31 Thread Ard Biesheuvel
eless/iwd.git/commit/?id=1db8a85a60c64523 [1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2 [2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b Signed-off-by: Ard Biesheuvel --- crypto/Kconfig | 10 ++ crypto/arc4.c | 10

[PATCH v3 3/7] SUNRPC: remove RC4-HMAC-MD5 support from KerberosV

2020-08-31 Thread Ard Biesheuvel
nly adversely affect interoperability with Windows NT/2000 systems that have not received any updates since 2008 (but are connected to a network nonetheless) [0] https://tools.ietf.org/html/rfc4757 [1] https://tools.ietf.org/html/rfc8429 Signed-off-by: Ard Biesheuvel Acked-by: J. Bruce Fields --- include/l

[PATCH v3 6/7] net: wireless: drop bogus CRYPTO_xxx Kconfig selects

2020-08-31 Thread Ard Biesheuvel
Drop some bogus Kconfig selects that are not entirely accurate, and unnecessary to begin with, since the same Kconfig options also select LIB80211 features that already imply the selected functionality (AES for CCMP, ARC4 and ECB for TKIP) Signed-off-by: Ard Biesheuvel --- drivers/net/wireless

[PATCH v3 2/7] staging/rtl8192u: switch to RC4 library interface

2020-08-31 Thread Ard Biesheuvel
Switch to the ARC4 library interface, to remove the pointless dependency on the skcipher API, from which we will hopefully be able to drop ecb(arc4) skcipher support. Signed-off-by: Ard Biesheuvel Acked-by: Greg Kroah-Hartman --- drivers/staging/rtl8192u/Kconfig | 1

[PATCH v3 1/7] staging/rtl8192e: switch to RC4 library interface

2020-08-31 Thread Ard Biesheuvel
Switch to the ARC4 library interface, to remove the pointless dependency on the skcipher API, from which we will hopefully be able to drop ecb(arc4) skcipher support. Signed-off-by: Ard Biesheuvel Acked-by: Greg Kroah-Hartman --- drivers/staging/rtl8192e/Kconfig | 4 +- drivers

[PATCH v3 4/7] crypto: n2 - remove ecb(arc4) support

2020-08-31 Thread Ard Biesheuvel
Signed-off-by: Ard Biesheuvel --- drivers/crypto/n2_core.c | 46 1 file changed, 46 deletions(-) diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c index d8aec5153b21..8c8e17d5fb20 100644 --- a/drivers/crypto/n2_core.c +++ b/drivers/crypto/n2_core.c @@ -662,7

[PATCH v3 0/7] crypto: mark ecb(arc4) skcipher as obsolete

2020-08-31 Thread Ard Biesheuvel
lds" Cc: Chuck Lever Cc: Eric Biggers Cc: Arnd Bergmann Cc: linux-cry...@vger.kernel.org Cc: netdev@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: linux-...@vger.kernel.org Ard Biesheuvel (7): staging/rtl8192e: switch to RC4 library interface staging/rtl8192u: switch to RC4 library

[PATCH v2 1/7] staging/rtl8192e: switch to RC4 library interface

2020-08-24 Thread Ard Biesheuvel
Switch to the ARC4 library interface, to remove the pointless dependency on the skcipher API, from which we will hopefully be able to drop ecb(arc4) skcipher support. Signed-off-by: Ard Biesheuvel Acked-by: Greg Kroah-Hartman --- drivers/staging/rtl8192e/Kconfig | 4 +- drivers

[PATCH v2 5/7] crypto: bcm-iproc - remove ecb(arc4) support

2020-08-24 Thread Ard Biesheuvel
Signed-off-by: Ard Biesheuvel --- drivers/crypto/bcm/cipher.c | 96 +--- drivers/crypto/bcm/cipher.h | 1 - drivers/crypto/bcm/spu.c| 23 + drivers/crypto/bcm/spu.h| 1 - drivers/crypto/bcm/spu2.c | 12 +-- drivers/crypto/bcm/spu2.h | 1 - 6 files changed, 6

[PATCH v2 6/7] net: wireless: drop bogus CRYPTO_xxx Kconfig selects

2020-08-24 Thread Ard Biesheuvel
Drop some bogus Kconfig selects that are not entirely accurate, and unnecessary to begin with, since the same Kconfig options also select LIB80211 features that already imply the selected functionality (AES for CCMP, ARC4 and ECB for TKIP) Signed-off-by: Ard Biesheuvel --- drivers/net/wireless

Re: [PATCH v2 7/7] crypto: arc4 - mark ecb(arc4) skcipher as obsolete

2020-08-24 Thread Ard Biesheuvel
On Mon, 24 Aug 2020 at 15:35, Herbert Xu wrote: > > On Mon, Aug 24, 2020 at 03:30:01PM +0200, Ard Biesheuvel wrote: > > > > +config CRYPTO_USER_ENABLE_OBSOLETE > > + bool "Enable obsolete cryptographic algorithms for userspace" > > + d

[PATCH v2 7/7] crypto: arc4 - mark ecb(arc4) skcipher as obsolete

2020-08-24 Thread Ard Biesheuvel
eless/iwd.git/commit/?id=1db8a85a60c64523 [1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2 [2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b Signed-off-by: Ard Biesheuvel --- crypto/Kconfig | 10 ++ crypto/arc4.c | 10

[PATCH v2 4/7] crypto: n2 - remove ecb(arc4) support

2020-08-24 Thread Ard Biesheuvel
Signed-off-by: Ard Biesheuvel --- drivers/crypto/n2_core.c | 46 1 file changed, 46 deletions(-) diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c index d8aec5153b21..8c8e17d5fb20 100644 --- a/drivers/crypto/n2_core.c +++ b/drivers/crypto/n2_core.c @@ -662,7

[PATCH v2 2/7] staging/rtl8192u: switch to RC4 library interface

2020-08-24 Thread Ard Biesheuvel
Switch to the ARC4 library interface, to remove the pointless dependency on the skcipher API, from which we will hopefully be able to drop ecb(arc4) skcipher support. Signed-off-by: Ard Biesheuvel Acked-by: Greg Kroah-Hartman --- drivers/staging/rtl8192u/Kconfig | 1

[PATCH v2 3/7] SUNRPC: remove RC4-HMAC-MD5 support from KerberosV

2020-08-24 Thread Ard Biesheuvel
nly adversely affect interoperability with Windows NT/2000 systems that have not received any updates since 2008 (but are connected to a network nonetheless) [0] https://tools.ietf.org/html/rfc4757 [1] https://tools.ietf.org/html/rfc8429 Signed-off-by: Ard Biesheuvel Acked-by: J. Bruce Fields --- include/l

[PATCH v2 0/7] crypto: mark ecb(arc4) skcipher as obsolete

2020-08-24 Thread Ard Biesheuvel
driverdev.osuosl.org Cc: linux-...@vger.kernel.org Ard Biesheuvel (7): staging/rtl8192e: switch to RC4 library interface staging/rtl8192u: switch to RC4 library interface SUNRPC: remove RC4-HMAC-MD5 support from KerberosV crypto: n2 - remove ecb(arc4) support crypto: bcm-iproc - remove ecb(arc4) suppo

Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API

2020-08-04 Thread Ard Biesheuvel
On Sat, 25 Jul 2020 at 10:06, Ard Biesheuvel wrote: > > On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote: > > > > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > > > > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > > >

Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API

2020-07-25 Thread Ard Biesheuvel
On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote: > > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > >

Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API

2020-07-18 Thread Ard Biesheuvel
On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > &

Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API

2020-07-02 Thread Ard Biesheuvel
On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > > Remove t

Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API

2020-07-02 Thread Ard Biesheuvel
On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from > > a maintenance pe

[RFC PATCH 0/7] crypto: get rid of ecb(arc4)

2020-07-02 Thread Ard Biesheuvel
.@driverdev.osuosl.org Cc: linux-...@vger.kernel.org Ard Biesheuvel (7): staging/rtl8192e: switch to RC4 library interface staging/rtl8192u: switch to RC4 library interface SUNRPC: remove RC4-HMAC-MD5 support from KerberosV crypto: remove ARC4 support from the skcipher API crypto: n2 -

[RFC PATCH 6/7] crypto: bcm-iproc - remove ecb(arc4) support

2020-07-02 Thread Ard Biesheuvel
Signed-off-by: Ard Biesheuvel --- drivers/crypto/bcm/cipher.c | 96 +--- drivers/crypto/bcm/cipher.h | 1 - drivers/crypto/bcm/spu.c| 23 + drivers/crypto/bcm/spu.h| 1 - drivers/crypto/bcm/spu2.c | 12 +-- drivers/crypto/bcm/spu2.h | 1 - 6 files changed, 6

[RFC PATCH 2/7] staging/rtl8192u: switch to RC4 library interface

2020-07-02 Thread Ard Biesheuvel
Switch to the ARC4 library interface, to remove the pointless dependency on the skcipher API, from which we will hopefully be able to drop ecb(arc4) skcipher support. Signed-off-by: Ard Biesheuvel --- drivers/staging/rtl8192u/Kconfig | 1 + drivers/staging/rtl8192u

[RFC PATCH 7/7] crypto: tcrypt - remove ecb(arc4) testing/benchmarking support

2020-07-02 Thread Ard Biesheuvel
Signed-off-by: Ard Biesheuvel --- crypto/tcrypt.c | 21 +-- crypto/testmgr.c | 7 --- crypto/testmgr.h | 62 3 files changed, 1 insertion(+), 89 deletions(-) diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c index ba0b7702f2e9..72828c4acd3a 100644 --- a/crypto/tcrypt.c

[RFC PATCH 5/7] crypto: n2 - remove ecb(arc4) support

2020-07-02 Thread Ard Biesheuvel
Signed-off-by: Ard Biesheuvel --- drivers/crypto/n2_core.c | 46 1 file changed, 46 deletions(-) diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c index 6a828bbecea4..c347e58cd9a1 100644 --- a/drivers/crypto/n2_core.c +++ b/drivers/crypto/n2_core.c @@ -662,7

[RFC PATCH 1/7] staging/rtl8192e: switch to RC4 library interface

2020-07-02 Thread Ard Biesheuvel
Switch to the ARC4 library interface, to remove the pointless dependency on the skcipher API, from which we will hopefully be able to drop ecb(arc4) skcipher support. Signed-off-by: Ard Biesheuvel --- drivers/staging/rtl8192e/Kconfig | 4 +- drivers/staging/rtl8192e

[RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API

2020-07-02 Thread Ard Biesheuvel
we have in the tree, we can safely drop this code now it no longer has any users. Signed-off-by: Ard Biesheuvel --- crypto/Kconfig | 12 crypto/Makefile | 1 - crypto/arc4.c| 76

[RFC PATCH 3/7] SUNRPC: remove RC4-HMAC-MD5 support from KerberosV

2020-07-02 Thread Ard Biesheuvel
nly adversely affect interoperability with Windows NT/2000 systems that have not received any updates since 2008 (but are connected to a network nonetheless) [0] https://tools.ietf.org/html/rfc4757 [1] https://tools.ietf.org/html/rfc8429 Signed-off-by: Ard Biesheuvel --- include/linux/sunrpc/gss_k

Re: [PATCH v2] net: phy: mscc: avoid skcipher API for single block AES encryption

2020-06-25 Thread Ard Biesheuvel
On Thu, 25 Jun 2020 at 21:16, David Miller wrote: > > From: Ard Biesheuvel > Date: Thu, 25 Jun 2020 09:18:16 +0200 > > > The skcipher API dynamically instantiates the transformation object > > on request that implements the requested algorithm optimally on the > >

[PATCH v2] net: phy: mscc: avoid skcipher API for single block AES encryption

2020-06-25 Thread Ard Biesheuvel
Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Fixes: 28c5107aa904e ("net: phy: mscc: macsec support") Reviewed-by: Eric Biggers Signed-off-by: Ard Biesheuvel --- v2: - select CRYPTO_LIB_AES only if MACSEC is enabled - add Eric's R-b drivers/net/phy/Kconfig

Re: [PATCH] net: phy: mscc: avoid skcipher API for single block AES encryption

2020-06-24 Thread Ard Biesheuvel
On Wed, 24 Jun 2020 at 18:32, Eric Biggers wrote: > > On Wed, Jun 24, 2020 at 03:34:27PM +0200, Ard Biesheuvel wrote: > > The skcipher API dynamically instantiates the transformation object on > > request that implements the requested algorithm optimally on the given > >

[PATCH] net: phy: mscc: avoid skcipher API for single block AES encryption

2020-06-24 Thread Ard Biesheuvel
Kallweit Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Fixes: 28c5107aa904e ("net: phy: mscc: macsec support") Signed-off-by: Ard Biesheuvel --- drivers/net/phy/Kconfig| 3 +- drivers/net/phy/mscc/mscc_macsec.c | 40 +--- 2 files changed,

Re: [PATCH] MAINTAINERS: update netsec driver

2019-07-18 Thread Ard Biesheuvel
On Thu, 18 Jul 2019 at 16:52, Jassi Brar wrote: > > On Thu, 18 Jul 2019 at 09:38, Ilias Apalodimas > wrote: > > > > Add myself to maintainers since i provided the XDP and page_pool > > implementation > > > Yes, please. > > Acked-by: Jassi Brar > Acked-by: Ard Biesheuvel

Re: [net-next, PATCH 2/2] net: netsec: remove loops in napi Rx process

2019-06-19 Thread Ard Biesheuvel
t; looping over the function. > Since it has no performance penalty let's remove that and simplify the Rx > path a bit > > Signed-off-by: Ilias Apalodimas Acked-by: Ard Biesheuvel > --- > drivers/net/ethernet/socionext/netsec.c | 11 ++- > 1 file changed, 2 inser

Re: [net-next, PATCH 1/2] net: netsec: initialize tx ring on ndo_open

2019-06-19 Thread Ard Biesheuvel
the > value is not correctly initialized the device won't have any available > descriptors > > Fixes: 35e07d23473972b8876f98bcfc631ebcf779e870 ("net: socionext: remove mmio > reads on Tx") > > Signed-off-by: Ilias Apalodimas Acked-by: Ard Biesheuvel >

Re: [PATCH] net: socionext: replace napi_alloc_frag with the netdev variant on init

2019-04-19 Thread Ard Biesheuvel
napi variant of the call is supposed to be used under softirq context > only > Helpful, thanks. In general, commit logs need to describe *why* you do something, since *what* you do is usually obvious from the patch itself, but why you do it isn't. With the above clarification added

Re: [PATCH] net: socionext: replace napi_alloc_frag with the netdev variant on init

2019-04-18 Thread Ard Biesheuvel
On Thu, 18 Apr 2019 at 11:27, Ilias Apalodimas wrote: > > Use netdev_alloc_frag during the Rx ring setup instead napi_alloc_frag > Why? > Fixes: 4acb20b46214 ("net: socionext: different approach on DMA") > Signed-off-by: Ilias Apalodimas > --- > drivers/net/ethernet/socionext/netsec.c | 11 +++

Re: [PATCH] arm64: do_csum: implement accelerated scalar version

2019-02-28 Thread Ard Biesheuvel
On Thu, 28 Feb 2019 at 16:14, Robin Murphy wrote: > > Hi Ard, > > On 28/02/2019 14:16, Ard Biesheuvel wrote: > > (+ Catalin) > > > > On Tue, 19 Feb 2019 at 16:08, Ilias Apalodimas > > wrote: > >> > >> On Tue, Feb 19, 2019 at 12:08:42AM +0100

Re: [PATCH] arm64: do_csum: implement accelerated scalar version

2019-02-28 Thread Ard Biesheuvel
(+ Catalin) On Tue, 19 Feb 2019 at 16:08, Ilias Apalodimas wrote: > > On Tue, Feb 19, 2019 at 12:08:42AM +0100, Ard Biesheuvel wrote: > > It turns out that the IP checksumming code is still exercised often, > > even though one might expect that modern NICs with checksum offlo

Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes

2019-02-27 Thread Ard Biesheuvel
On Wed, 27 Feb 2019 at 11:02, Marc Zyngier wrote: > > + Lorenzo > > Hi Brian, > > On 26/02/2019 23:28, Brian Norris wrote: > > + others > > > > Hi Marc, > > > > Thanks for the series. I have a few bits of history to add to this, and > > some comments. > > > > On Sun, Feb 24, 2019 at 02:04:22PM +00

Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes

2019-02-26 Thread Ard Biesheuvel
On Mon, 25 Feb 2019 at 15:53, Marc Zyngier wrote: > > Hi Ard, > > On 25/02/2019 12:45, Ard Biesheuvel wrote: > > On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote: > >> > >> For quite some time, I wondered why the PCI mwifiex device built in my > >&

Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes

2019-02-25 Thread Ard Biesheuvel
On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote: > > For quite some time, I wondered why the PCI mwifiex device built in my > Chromebook was unable to use the good old legacy interrupts. But as MSIs > were working fine, I never really bothered investigating. I finally had a > look, and the result

[PATCH] arm64: do_csum: implement accelerated scalar version

2019-02-18 Thread Ard Biesheuvel
size > 64 bytes, in order to reduce the number of branches and improve performance on cores with deep pipelines. On Cortex-A57, this implementation is on par with Lingyan's NEON implementation, and roughly 7x as fast as the generic C code. Cc: "huanglingyan (A)" Signed-off-

Re: [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Ard Biesheuvel
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote: > > On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote: > > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: > > > Variables declared in a switch statement before any case statements > > > cannot be initialized, so move all instances out of the

Re: [PATCH v2 1/4] vmalloc: New flags for safe vfree on special perms

2018-12-22 Thread Ard Biesheuvel
On Fri, 21 Dec 2018 at 20:57, Edgecombe, Rick P wrote: > > On Fri, 2018-12-21 at 18:25 +0100, Ard Biesheuvel wrote: > > On Fri, 21 Dec 2018 at 18:12, Andy Lutomirski > > wrote: > > > > On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel < > > > > ard.biesh

Re: [PATCH v2 1/4] vmalloc: New flags for safe vfree on special perms

2018-12-21 Thread Ard Biesheuvel
On Fri, 21 Dec 2018 at 18:12, Andy Lutomirski wrote: > > > On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel > > wrote: > > > >> On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote: > >> > >> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe

Re: [PATCH v2 1/4] vmalloc: New flags for safe vfree on special perms

2018-12-21 Thread Ard Biesheuvel
On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote: > > On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe > wrote: > > > > This adds two new flags VM_IMMEDIATE_UNMAP and VM_HAS_SPECIAL_PERMS, for > > enabling vfree operations to immediately clear executable TLB entries to > > freed > > pages, and

Re: [net-next, PATCH 2/2] net: socionext: remove mmio reads on Tx

2018-12-14 Thread Ard Biesheuvel
On Fri, 14 Dec 2018 at 12:18, Ilias Apalodimas wrote: > > On Fri, Dec 14, 2018 at 11:59:00AM +0100, Ard Biesheuvel wrote: > > On Fri, 14 Dec 2018 at 09:59, Ilias Apalodimas > > wrote: > > > > > > Currently the driver issues 2 mmio reads to figure out the num

Re: [net-next, PATCH 2/2] net: socionext: remove mmio reads on Tx

2018-12-14 Thread Ard Biesheuvel
On Fri, 14 Dec 2018 at 09:59, Ilias Apalodimas wrote: > > Currently the driver issues 2 mmio reads to figure out the number of > transmitted packets and clean them. We can get rid of the expensive > reads since BIT 31 of the Tx descriptor can be used for that. > We can also remove the budget count

Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages

2018-12-06 Thread Ard Biesheuvel
On Thu, 6 Dec 2018 at 20:30, Will Deacon wrote: > > On Thu, Dec 06, 2018 at 08:23:20PM +0100, Ard Biesheuvel wrote: > > On Thu, 6 Dec 2018 at 20:21, Andy Lutomirski wrote: > > > > > > On Thu, Dec 6, 2018 at 11:04 AM Ard Biesheuvel > > > wrote: > >

Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages

2018-12-06 Thread Ard Biesheuvel
On Thu, 6 Dec 2018 at 20:21, Andy Lutomirski wrote: > > On Thu, Dec 6, 2018 at 11:04 AM Ard Biesheuvel > wrote: > > > > On Thu, 6 Dec 2018 at 19:54, Andy Lutomirski wrote: > > > > > > > That’s not totally nuts. Do we ever have code that expects __v

Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages

2018-12-06 Thread Ard Biesheuvel
On Thu, 6 Dec 2018 at 19:54, Andy Lutomirski wrote: > > > On Dec 5, 2018, at 11:29 PM, Ard Biesheuvel > > wrote: > > > >> On Thu, 6 Dec 2018 at 00:16, Andy Lutomirski wrote: > >> > >>> On Wed, Dec 5, 2018 at 3:41 AM Will Deacon wrote: &g

Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages

2018-12-05 Thread Ard Biesheuvel
> > > such > > > > > > > as executable. > > > > > > > > > > > > So I am trying to finish my patch-set for preventing transient W+X > > > > > > mappings > > > > > > from taking space, by handling

Re: [PATCH v4 2/2] arm64/bpf: don't allocate BPF JIT programs in module memory

2018-12-04 Thread Ard Biesheuvel
On Mon, 3 Dec 2018 at 13:49, Will Deacon wrote: > > On Fri, Nov 30, 2018 at 08:20:06PM +0100, Ard Biesheuvel wrote: > > On Fri, 30 Nov 2018 at 19:26, Will Deacon wrote: > > > > > > On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote: > > > >

Re: [PATCH v4 2/2] arm64/bpf: don't allocate BPF JIT programs in module memory

2018-11-30 Thread Ard Biesheuvel
On Fri, 30 Nov 2018 at 19:26, Will Deacon wrote: > > On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote: > > The arm64 module region is a 128 MB region that is kept close to > > the core kernel, in order to ensure that relative branches are > > always in

[PATCH v4 0/2] bpf: permit JIT allocations to be served outside the module region

2018-11-23 Thread Ard Biesheuvel
c: Daniel Borkmann Cc: Alexei Starovoitov Cc: Rick Edgecombe Cc: Eric Dumazet Cc: Jann Horn Cc: Kees Cook Cc: Jessica Yu Cc: Arnd Bergmann Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: "David S. Miller" Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.ke

[PATCH v4 1/2] bpf: add __weak hook for allocating executable memory

2018-11-23 Thread Ard Biesheuvel
By default, BPF uses module_alloc() to allocate executable memory, but this is not necessary on all arches and potentially undesirable on some of them. So break out the module_alloc() and module_memfree() calls into __weak functions to allow them to be overridden in arch code. Signed-off-by: Ard

  1   2   3   >