[PATCH] aesni-intel: Merge with fpu.ko

for bugs like: https://bugzilla.redhat.com/show_bug.cgi?id=589390 Signed-off-by: Andy Lutomirski l...@mit.edu --- I'm not sure this is the best fix, but it seems to fix a longstanding bug. FWIW, I don't understand why the fpu module exists at all. arch/x86/crypto/Makefile |4

Re: [PATCH v2 2/2] crypto, x86: SSSE3 based SHA1 implementation for x86-64

On 08/04/2011 02:44 AM, Herbert Xu wrote: On Sun, Jul 24, 2011 at 07:53:14PM +0200, Mathias Krause wrote: With this algorithm I was able to increase the throughput of a single IPsec link from 344 Mbit/s to 464 Mbit/s on a Core 2 Quad CPU using the SSSE3 variant -- a speedup of +34.8%. Were

[PATCH] crypto_user: Fix out-of-bounds read

This is unlikely to be exploitable for anything except an OOPS. Cc: sta...@vger.kernel.org Signed-off-by: Andy Lutomirski l...@amacapital.net --- Notes: This is entirely untested, but it looks obviously correct to me. crypto/crypto_user.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH] crypto_user: Fix out-of-bounds read

On Apr 23, 2014 4:40 AM, Dan Carpenter dan.carpen...@oracle.com wrote: On Tue, Apr 22, 2014 at 12:30:28PM -0700, Andy Lutomirski wrote: This is unlikely to be exploitable for anything except an OOPS. Cc: sta...@vger.kernel.org Signed-off-by: Andy Lutomirski l...@amacapital.net

Re: [PATCH, RFC] random: introduce getrandom(2) system call

On 07/17/2014 02:18 AM, Theodore Ts'o wrote: The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD. The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks,

Re: [PATCH, RFC] random: introduce getrandom(2) system call

On 07/17/2014 11:48 AM, Mark Kettenis wrote: On Thu, Jul 17, 2014, Theodore Ts'o wrote: The getrandom(2) system call is a superset of getentropy(2). When we add the support for this into glibc, it won't be terribly difficult nor annoying to drop the following in alongside the standard

Re: [PATCH, RFC] random: introduce getrandom(2) system call

On Thu, Jul 17, 2014 at 2:28 PM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 01:35:15PM -0700, Andy Lutomirski wrote: Can we please have a mode in which getrandom(2) can neither block nor fail? If that gets added, then this can replace things like AT_RANDOM. AT_RANDOM has

Re: [PATCH -v5] random: introduce getrandom(2) system call

On Thu, Jul 24, 2014 at 8:18 AM, Henrique de Moraes Holschuh h...@hmh.eng.br wrote: On Thu, 24 Jul 2014, Theodore Ts'o wrote: ERRORS EINVAL An invalid flag was passed to getrandom(2) EFAULT buf is outside the accessible address space. EAGAIN The

Re: [PATCH -v5] random: introduce getrandom(2) system call

On Thu, Jul 24, 2014 at 1:30 PM, Henrique de Moraes Holschuh h...@hmh.eng.br wrote: On Thu, 24 Jul 2014, Theodore Ts'o wrote: On Thu, Jul 24, 2014 at 08:21:38AM -0700, Andy Lutomirski wrote: Should we add ESOMETHING to be able to deny access to GRND_RANDOM or some future extension

General flags to turn things off (getrandom, pid lookup, etc)

will propose a thread-sync flag. restrict_userspace requires either no_new_privs or CAP_SYS_ADMIN in the current user namespace. Thoughts? --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord

Re: General flags to turn things off (getrandom, pid lookup, etc)

On Fri, Jul 25, 2014 at 1:15 PM, Dave Jones da...@redhat.com wrote: On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote: There is recent interest in having a way to turn generally-available kernel features off. Maybe we should add a good one so we can stop bikeshedding

Re: General flags to turn things off (getrandom, pid lookup, etc)

On Fri, Jul 25, 2014 at 2:35 PM, One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: On Fri, 25 Jul 2014 11:30:48 -0700 Andy Lutomirski l...@amacapital.net wrote: [new thread because this sort of combines two threads] There is recent interest in having a way to turn generally-available

Re: General flags to turn things off (getrandom, pid lookup, etc)

