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
| ||
|
Message-ID: <20141115031549.GA19208@gondor.apana.org.au> Date: Sat, 15 Nov 2014 11:15:50 +0800 From: Herbert Xu <herbert@...dor.apana.org.au> To: Steffen Klassert <steffen.klassert@...unet.com> Cc: Ming Liu <ming.liu@...driver.com>, davem@...emloft.net, ying.xue@...driver.com, linux-crypto@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: > > Everything below the local_bh_enable() should not run in atomic context > as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEEP flag. Actually I'm thinking of doing exactly that (disabling softirq in cryptd) to fix the reordering problem. Most threads do not use the FPU/SIMD so cryptd is only ever needed when we have a user-space app that touches the FPU/SIMD which then gets an interrupt to perform crypto in softirq. So forcing cryptd on everyone just because some apps touch the FPU/SIMD is a non- starter. The most straightforward solution is to always defer to cryptd once it gets started. This is bad because if a rarely used app that touches FPU/SIMD runs then we'll end up stuck in cryptd long after the app goes away. So what I'm thinking of is to have the softirq path forcibly regain control from cryptd where possible. This is tricky because cryptd might be in the middle of processing a request. So that's why I'd like to disable softirqs while we're processing a request. Cheers, -- Email: Herbert Xu <herbert@...dor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists