Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-13 Thread Herbert Xu
On Tue, Dec 13, 2016 at 09:06:31AM -0800, Andy Lutomirski wrote: > > > Having 0 as type and CRYPTO_ALG_ASYNC as mask in general means > > that we're requesting a sync algorithm (i.e., ASYNC bit off). > > > > However, it is completely unnecessary for shash as they can never > > be async. So this

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-13 Thread Andy Lutomirski
On Mon, Dec 12, 2016 at 7:39 PM, Herbert Xu 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/sha.c:299 >> >

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-12 Thread Herbert Xu
On Mon, Dec 12, 2016 at 12:45:18PM -0600, Gary R Hook wrote: > On 12/12/2016 12:34 PM, Andy Lutomirski wrote: > > <...snip...> > > > > >I have a patch to make these depend on !VMAP_STACK. > > > >>drivers/crypto/ccp/ccp-crypto-aes-cmac.c:105,119,142 > >>

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-12 Thread Herbert Xu
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/sha.c:299 > > drivers/crypto/sahara.c:973,988 > > drivers/crypto/talitos.c:1910 > >

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-12 Thread Andy Lutomirski
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: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-11 Thread Eric Biggers
On Sun, Dec 11, 2016 at 11:13:55AM -0800, Andy Lutomirski wrote: > 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

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-11 Thread Andy Lutomirski
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

2016-12-10 Thread Andy Lutomirski
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: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-10 Thread Jason A. Donenfeld
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 think I'm going to add one. That's too bad to hear. I hope you'll reconsider. Modern cryptographic design is heading more and more

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-10 Thread Eric Biggers
On Sat, Dec 10, 2016 at 04:16:43PM +0800, Herbert Xu wrote: > Why did you drop me from the CC list when you were replying to > my email? > Sorry --- this thread is Cc'ed to the kernel-hardening mailing list (which was somewhat recently revived), and I replied to the email that reached me from

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

2016-12-10 Thread Herbert Xu
Why did you drop me from the CC list when you were replying to my email? Eric Biggers wrote: > On Sat, Dec 10, 2016 at 01:32:08PM +0800, Herbert Xu wrote: > >> Are you sure? Any instance of *_ON_STACK must only be used with >> sync algorithms and most drivers under

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

2016-12-09 Thread Eric Biggers
On Sat, Dec 10, 2016 at 01:37:12PM +0800, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > > Herbert, how hard would it be to teach the crypto code to use a more > > sensible data structure than scatterlist and to use coccinelle fix > > this stuff for

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-09 Thread Eric Biggers
On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > The following crypto drivers initialize a scatterlist to point into an > > ahash_request, which may have been allocated on the stack with > > AHASH_REQUEST_ON_STACK(): > > > > drivers/crypto/bfin_crc.c:351 > >

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-09 Thread Herbert Xu
On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > Herbert, how hard would it be to teach the crypto code to use a more > sensible data structure than scatterlist and to use coccinelle fix > this stuff for real? First of all we already have a sync non-SG hash interface, it's

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-09 Thread Herbert Xu
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(): > > > >

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-09 Thread Andy Lutomirski
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