Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1539785
| From | Eric Biggers <ebiggers3@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK |
| Date | 2016-12-10 07:10 +0100 |
| Message-ID | <sMJ18-57L-13@gated-at.bofh.it> (permalink) |
| References | <sMCsG-UG-11@gated-at.bofh.it> <sMIoq-4xC-13@gated-at.bofh.it> <sMIy5-4AH-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sat, Dec 10, 2016 at 01:32:08PM +0800, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > > > The following crypto drivers initialize a scatterlist to point into an > > > ablkcipher_request, which may have been allocated on the stack with > > > SKCIPHER_REQUEST_ON_STACK(): > > > > > > drivers/crypto/ccp/ccp-crypto-aes-xts.c:162 > > > drivers/crypto/ccp/ccp-crypto-aes.c:94 > > > > These are real, and I wish I'd known about them sooner. > > Are you sure? Any instance of *_ON_STACK must only be used with > sync algorithms and most drivers under drivers/crypto declare > themselves as async. > Why exactly is that? Obviously, it wouldn't work if you returned from the stack frame before the request completed, but does anything stop someone from using an *_ON_STACK() request and then waiting for the request to complete before returning from the stack frame? Eric
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Remaining crypto API regressions with CONFIG_VMAP_STACK Eric Biggers <ebiggers3@gmail.com> - 2016-12-10 00:10 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Andy Lutomirski <luto@amacapital.net> - 2016-12-10 06:30 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Herbert Xu <herbert@gondor.apana.org.au> - 2016-12-10 06:40 +0100
Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Eric Biggers <ebiggers3@gmail.com> - 2016-12-10 07:10 +0100
Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Herbert Xu <herbert@gondor.apana.org.au> - 2016-12-10 09:20 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Eric Biggers <ebiggers3@gmail.com> - 2016-12-10 09:40 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Herbert Xu <herbert@gondor.apana.org.au> - 2016-12-10 06:40 +0100
Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Eric Biggers <ebiggers3@gmail.com> - 2016-12-10 07:40 +0100
Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-10 15:50 +0100
Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Andy Lutomirski <luto@amacapital.net> - 2016-12-10 18:50 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Eric Biggers <ebiggers3@gmail.com> - 2016-12-10 07:00 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Andy Lutomirski <luto@amacapital.net> - 2016-12-11 20:20 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Eric Biggers <ebiggers3@gmail.com> - 2016-12-12 00:40 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Andy Lutomirski <luto@amacapital.net> - 2016-12-12 19:40 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Herbert Xu <herbert@gondor.apana.org.au> - 2016-12-13 04:40 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Andy Lutomirski <luto@amacapital.net> - 2016-12-13 18:10 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Herbert Xu <herbert@gondor.apana.org.au> - 2016-12-14 06:00 +0100
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK Herbert Xu <herbert@gondor.apana.org.au> - 2016-12-13 04:50 +0100
csiph-web