On Fri, Jul 25, 2014 at 4:43 PM, H. Peter Anvin h...@zytor.com wrote: On 07/25/2014 11:30 AM, Andy Lutomirski wrote: - 32-bit GDT code segments [huge attack surface] - 64-bit GDT code segments [probably pointless] I presume you mean s/GDT/LDT/. We already don't allow 64-bit LDT code

Re: General flags to turn things off (getrandom, pid lookup, etc)

On Jul 27, 2014 5:06 PM, Theodore Ts'o ty...@mit.edu wrote: On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote: There is recent interest in having a way to turn generally-available kernel features off. Maybe we should add a good one so we can stop bikeshedding and avoid

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote: >> >> Is there a straightforward way that bluetooth and, potentially, other >> drivers can just do synchronous crypto

Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

net/bluetooth/smp.c (in smp_e) wants to do AES-ECB on a 16-byte stack buffer, which seems eminently reasonable to me. It does it like this: sg_init_one(, data, 16); skcipher_request_set_tfm(req, tfm); skcipher_request_set_callback(req, 0, NULL, NULL);

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu <herb...@gondor.apana.org.au> > wrote: >> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote: >>> >>> Is

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Wed, Jun 22, 2016 at 2:48 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu <herb...@gondor.apana.org.au> >> wrote: >>> On T

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Wed, Jun 22, 2016 at 11:41 PM, Herbert Xu wrote: > On Thu, Jun 23, 2016 at 11:48:25AM +0800, Herbert Xu wrote: >> >> No we never had such an API in the kernel. However, I see that >> rxkad does some pretty silly things and we should be able to avoid >> using the

Re: [PATCH 1/2] fscrypto: don't use on-stack buffer for filename encryption

