Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
On Wed, Dec 28, 2016 at 07:50:44PM +, Ard Biesheuvel wrote: > > So about this chunksize, is it ever expected to assume other values > than 1 (for stream ciphers) or the block size (for block ciphers)? > Having block size, IV size *and* chunk size fields may be confusing to > some already, so if the purpose of chunk size can be fulfilled by a > single 'stream cipher' flag, perhaps we should change that first. For users (such as algif) it's much more convenient to have a size rather than a flag because that's what they need to determine the minimum size for partial updates. For implementors you don't need to specify the chunksize at all unless you're a stream cipher (or some other case in future where the minimum partial update size is not equal to your block size). Cheers, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
On 28 December 2016 at 09:23, Herbert Xu wrote: > On Wed, Dec 28, 2016 at 09:19:32AM +, Ard Biesheuvel wrote: >> >> Ok, so that implies a field in the skcipher algo struct then, rather than >> some definition internal to the driver? > > Oh yes it should definitely be visible to other crypto API drivers > and algorithms. It's just that we don't want to export it outside > of the crypto API, e.g., to IPsec or algif. > Understood. So about this chunksize, is it ever expected to assume other values than 1 (for stream ciphers) or the block size (for block ciphers)? Having block size, IV size *and* chunk size fields may be confusing to some already, so if the purpose of chunk size can be fulfilled by a single 'stream cipher' flag, perhaps we should change that first. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] /dev/random - a new approach (code for 4.10-rc1)
Hi, The patch set that can be downloaded at [1] provides a different approach to / dev/random which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time as well as in virtual environments and when using SSDs or Device Mapper targets. A secondary design goal is to limit the impact of the entropy collection on massive parallel systems and also allow the use accelerated cryptographic primitives. Also, all steps of the entropic data processing are testable. Finally performance improvements are visible at /dev/urandom and get_random_bytes. The design and implementation is driven by a set of goals described in [2] that the LRNG completely implements. Furthermore, [2] includes a comparison with RNG design suggestions such as SP800-90B, SP800-90C, and AIS20/31. [1] http://www.chronox.de/lrng.html [2] http://www.chronox.de/lrng/doc/lrng.pdf Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: simd ciphers
Am Mittwoch, 28. Dezember 2016, 18:28:26 CET schrieb Herbert Xu: Hi Herbert, > On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote: > > When I configure AES-NI as module, it works. When compiling it statically, > > the allocation returns an -ENOENT. > > > > Now, when I diff both config files after a simple toggle from AES-NI=y to > > =m I see (linux-4.10.config contains the static config, .config contains > > the module > > configuration): > Thanks Stephan! Does this patch help? This patch does not help. But I now found the issue: we need some Kconfig wizardry to mandate pcbc to be compiled statically when AES-NI is static. Currently I had pcbc always as a module even when selecting AES-NI as static compilation. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: qat - initialize cra_flags before register into kpp
On Thu, Dec 22, 2016 at 03:00:51PM +, Giovanni Cabiddu wrote: > Initialize dh.base.cra_flags before registering the dh algorithm. > Without this fix, the registration of the dh algorithm might fail > if the qat driver is restarted. > > Signed-off-by: Sushil Kumar > Signed-off-by: Giovanni Cabiddu Please patch the crypto API instead. I think unsetting the bit CRYPTO_ALG_DEAD at the top of crypto_register_alg should do the trick. Thanks, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: simd ciphers
On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote:
>
> When I configure AES-NI as module, it works. When compiling it statically,
> the
> allocation returns an -ENOENT.
>
> Now, when I diff both config files after a simple toggle from AES-NI=y to =m
> I
> see (linux-4.10.config contains the static config, .config contains the
> module
> configuration):
Thanks Stephan! Does this patch help?
---8<---
Subject: crypto: pcbc - Move pcbc registration up to subsys_initcall
The pcbc template is required by aesni. As aesni registers itself
at late_initcall, we have to make sure pcbc is registered before
that.
This patch moves it to subsys_initcall like cryptd.
Fixes: 85671860caac ("crypto: aesni - Convert to skcipher")
Reported-by: Stephan Müller
Signed-off-by: Herbert Xu
diff --git a/crypto/pcbc.c b/crypto/pcbc.c
index e4538e0..0855c61 100644
--- a/crypto/pcbc.c
+++ b/crypto/pcbc.c
@@ -307,7 +307,7 @@ static void __exit crypto_pcbc_module_exit(void)
crypto_unregister_template(&crypto_pcbc_tmpl);
}
-module_init(crypto_pcbc_module_init);
+subsys_initcall(crypto_pcbc_module_init);
module_exit(crypto_pcbc_module_exit);
MODULE_LICENSE("GPL");
--
Email: Herbert Xu
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 linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)
Hannes Frederic Sowa wrote: > We call extract_crng when we run out of batched entropy and reseed. How > often we call down to extract_crng depends on how much entropy we > extracted by calls to get_random_int/long, so the number of calls into > those functions matter. > > In extract_crng we have a timer which reseeds every 300s the CPRNG and > either uses completely new entropy from the CRNG or calls down into the > CPRNG while also doing backtracing protection (which feeds chacha's > block size / 2 back into chacha, if I read the code correctly, thus > 1024 bits, which should be enough). In the current code, _extract_crng checks to see if more than 300 s have elapsed since last time it was reseeded, and if so, reseeds with fresh entropy. In addition, on every read (or get_random_bytes), if the request leaves enough ranfom bits in the last ChaCha block, it feeds back 256 bits (the ChaCha block size is 16*32 = 512 bits) for anti-backtracking. If the last read happened to not fit under that limit (size % 512 > 256), *and* there are no calls for RNG output for a long time, there is no upper limit to how long the old ChaCha key can hang around. > On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote: >> For example, two mix-backs of 64 bits gives you 65 bit security, not 128. >> (Because each mixback can be guessed and verified separately.) > Exactly, but the full reseed after running out of entropy is strong > enough to not be defeated by your argumentation. Neither the reseed > from the CRNG. Yes, I was just reacting to your original statement: > couldn't we simply use 8 bytes of the 64 byte > return block to feed it directly back into the state chacha? It's not the idea that's bad, just the proposed quantity. >> If you want that, I have a pile of patches to prandom I really >> should push upstream. Shall I refresh them and send them to you? > I would like to have a look at them in the new year, certainly! I can > also take care about the core prandom patches, but don't know if I have > time to submit the others to the different subsystems. > > Maybe, if David would be okay with that, we can submit all patches > through his tree, as he is also the dedicated maintainer for prandom. Amazing, thank you very much! They're just minor cleanups, nothing too exciting. I'll put it in the queue to make sure they're up to date. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: simd ciphers
Am Mittwoch, 28. Dezember 2016, 16:59:38 CET schrieb Herbert Xu: Hi Herbert, > > With 4.10-rc1, I also do not get the AES-NI implementations to work. do > > you > > have any ideas what may be the issue? > > I'm having problems reproducing this. Does it work for you if you > build them as modules? When I configure AES-NI as module, it works. When compiling it statically, the allocation returns an -ENOENT. Now, when I diff both config files after a simple toggle from AES-NI=y to =m I see (linux-4.10.config contains the static config, .config contains the module configuration): $ diff -urN ../linux-4.10.config .config --- ../linux-4.10.config2016-12-28 10:56:51.805526584 +0100 +++ .config 2016-12-28 11:00:17.959608195 +0100 @@ -4062,8 +4062,8 @@ CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_ABLK_HELPER=m -CONFIG_CRYPTO_SIMD=y -CONFIG_CRYPTO_GLUE_HELPER_X86=y +CONFIG_CRYPTO_SIMD=m +CONFIG_CRYPTO_GLUE_HELPER_X86=m # # Authenticated Encryption with Associated Data @@ -4132,7 +4132,7 @@ # CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=y -CONFIG_CRYPTO_AES_NI_INTEL=y +CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
On Wed, Dec 28, 2016 at 09:19:32AM +, Ard Biesheuvel wrote: > > Ok, so that implies a field in the skcipher algo struct then, rather than > some definition internal to the driver? Oh yes it should definitely be visible to other crypto API drivers and algorithms. It's just that we don't want to export it outside of the crypto API, e.g., to IPsec or algif. Thanks, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
> On 28 Dec 2016, at 09:18, Herbert Xu wrote: > >> On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote: >>> On Fri, Dec 09, 2016 at 02:33:51PM +, Ard Biesheuvel wrote: >>> This converts the ChaCha20 code from a blkcipher to a skcipher, which >>> is now the preferred way to implement symmetric block and stream ciphers. >>> >>> This ports the generic and x86 versions at the same time because the >>> latter reuses routines of the former. >>> >>> Note that the skcipher_walk() API guarantees that all presented blocks >>> except the final one are a multiple of the chunk size, so we can simplify >>> the encrypt() routine somewhat. >>> >>> Signed-off-by: Ard Biesheuvel >> >> Patch applied. Thanks. > > I'm reverting this patch because it breaks the build on ARM without > the two subsequent patches. > > When resubmitting please make sure that the kernel can build and > work after each patch. Otherwise git bisections will fail. > Ehm, could you keep this one and revert the other two instead please? This patch will not change in the respin, and the other two are blkciphers rather than skciphers (and in the arm64 version, I optimized the asm code as well) so they will look rather different ( as they do in the nacked v2) > -- > Email: Herbert Xu > 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: simd ciphers
On Wed, Dec 28, 2016 at 09:37:04AM +0100, Stephan Müller wrote: > Am Donnerstag, 8. Dezember 2016, 19:40:38 CET schrieb Stephan Müller: > > Hi Herbert, > > > Am Donnerstag, 8. Dezember 2016, 19:32:03 CET schrieb Stephan Müller: > > > > Hi Herbert, > > > > > Hi Herbert, > > > > > > with the addition of the simd cipher change I seem to be unable to use the > > > AESNI ciphers. My .config contains CONFIG_CRYPTO_SIMD=y and > > > CONFIG_CRYPTO_AES_NI_INTEL=y. Those options always worked to load the > > > AES-NI > > (with "always worked" I meant the CONFIG_CRYPTO_AES_NI_INTEL=y option of > > course, that always ensured AES-NI to be present and usable) > > With 4.10-rc1, I also do not get the AES-NI implementations to work. do you > have any ideas what may be the issue? I'm having problems reproducing this. Does it work for you if you build them as modules? Thanks, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
On Wed, Dec 28, 2016 at 09:23:07AM +, Ard Biesheuvel wrote: > > Ehm, could you keep this one and revert the other two instead please? This > patch will not change in the respin, and the other two are blkciphers rather > than skciphers (and in the arm64 version, I optimized the asm code as well) > so they will look rather different ( as they do in the nacked v2) OK I will keep this patch and revert the other two. Thanks, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
> On 28 Dec 2016, at 09:10, Herbert Xu wrote: > >> On Tue, Dec 27, 2016 at 06:35:46PM +, Ard Biesheuvel wrote: >> >> OK, I will try to hack something up. >> >> One thing to keep in mind though is that stacked chaining modes should >> present the data with the same granularity for optimal performance. >> E.g., xts(ecb(aes)) should pass 8 blocks at a time. How should this >> requirement be incorporated according to you? > > xts tries to do a page at a time, which should be good enough, no? > Yes, if the xts chaining mode driver invokes the ecb transform with that granularity, it should be fine. Note that this is a theoretical concern for this mode in particular, given that the bit sliced aes code implements the xts bits as well > In general this parameter should be visible to internal API users > such as xts so they could use it to determine how it wants to > structure its walks. > Ok, so that implies a field in the skcipher algo struct then, rather than some definition internal to the driver? > Cheers, > -- > Email: Herbert Xu > 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
On Wed, Dec 28, 2016 at 05:18:01PM +0800, Herbert Xu wrote: > On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote: > > On Fri, Dec 09, 2016 at 02:33:51PM +, Ard Biesheuvel wrote: > > > This converts the ChaCha20 code from a blkcipher to a skcipher, which > > > is now the preferred way to implement symmetric block and stream ciphers. > > > > > > This ports the generic and x86 versions at the same time because the > > > latter reuses routines of the former. > > > > > > Note that the skcipher_walk() API guarantees that all presented blocks > > > except the final one are a multiple of the chunk size, so we can simplify > > > the encrypt() routine somewhat. > > > > > > Signed-off-by: Ard Biesheuvel > > > > Patch applied. Thanks. > > I'm reverting this patch because it breaks the build on ARM without > the two subsequent patches. > > When resubmitting please make sure that the kernel can build and > work after each patch. Otherwise git bisections will fail. Sorry, it only broke the build because I applied your other two patches first. So I'll just revert all three and it should work. Cheers, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 02:33:51PM +, Ard Biesheuvel wrote: > > This converts the ChaCha20 code from a blkcipher to a skcipher, which > > is now the preferred way to implement symmetric block and stream ciphers. > > > > This ports the generic and x86 versions at the same time because the > > latter reuses routines of the former. > > > > Note that the skcipher_walk() API guarantees that all presented blocks > > except the final one are a multiple of the chunk size, so we can simplify > > the encrypt() routine somewhat. > > > > Signed-off-by: Ard Biesheuvel > > Patch applied. Thanks. I'm reverting this patch because it breaks the build on ARM without the two subsequent patches. When resubmitting please make sure that the kernel can build and work after each patch. Otherwise git bisections will fail. Thanks, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
On Wed, Dec 28, 2016 at 09:11:03AM +, Ard Biesheuvel wrote: > > > On 28 Dec 2016, at 09:03, Herbert Xu wrote: > > > >> On Tue, Dec 27, 2016 at 02:26:35PM +, Ard Biesheuvel wrote: > >> > >> You just nacked the v2 of this series (due to the chunksize/walksize) and > >> i rewrote them as skciphers as well > > > > Sorry. Would you like me to revert or just send a new series > > on top of this? > > > > No worries. If you can, please drop them entirely, or revert them otherwise. > I will resend after the holidays OK I will revert. Thanks. -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
> On 28 Dec 2016, at 09:03, Herbert Xu wrote: > >> On Tue, Dec 27, 2016 at 02:26:35PM +, Ard Biesheuvel wrote: >> >> You just nacked the v2 of this series (due to the chunksize/walksize) and i >> rewrote them as skciphers as well > > Sorry. Would you like me to revert or just send a new series > on top of this? > No worries. If you can, please drop them entirely, or revert them otherwise. I will resend after the holidays > Thanks, > -- > Email: Herbert Xu > 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
On Tue, Dec 27, 2016 at 06:35:46PM +, Ard Biesheuvel wrote: > > OK, I will try to hack something up. > > One thing to keep in mind though is that stacked chaining modes should > present the data with the same granularity for optimal performance. > E.g., xts(ecb(aes)) should pass 8 blocks at a time. How should this > requirement be incorporated according to you? xts tries to do a page at a time, which should be good enough, no? In general this parameter should be visible to internal API users such as xts so they could use it to determine how it wants to structure its walks. Cheers, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
On Tue, Dec 27, 2016 at 02:26:35PM +, Ard Biesheuvel wrote: > > You just nacked the v2 of this series (due to the chunksize/walksize) and i > rewrote them as skciphers as well Sorry. Would you like me to revert or just send a new series on top of this? Thanks, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
On Tue, Dec 27, 2016 at 11:39:21AM +, Challa, Mahipal wrote: > > Mahipal: One major issue is, the kernel use cases to validate the Cavium > ThunderX ZIP driver are "ZSWAP" and "IPComp" which are not yet supported with > scomp-acomp framework. OK I'll look into converting IPcomp. Thanks, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xts(ecb(aes-asm))
On Fri, Dec 09, 2016 at 07:02:25AM +0100, Stephan Müller wrote: > Hi Herbert, > > while testing the current cryptodev-2.6 tree, I noticed that instead of the > driver name of xts(aes-asm) (which used to be there), I now see xts(ecb(aes- > asm)). > > Is that intentional? Yes this is a result of the xts template switching over to skciphers instead of simple ciphers as its base. Cheers, -- Email: Herbert Xu 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: simd ciphers
Am Donnerstag, 8. Dezember 2016, 19:40:38 CET schrieb Stephan Müller: Hi Herbert, > Am Donnerstag, 8. Dezember 2016, 19:32:03 CET schrieb Stephan Müller: > > Hi Herbert, > > > Hi Herbert, > > > > with the addition of the simd cipher change I seem to be unable to use the > > AESNI ciphers. My .config contains CONFIG_CRYPTO_SIMD=y and > > CONFIG_CRYPTO_AES_NI_INTEL=y. Those options always worked to load the > > AES-NI > (with "always worked" I meant the CONFIG_CRYPTO_AES_NI_INTEL=y option of > course, that always ensured AES-NI to be present and usable) With 4.10-rc1, I also do not get the AES-NI implementations to work. do you have any ideas what may be the issue? Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
