lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 7 Sep 2018 08:56:23 +0200 From: Ard Biesheuvel <ard.biesheuvel@...aro.org> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: Kees Cook <keescook@...omium.org>, Eric Biggers <ebiggers@...gle.com>, Gilad Ben-Yossef <gilad@...yossef.com>, Alexander Stein <alexander.stein@...tec-electronic.com>, Antoine Tenart <antoine.tenart@...tlin.com>, Boris Brezillon <boris.brezillon@...tlin.com>, Arnaud Ebalard <arno@...isbad.org>, Corentin Labbe <clabbe.montjoie@...il.com>, Maxime Ripard <maxime.ripard@...tlin.com>, Chen-Yu Tsai <wens@...e.org>, Christian Lamparter <chunkeey@...il.com>, Philippe Ombredanne <pombredanne@...b.com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>, "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" <linux-crypto@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH v2 2/4] crypto: skcipher - Enforce non-ASYNC for on-stack requests On 7 September 2018 at 05:42, Herbert Xu <herbert@...dor.apana.org.au> wrote: > On Thu, Sep 06, 2018 at 03:58:52PM -0700, Kees Cook wrote: >> >> @@ -437,6 +442,12 @@ static inline struct crypto_skcipher *crypto_skcipher_reqtfm_check( >> { >> struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req); >> >> + if (req->__onstack) { >> + if (WARN_ON(crypto_skcipher_alg(tfm)->base.cra_flags & >> + CRYPTO_ALG_ASYNC)) >> + return ERR_PTR(-EINVAL); >> + } > > Sorry but I don't like imposing a run-time check on everybody when > stack-based requests are the odd ones out. If we're going to make > this a run-time check (I'd much prefer a compile-time check, but I > understand that this may involve too much churn), then please do it > for stack-based request users only. > OK, so given that all SKCIPHER_REQUEST_ON_STACK occurrences are updated in this series anyway, perhaps we should add skcipher_[en|de]crypt_onstack() flavors that encapsulate the additional check? Only question is how to enforce at compile time that those are used instead of the ordinary ones when using a stack allocated request. Would you mind using some macro foo here involving __builtin_types_compatible_p() ?
Powered by blists - more mailing lists