On Nov 5, 2016 8:13 AM, "Kent Overstreet" wrote: > > On Thu, Nov 03, 2016 at 03:03:01PM -0700, Eric Biggers wrote: > > With the new (in 4.9) option to use a virtually-mapped stack > > (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for > > the

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

On Mon, Oct 17, 2016 at 10:17 AM, Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 17. Oktober 2016, 10:06:27 CEST schrieb Andy Lutomirski: > > Hi Andy, > >> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c >> index 920

Re: [PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

On Fri, Oct 21, 2016 at 1:48 PM, Laszlo Ersek wrote: > The virtio-rng backend for hwrng passes the buffer that it receives for > filling to sg_set_buf() directly, in: > > virtio_read() [drivers/char/hw_random/virtio-rng.c] > register_buffer()

Re: vmalloced stacks and scatterwalk_map_and_copy()

[Adding Thorsten to help keep this from getting lost] On Thu, Nov 3, 2016 at 1:30 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Thu, Nov 3, 2016 at 11:16 AM, Eric Biggers <ebigg...@google.com> wrote: >> Hello, >> >> I hit the BUG_ON() in arch/x86/mm/physad

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 3, 2016 at 11:16 AM, Eric Biggers wrote: > Hello, > > I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code > in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y: > > /* carry flag will be set if starting x was

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 3, 2016 at 4:10 PM, Eric Biggers <ebigg...@google.com> wrote: > On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote: >> On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: >> > >> > Also, Herbert, it seems like the considerable

Re: virtio-rng scatterlist null pointer dereference with VMAP_STACK=y

On Sun, Oct 16, 2016 at 9:59 AM, Andy Lutomirski <l...@amacapital.net> wrote: > On Sat, Oct 15, 2016 at 5:21 PM, Matt Mullins <mmull...@mmlx.us> wrote: >> With VMAP_STACK=y and HW_RANDOM_VIRTIO=y, I get the following crash: >> >> [1.470437] BUG: unable to handl

Re: virtio-rng scatterlist null pointer dereference with VMAP_STACK=y

t; VMAP_STACK) fails to be added to a scatterlist due to use of virt_to_page in > sg_set_buf(). > > None of this looks obviously wrong to me, but in combination it is not > functional. Hence, I don't have a particular fix in mind, and I've CC'ed > folks > from both the hw_random an

[PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

after device init") Signed-off-by: Andy Lutomirski <l...@kernel.org> --- This fixes a crash in 4.9-rc1. resending because I typoed the git send-email command. I stealthily added Matt's Tested-by, too. drivers/char/hw_random/core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deleti

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

On Mon, Oct 17, 2016 at 11:36 AM, Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski: > > Hi Andy, >> >> Sure, but shouldn't that be a separate patch covering the whole hw_crypto >> cor

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

cc: Viro because I'm talking about iov_iter. On Sat, Dec 10, 2016 at 6:45 AM, Jason A. Donenfeld wrote: > Hi Herbert, > > On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu > wrote: >> As for AEAD we never had a sync interface to begin with and I >> don't

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

On Mon, Dec 12, 2016 at 2:28 PM, David Howells <dhowe...@redhat.com> wrote: > Andy Lutomirski <l...@kernel.org> wrote: > >> +static const char zero_pad[16] = {0}; > > Isn't there a global page of zeros or something that we can share? Also, you > shouldn't explicit

Re: [PATCH] wusbcore: Fix one more crypto-on-the-stack bug

On Mon, Dec 12, 2016 at 1:44 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Mon, Dec 12, 2016 at 12:52:45PM -0800, Andy Lutomirski wrote: >> The driver put a constant buffer of all zeros on the stack and >> pointed a scatterlist entry at it. This doesn't work with vir

[PATCH v2] wusbcore: Fix one more crypto-on-the-stack bug

The driver put a constant buffer of all zeros on the stack and pointed a scatterlist entry at it. This doesn't work with virtual stacks. Use ZERO_PAGE instead. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers <ebigge...@gmail.com> Signed-off-by: Andy Lutomirski <l...@k

[PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

The driver put a constant buffer of all zeros on the stack and pointed a scatterlist entry at it in two places. This doesn't work with virtual stacks. Use ZERO_PAGE instead. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers <ebigge...@gmail.com> Signed-off-by: Andy Lutomir

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski <l...@kernel.org> wrote: > The driver put a constant buffer of all zeros on the stack and > pointed a scatterlist entry at it in two places. This doesn't work > with virtual stacks. Use ZERO_PAGE instead. Wait a second... >

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

[add some people who might know] On Tue, Dec 13, 2016 at 4:20 AM, David Laight <david.lai...@aculab.com> wrote: > From: Andy Lutomirski >> Sent: 12 December 2016 20:53 >> The driver put a constant buffer of all zeros on the stack and >> pointed a scatterlis

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Mon, Dec 12, 2016 at 7:39 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Mon, Dec 12, 2016 at 10:34:10AM -0800, Andy Lutomirski wrote: >> >> Here's my status. >> >> > drivers/crypto/bfin_crc.c:351 >> > drivers/crypto/qce/s

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo <kv...@codeaurora.org> wrote: > Andy Lutomirski <l...@kernel.org> writes: > >> Eric Biggers pointed out that the orinoco driver pointed scatterlists >> at the stack. >> >> Fix it by switching from ahash to shash

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

On Thu, Dec 15, 2016 at 7:03 PM, Jason A. Donenfeld wrote: > -static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash) > - __aligned(sizeof(unsigned long)); > +static DEFINE_PER_CPU(u64, get_random_int_chaining); > [...] > unsigned long

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to

[PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

ed-off-by: Andy Lutomirski <l...@kernel.org> --- security/keys/encrypted-keys/encrypted.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c index 17a06105ccb6..fab2fb864002 100644 --

[PATCH] wusbcore: Fix one more crypto-on-the-stack bug

The driver put a constant buffer of all zeros on the stack and pointed a scatterlist entry at it. This doesn't work with virtual stacks. Make the buffer static to fix it. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers <ebigge...@gmail.com> Signed-off-by: Andy Lutomir

[PATCH] cifs: Fix smbencrypt() to stop pointing a scatterlist at the stack

...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers <ebigge...@gmail.com> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- Compile-tested only. fs/cifs/smbencrypt.c | 40 1 file changed, 8 insertions(+), 32 deletions(-) diff --git a/fs/cifs/smben

[PATCH] crypto: Make a few drivers depend on !VMAP_STACK

<ebigge...@gmail.com> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- drivers/crypto/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 4d2b81f2b223..481e67e54ffd 100644 --- a/drivers/crypto/K

[PATCH] orinoco: Use shash instead of ahash for MIC calculations

Eric Biggers pointed out that the orinoco driver pointed scatterlists at the stack. Fix it by switching from ahash to shash. The result should be simpler, faster, and more correct. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers <ebigge...@gmail.com> Signed-off-by

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to

Re: x86-64: Maintain 16-byte stack alignment

rd. It also needs to be tested with and without frame pointers. > > So I'm not at all convinced that this is a good idea. We shouldn't > expect 16-byte alignment to be something trustworthy. > > Linus -- Andy Lutomirski AMA Capital Management, LLC -- To unsu

Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

On Wed, Jan 11, 2017 at 11:47 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > Andy Lutomirski <l...@kernel.org> wrote: >> There are some hashes (e.g. sha224) that have some internal trickery >> to make sure that only the correct number of output bytes are >&

Re: x86-64: Maintain 16-byte stack alignment

On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu wrote: > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: >> >> I'm pretty sure we have random asm code that may not maintain a >> 16-byte stack alignment when it calls other code (including, in some >>

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 10:01 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu <herb...@gondor.apana.org.au> > wrote: >> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote: >>> >>> That sai

[PATCH v2 3/8] crypto/sha256: Build the SHA256 core separately from the crypto module

This just moves code around -- no code changes in this patch. This wil let BPF-based tracing link against the SHA256 core code without depending on the crypto core. Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Herbert Xu <herb...@gondor.apana.org.au> Signed-off-by: Andy L

[PATCH v2 6/8] bpf: Rename fdinfo's prog_digest to prog_sha256

'. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- kernel/bpf/syscall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 12:00 PM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 10 January 2017 at 19:22, Andy Lutomirski <l...@amacapital.net> wrote: >> On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel >> <ard.biesheu...@linaro.org> wrote: >>> On

[PATCH v2 5/8] bpf: Avoid copying the entire BPF program when hashing it

be a considerable speedup as vmalloc() is quite slow. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- kernel/bpf/core.c | 33 + 1 file changed, 13 insertion

[PATCH v2 2/8] crypto/sha256: Export a sha256_{init,update,final}_direct() API

depend on crypto. Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Herbert Xu <herb...@gondor.apana.org.au> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- crypto/sha256_generic.c | 31 ++- include/crypto/sha.h | 24 +++

[PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

output size so that memory debugging will catch the error if the output is overrun. Tested by intentionally breaking sha224 to output all 256 internally-generated bits while running on KASAN. Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Herbert Xu <herb...@gondor.apana.org.au> Signed-

[PATCH v2 1/8] crypto/sha256: Factor out the parts of base API that don't use shash_desc

I want to expose a minimal SHA256 API that can be used without the depending on the crypto core. To prepare for this, factor out the meat of the sha256_base_*() helpers. Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Herbert Xu <herb...@gondor.apana.org.au> Signed-off-by: Andy L

[PATCH v2 0/8] Switch BPF's digest to SHA256

haven't yet because I wanted to minimize churn. Also, the changes will be essentially identical to the SHA-256 changes and I want to get the latter reviewed first. Andy Lutomirski (8): crypto/sha256: Factor out the parts of base API that don't use shash_desc crypto/sha256: Export

Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256

On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 01/11/2017 12:24 AM, Andy Lutomirski wrote: >> >> This makes it easier to add another digest algorithm down the road if >> needed. It also serves to force any programs that might h

Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

On Wed, Jan 11, 2017 at 7:13 AM, David Laight <david.lai...@aculab.com> wrote: > From: Andy Lutomirski >> Sent: 10 January 2017 23:25 >> There are some hashes (e.g. sha224) that have some internal trickery >> to make sure that only the correct number of output bytes are

Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256

On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann <dan...@iogearbox.net> wrote: > Hi Andy, > > On 01/11/2017 04:11 AM, Andy Lutomirski wrote: >> >> On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann <dan...@iogearbox.net> >> wrote: >>> &

Re: x86-64: Maintain 16-byte stack alignment

On Wed, Jan 11, 2017 at 12:09 AM, Herbert Xu wrote: > On Wed, Jan 11, 2017 at 08:06:54AM +, Ard Biesheuvel wrote: >> >> Couldn't we update the __aligned(x) macro to emit 32 if arch == x86 >> and x == 16? All other cases should work just fine afaict > > Not

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf <jpoim...@redhat.com> wrote: > On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf <jpoim...@redhat.com> wrote: >> > On Thu, Jan 12, 2017 at 12:08:07P

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf <jpoim...@redhat.com> wrote: > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds >> <torva...@linux-foundation.org> wrote: >> > On Thu, Jan 12, 20

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds wrote: > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote: >> >> Just to clarify, I think you're asking if, for versions of gcc which >> don't support -mpreferred-stack-boundary=3, objtool

[PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256

, as no released kernel has ever had TCA*BPF_DIGEST. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- include/uapi/linux/pkt_cls.h | 2 +- include/uapi/linux/tc_act/tc_bpf.h | 2 +- n

[PATCH v2 4/8] bpf: Use SHA256 instead of SHA1 for bpf digests

calling vmalloc(). I moved the digest field to keep all of the bpf program metadata in the same cache line. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- include/linux/filter.h | 11

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu wrote: > On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote: >> >> That said, I do think that the "don't assume stack alignment, do it by >> hand" may be the safer thing. Because who knows what the random rules

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 10 January 2017 at 19:00, Andy Lutomirski <l...@amacapital.net> wrote: >> On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel >> <ard.biesheu...@linaro.org> wrote: >>> On

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

: >>>> >>>> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > > [...] > >>>> The hashing is not a proper sha1 neither, unfortunately. I think that >>>> is why it will have a custom implementation in iproute2? >>> >>&g

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Fri, Dec 23, 2016 at 8:23 AM, Andy Lutomirski <l...@amacapital.net> wrote: > On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann <dan...@iogearbox.net> wrote: >> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote: >>> >>> On Fri, 2016-12-23 at 11:04 +0100, Da

[RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

involved. Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Herbert Xu <herb...@gondor.apana.org.au> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/arm/crypto/sha2-ce-glue.c | 10 --- arch/arm/crypto/sha256_glue.c | 23 ++- arch/arm/crypto/sha256

[RFC PATCH 4.10 3/6] bpf: Use SHA256 instead of SHA1 for bpf digests

in the same cache line. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- include/linux/filter.h | 11 +++ init/Kconfig | 1 + kernel/bpf/core.c | 41 +++---

[RFC PATCH 4.10 2/6] crypto/sha256: Make the sha256 library functions selectable

This will let other kernel code call into sha256_init(), etc. without pulling in the core crypto code. Signed-off-by: Andy Lutomirski <l...@kernel.org> --- crypto/Kconfig | 8 crypto/Makefile | 2 +- crypto/sha256_generic.c | 4 include/crypto/sha.h| 4 +

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Fri, Dec 23, 2016 at 6:22 PM, Andy Lutomirski <l...@kernel.org> wrote: > There are some pieecs of kernel code that want to compute SHA256 > directly without going through the crypto core. Adjust the exported > API to decouple it from the crypto core. > > I suspect this wil

[RFC PATCH 4.10 0/6] Switch BPF's digest to SHA256

for 4.10. If this series misses 4.10 and nothing takes its place, then we'll have an unpleasant ABI stability situation. Andy Lutomirski (6): crypto/sha256: Refactor the API so it can be used without shash crypto/sha256: Make the sha256 library functions selectable bpf: Use SHA256 instead of SHA1

[RFC PATCH 4.10 4/6] bpf: Avoid copying the entire BPF program when hashing it

be a considerable speedup as vmalloc() is quite slow. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- kernel/bpf/core.c | 34 ++ 1 file changed, 14 insertion

[RFC PATCH 4.10 6/6] net: Rename TCA*BPF_DIGEST to ..._SHA256

, as no released kernel has ever had TCA*BPF_DIGEST. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- include/uapi/linux/pkt_cls.h | 2 +- include/uapi/linux/tc_act/tc_bpf.h | 2 +- n

[RFC PATCH 4.10 5/6] bpf: Rename fdinfo's prog_digest to prog_sha256

'. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- kernel/bpf/syscall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c

Re: [RFC PATCH 4.10 3/6] bpf: Use SHA256 instead of SHA1 for bpf digests

On Mon, Dec 26, 2016 at 5:36 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Dec 24, 2016 at 08:59:53PM +0100, Daniel Borkmann wrote: >> On 12/24/2016 03:22 AM, Andy Lutomirski wrote: >> >BPF digests are intended to be used to avoid reloading progr

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Tue, Dec 27, 2016 at 6:16 AM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 12/27/2016 10:58 AM, Herbert Xu wrote: >> >> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: >>> >>> >>> According to Daniel, the networking fo

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 9:01 PM, George Spelvin <li...@sciencehorizons.net> wrote: > Andy Lutomirski wrote: >> I don't even think it needs that. This is just adding a >> non-destructive final operation, right? > > It is, but the problem is that SipHash is intend

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: >> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote: >> > On T

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 6:07 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin > <li...@sciencehorizons.net> wrote: >> As a separate message, to disentangle the threads, I'd like to >> talk about get_random_long(). >

BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: >> Hi Hannes, >> >> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa >> wrote: >> > IPv6 you cannot touch

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 8:28 AM, Jason A. Donenfeld wrote: > Hi all, > > I don't know what your design requirements are for this. It looks like > you're generating some kind of crypto digest of a program, and you > need to avoid collisions. If you'd like to go with a PRF (keyed

George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin wrote: > As a separate message, to disentangle the threads, I'd like to > talk about get_random_long(). > > After some thinking, I still like the "state-preserving" construct > that's equivalent to the current MD5 code.

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote: > unsigned int get_random_int(void) > { > - __u32 *hash; > - unsigned int ret; > - > - if (arch_get_random_int()) > - return ret; > - > - hash = get_cpu_var(get_random_int_hash); >

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Wed, Dec 21, 2016 at 6:07 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 22.12.2016 00:42, Andy Lutomirski wrote: >> On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: >>> unsigned int get_random_int(void)

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 9:25 AM, Linus Torvalds wrote: > On Wed, Dec 21, 2016 at 7:55 AM, George Spelvin > wrote: >> >> How much does kernel_fpu_begin()/kernel_fpu_end() cost? > > It's now better than it used to be, but it's absolutely

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Thu, Dec 22, 2016 at 11:24 AM, George Spelvin wrote: >> Having slept on this, I like it less. The problem is that a >> backtracking attacker doesn't just learn H(random seed || entropy_0 || >> secret || ...) -- they learn the internal state of the hash function >>

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 11:34 AM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Sat, Dec 24, 2016 at 2:33 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > Hi Andy, > > On 24 December 2016 at 02:22, Andy Lutomirski <l...@kernel.org> wrote: >> There are some pieecs of kernel code that want to compute SHA256 >> directly without going

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Mon, Dec 26, 2016 at 9:51 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 26 December 2016 at 07:57, Herbert Xu <herb...@gondor.apana.org.au> wrote: >> On Sat, Dec 24, 2016 at 09:57:53AM -0800, Andy Lutomirski wrote: >>> >>> I actually do

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 2:13 PM, George Spelvin wrote: >> What should we do with get_random_int() and get_random_long()? In >> some cases it's being used in performance sensitive areas, and where >> anti-DoS protection might be enough. In others, maybe not so much. >

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

On Fri, Dec 16, 2016 at 1:45 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > Hi Andy, > > On Fri, Dec 16, 2016 at 10:31 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> I think it would be nice to try to strenghen the PRNG construction. >> FWIW, I'm not an ex

Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

> On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai wrote: > > The SCTP program may sleep under a spinlock, and the function call path is: > sctp_generate_t3_rtx_event (acquire the spinlock) > sctp_do_sm >sctp_side_effects > sctp_cmd_interpreter >sctp_make_init_ack >

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

On Fri, Oct 13, 2017 at 12:09 PM, Linus Torvalds wrote: > On Fri, Oct 13, 2017 at 6:56 AM, Andrey Ryabinin > wrote: >> >> This could be fixed by s/vmovdqa/vmovdqu change like bellow, but maybe the >> right fix >> would be to align the data

Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

On Mon, Oct 2, 2017 at 10:26 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Mon, Oct 02, 2017 at 09:18:24PM -0700, Andy Lutomirski wrote: >> > On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai <baijiaju1...@163.com> wrote: >> > >> > The SCTP program may sle

  1   2   >