[PATCH][RFC] CPU Jitter random number generator (resent)
Hi, [1] patch at http://www.chronox.de/jent/jitterentropy-20130516.tar.bz2 A new version of the CPU Jitter random number generator is released at http://www.chronox.de/ . The heart of the RNG is about 30 lines of easy to read code. The readme in the main directory explains the different code files. A changelog can be found on the web site. In a previous attempt (http://lkml.org/lkml/2013/2/8/476), the first iteration received comments for the lack of tests, documentation and entropy assessment. All these concerns have been addressed. The documentation of the CPU Jitter random number generator (http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html and PDF at http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and pictures are better in PDF) offers a full analysis of: - the root cause of entropy - a design of the RNG - statistical tests and analyses - entropy assessment and explanation of the flow of entropy The document also explains the core concept to have a fully decentralized entropy collector for every caller in need of entropy. Also, this RNG is well suitable for virtualized environments. Measurements on OpenVZ and KVM environments have been conducted as documented. As the Linux kernel is starved of entropy in virtualized as well as server environments, new sources of entropy are vital. The appendix of the documentation contains example use cases by providing link code to the Linux kernel crypto API, libgcrypt and OpenSSL. Links to other cryptographic libraries should be straight forward to implement. These implementations follow the concept of decentralized entropy collection. The man page provided with the source code explains the use of the API of the CPU Jitter random number generator. The test cases used to compile the documentation are available at the web site as well. Note: for the kernel crypto API, please read the provided Kconfig file for the switches and which of them are recommended in regular operation. These switches must currently be set manually in the Makefile. Ciao Stephan Signed-off-by: Stephan Mueller -- 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: Oops on 3.10-rc1 related to ssh256_ssse3
On 16.05.2013 16:41, Julian Wollrath wrote: > Hello, > > I have an encrypted disc (dm-crypt, type LUKS1, ssh256 as hash > algorithm). I have an Intel Core i5 M450 that supports ssse3. Find > below the output from netconsole with the oops. The last warning > appeared when I restart the pc using the magic sysrq key combination > REISUB. I have the same problem with a different laptop with an AMD > E-450 APU. Appears to be stack corruption caused by sha256_transform_ssse3. Does attached patch help? -Jussi > > If you need further information, feel free to ask. > > > Best regards, > Julian Wollrath > > [3.647071] device-mapper: uevent: version 1.0.3 > [3.647245] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: > dm-de...@redhat.com > [ 11.619603] sha256_ssse3: Using SSSE3 optimized SHA-256 implementation > [ 12.131483] BUG: unable to handle kernel paging request at 8800bb593000 > [ 12.131848] IP: [] loop0+0x27/0x44 [sha256_ssse3] > [ 12.132032] PGD 1a32067 PUD 1a35067 PMD 1a36067 PTE 0 > [ 12.132427] Oops: [#1] SMP > [ 12.132670] Modules linked in: sha256_ssse3(+) sha256_generic > twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper > twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod > cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata > scsi_mod r8169 mii usbcore usb_common thermal thermal_sys > [ 12.135396] CPU: 3 PID: 276 Comm: cryptomgr_test Not tainted 3.10.0-rc1+ #2 > [ 12.135559] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 > 10/25/2010 > [ 12.135720] task: 880037572090 ti: 8800b66b6000 task.ti: > 8800b66b6000 > [ 12.135836] RIP: 0010:[] [] > loop0+0x27/0x44 [sha256_ssse3] > [ 12.136032] RSP: 0018:8800b66b7af0 EFLAGS: 00010287 > [ 12.136130] RAX: a186fc15 RBX: 704bb939 RCX: > d1b791ec > [ 12.136232] RDX: 1fd2088a RSI: 880037a97ee8 RDI: > 8800bb592fc8 > [ 12.136334] RBP: a016f000 R08: 52a5c3c8 R09: > 5db427ef > [ 12.136439] R10: b80a833e R11: 29c53567 R12: > 8800b66b7b08 > [ 12.136543] R13: 3158a213 R14: c7fc368e R15: > 01008012 > [ 12.136647] FS: () GS:8800bb18() > knlGS: > [ 12.136763] CS: 0010 DS: ES: CR0: 80050033 > [ 12.136863] CR2: 8800bb593000 CR3: 0180b000 CR4: > 07e0 > [ 12.136964] DR0: DR1: DR2: > > [ 12.137066] DR3: DR6: 0ff0 DR7: > 0400 > [ 12.137167] Stack: > [ 12.137257] 880108c634c8 8800bb592f88 6033fb357b8c96fd > c5e119eaebeb38a3 > [ 12.137668] 880037a97f08 8800b66b7b80 0008 > 0008 > [ 12.138077] 880037a97ed0 a016dc4e 880001496ae5 > 880037a97ee0 > [ 12.138484] Call Trace: > [ 12.138580] [] ? __sha256_ssse3_update+0x5e/0xe0 > [sha256_ssse3] > [ 12.138701] [] ? sha256_ssse3_final+0x145/0x1ec > [sha256_ssse3] > [ 12.138825] [] ? shash_ahash_finup+0x32/0x80 > [ 12.138931] [] ? test_hash+0x383/0x6b0 > [ 12.139034] [] ? crypto_mod_get+0x10/0x30 > [ 12.139141] [] ? __kmalloc+0x1c6/0x1f0 > [ 12.139243] [] ? __crypto_alg_lookup+0xac/0xf0 > [ 12.139344] [] ? crypto_create_tfm+0x48/0xd0 > [ 12.139445] [] ? crypto_init_shash_ops_async+0x2d/0xd0 > [ 12.139548] [] ? alg_test_hash+0x43/0xa0 > [ 12.139650] [] ? alg_test+0x9b/0x230 > [ 12.139753] [] ? __schedule+0x271/0x650 > [ 12.139856] [] ? cryptomgr_probe+0xb0/0xb0 > [ 12.139954] [] ? cryptomgr_test+0x38/0x40 > [ 12.140058] [] ? kthread+0xaf/0xc0 > [ 12.140219] [] ? kthread_create_on_node+0x110/0x110 > [ 12.140382] [] ? ret_from_fork+0x7c/0xb0 > [ 12.140482] [] ? kthread_create_on_node+0x110/0x110 > [ 12.140585] Code: c4 40 00 00 48 8d 2d 9d 3f 00 00 f3 0f 6f 27 66 41 0f 38 > 00 e4 f3 0f 6f 6f 10 66 41 0f 38 00 ec f3 0f 6f 77 20 66 41 0f 38 00 f4 > 0f 6f 7f 30 66 41 0f 38 00 fc 48 89 7c 24 08 48 c7 c7 03 00 > [ 12.145708] RIP [] loop0+0x27/0x44 [sha256_ssse3] > [ 12.145885] RSP > [ 12.145979] CR2: 8800bb593000 > [ 12.146075] ---[ end trace 0382cf30f3465fd1 ]--- > [ 12.146173] note: cryptomgr_test[276] exited with preempt_count 1 > [ 12.146347] BUG: scheduling while atomic: cryptomgr_test/276/0x1001 > [ 12.146485] Modules linked in: sha256_ssse3(+) sha256_generic > twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper > twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod > cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata > scsi_mod r8169 mii usbcore usb_common thermal thermal_sys > [ 12.150126] CPU: 3 PID: 276 Comm: cryptomgr_test Tainted: G D > 3.10.0-rc1+ #2 > [ 12.150282] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 > 10/2
Re: linux-next: Tree for May 15 (crypto /crct10dif)
On Mon, 2013-05-20 at 19:47 +0800, Herbert Xu wrote:
>
> Nope this is still broken. We need to move the actual crct10dif
> code into crypto/. I'll fix up the patch in the tree.
>
> Also I'm going to get rid of crc_t10dif_update_lib function. If you
> still want to maintain the ordering you should do so using the
> *_init constructs.
>
Herbert,
I used the following constructs in the pclmulqdq version of t10dif
to get the module loaded.
static const struct x86_cpu_id crct10dif_cpu_id[] = {
X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ),
{}
};
MODULE_DEVICE_TABLE(x86cpu, crct10dif_cpu_id);
However, the default generic algorithm is used
in the library function. The options CRC_T10DIF, CRYPTO_CRCT10DIF
and CRYPTO_CRCT10DIF_PCLMUL are selected as modules (which
is most likely usage scenario in distribution) on my
test machine. The library module and generic crypto module was loaded
before the pclmulqdq t10dif module during boot. How should
things be changed to get this crypto module loaded earlier before the
library? Should we add another init call level between fs and device
init calls for loading the available crypto algorithms?
The crc_t10dif_update_lib was originally used to side step this issue.
BTW, latest crypto-dev need the following modification if we get
rid of crc_t10dif_update_lib.
Thanks.
Tim
diff --git a/arch/x86/crypto/crct10dif-pclmul_glue.c
b/arch/x86/crypto/crct10dif-pclmul_glue.c
index 3c0abd3..d838b7f 100644
--- a/arch/x86/crypto/crct10dif-pclmul_glue.c
+++ b/arch/x86/crypto/crct10dif-pclmul_glue.c
@@ -136,8 +136,6 @@ static int __init crct10dif_intel_mod_init(void)
return -ENODEV;
ret = crypto_register_shash(&alg);
- if (!ret)
- crc_t10dif_update_lib();
return ret;
}
--
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 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > For all ux500 based platforms the maximum number of end-points are used. > Move this knowledge into the driver so we can relinquish the burden from > platform data. This also removes quite a bit of complexity from the driver > and will aid us when we come to enable the driver for Device Tree. > > Cc: Felipe Balbi > Cc: linux-...@vger.kernel.org > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones I have now gone over and collected ACKs etc for the patches up until here. Now you need Felipe's consent to proceed with the MUSB changes through my tree. Yours, Linus Walleij -- 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 19/39] ARM: ux500: Register Cyrp and Hash platform drivers on Snowball
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > These drivers are now operational and even use the latest common clk > and DMA APIs. There's no reason why we shouldn't start them up now. > > Reviewed-by: Linus Walleij > Signed-off-by: Lee Jones Patch applied now that the deps are in place. Yours, Linus Walleij -- 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 18/39] crypto: ux500/[cryp|hash] - Show successful start-up in the bootlog
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The Cryp driver is currently silent and the Hash driver prints the > name of its probe function unnecessarily. Let's just put a nice > descriptive one-liner there instead. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-crypto@vger.kernel.org > Acked-by: Arnd Bergmann > Reviewed-by: Linus Walleij > Signed-off-by: Lee Jones Patch applied with Herbert's ACK. Thanks, Linus Walleij -- 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: linux-next: Tree for May 15 (crypto /crct10dif)
On Mon, May 20, 2013 at 07:47:07PM +0800, Herbert Xu wrote:
> On Thu, May 16, 2013 at 11:03:32AM -0700, Tim Chen wrote:
> >
> > Need to also add select CRYPTO for CRC_T10DIF. Updated fix below:
> >
> >
> > Signed-off-by: Tim Chen
> > ---
> > diff --git a/crypto/Kconfig b/crypto/Kconfig
> > index d1ca631..015df24 100644
> > --- a/crypto/Kconfig
> > +++ b/crypto/Kconfig
> > @@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
> > config CRYPTO_CRCT10DIF
> > tristate "CRCT10DIF algorithm"
> > select CRYPTO_HASH
> > + depends on CRC_T10DIF
> > help
> > CRC T10 Data Integrity Field computation is being cast as
> > a crypto transform. This allows for faster crc t10 diff
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index 0cee056..6407793 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -63,7 +63,8 @@ config CRC16
> >
> > config CRC_T10DIF
> > tristate "CRC calculation for the T10 Data Integrity Field"
> > - select CRYPTO_CRCT10DIF
> > + select CRYPTO
> > + select CRYPTO_HASH
> > help
> > This option is only needed if a module that's not in the
> > kernel tree needs to calculate CRC checks for use with the
>
> Nope this is still broken. We need to move the actual crct10dif
> code into crypto/. I'll fix up the patch in the tree.
>
> Also I'm going to get rid of crc_t10dif_update_lib function. If you
> still want to maintain the ordering you should do so using the
> *_init constructs.
Here is the updated patch in question:
commit 2d31e518a42828df7877bca23a958627d60408bc
Author: Tim Chen
Date: Wed May 1 12:52:48 2013 -0700
crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform
framework
When CRC T10 DIF is calculated using the crypto transform framework, we
wrap the crc_t10dif function call to utilize it. This allows us to
take advantage of any accelerated CRC T10 DIF transform that is
plugged into the crypto framework.
Signed-off-by: Tim Chen
Signed-off-by: Herbert Xu
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 622d8a4..ceb3611 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -376,6 +376,14 @@ config CRYPTO_CRC32_PCLMUL
which will enable any routine to use the CRC-32-IEEE 802.3 checksum
and gain better performance as compared with the table implementation.
+config CRYPTO_CRCT10DIF
+ tristate "CRCT10DIF algorithm"
+ select CRYPTO_HASH
+ help
+ CRC T10 Data Integrity Field computation is being cast as
+ a crypto transform. This allows for faster crc t10 diff
+ transforms to be used if they are available.
+
config CRYPTO_GHASH
tristate "GHASH digest algorithm"
select CRYPTO_GF128MUL
diff --git a/crypto/Makefile b/crypto/Makefile
index a8e9b0f..62af87d 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_CRYPTO_ZLIB) += zlib.o
obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += michael_mic.o
obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o
obj-$(CONFIG_CRYPTO_CRC32) += crc32.o
+obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif.o
obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o authencesn.o
obj-$(CONFIG_CRYPTO_LZO) += lzo.o
obj-$(CONFIG_CRYPTO_842) += 842.o
diff --git a/crypto/crct10dif.c b/crypto/crct10dif.c
new file mode 100644
index 000..92aca96
--- /dev/null
+++ b/crypto/crct10dif.c
@@ -0,0 +1,178 @@
+/*
+ * Cryptographic API.
+ *
+ * T10 Data Integrity Field CRC16 Crypto Transform
+ *
+ * Copyright (c) 2007 Oracle Corporation. All rights reserved.
+ * Written by Martin K. Petersen
+ * Copyright (C) 2013 Intel Corporation
+ * Author: Tim Chen
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct chksum_desc_ctx {
+ __u16 crc;
+};
+
+/* Table generated using the following polynomium:
+ * x^16 + x^15 + x^11 + x^9 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
+ * gt: 0x8bb7
+ */
+static const __u16 t10_dif_crc_table[256] = {
+ 0x, 0x8BB7, 0x9CD9, 0x176E, 0xB205, 0x39B2, 0x2EDC, 0xA56B,
+ 0xEFBD, 0x640A, 0x7364, 0xF8D3, 0x5DB8, 0xD60F, 0xC161, 0x4AD6,
+ 0x54CD, 0xDF7A, 0xC814, 0x43A3, 0xE6C8, 0x6D7F, 0x7A11, 0xF1A6,
+ 0xBB70, 0x30C7, 0x27A9, 0xAC1E, 0x0975, 0x82C2, 0x95AC, 0x1E1B,
Re: [PATCH 16/39] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The DMA controller currently takes configuration information from > information passed though dma_channel_request(), but it shouldn't. > Using the API, the DMA channel should only be configured during > a dma_slave_config() call. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-crypto@vger.kernel.org > Acked-by: Arnd Bergmann > Acked-by: Linus Walleij > Signed-off-by: Lee Jones Patch applied with Herbert's ACK. Thanks, Linus Walleij -- 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 15/39] crypto: ux500/cryp - Prepare clock before enabling it
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > If we fail to prepare the ux500-cryp clock before enabling it the > platform will fail to boot. Here we insure this happens. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-crypto@vger.kernel.org > Acked-by: Ulf Hansson > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Patch applied with Herbert's ACK. Yours, Linus Walleij -- 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 14/39] ARM: ux500: Stop passing Hash DMA channel config information though pdata
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > DMA channel configuration information should be setup in the driver. > The Ux500 Hash driver now does this, so there's no need to send it > though here too. > > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Patch applied now that the deps are in! Yours, Linus Walleij -- 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 13/39] crypto: ux500/hash - Set DMA configuration though dma_slave_config()
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The DMA controller currently takes configuration information from > information passed though dma_channel_request(), but it shouldn't. > Using the API, the DMA channel should only be configured during > a dma_slave_config() call. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-crypto@vger.kernel.org > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Patch applied to my dma40 branch with Herbert's ACK. Yours, Linus Walleij -- 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 12/39] crypto: ux500/hash - Prepare clock before enabling it
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > If we fail to prepare the ux500-hash clock before enabling it the > platform will fail to boot. Here we insure this happens. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-crypto@vger.kernel.org > Acked-by: Arnd Bergmann > Acked-by: Ulf Hansson > Signed-off-by: Lee Jones Patch applied to my dma40 branch with Herbert's ACK. Yours, Linus Walleij -- 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 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
On Thu, May 16, 2013 at 12:59 PM, Lee Jones wrote: > On Thu, 16 May 2013, Vinod Koul wrote: > >> On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote: >> > On Thu, 16 May 2013, Vinod Koul wrote: >> > >> > > On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote: >> > > > All configuration left in d40_phy_cfg() is runtime configurable and >> > > > there is already a call into it from d40_runtime_config(), so let's >> > > > rely on that. >> > > > >> > > > Acked-by: Vinod Koul >> > > That needs up update! >> > >> > Ah, where did I get that from that? >> > >> > Was that my mistake, or was this in the MAINTAINERS file? >> Certainly not in MAINTAINERS file :) > > My bad then, sorry. > > Linus, > > Would you be kind enough to fix it please, as it's in your tree now. I've fixed it up! Yours, Linus Walleij -- 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: linux-next: Tree for May 15 (crypto /crct10dif)
On Thu, May 16, 2013 at 11:03:32AM -0700, Tim Chen wrote: > > Need to also add select CRYPTO for CRC_T10DIF. Updated fix below: > > > Signed-off-by: Tim Chen > --- > diff --git a/crypto/Kconfig b/crypto/Kconfig > index d1ca631..015df24 100644 > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL > config CRYPTO_CRCT10DIF > tristate "CRCT10DIF algorithm" > select CRYPTO_HASH > + depends on CRC_T10DIF > help > CRC T10 Data Integrity Field computation is being cast as > a crypto transform. This allows for faster crc t10 diff > diff --git a/lib/Kconfig b/lib/Kconfig > index 0cee056..6407793 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -63,7 +63,8 @@ config CRC16 > > config CRC_T10DIF > tristate "CRC calculation for the T10 Data Integrity Field" > - select CRYPTO_CRCT10DIF > + select CRYPTO > + select CRYPTO_HASH > help > This option is only needed if a module that's not in the > kernel tree needs to calculate CRC checks for use with the Nope this is still broken. We need to move the actual crct10dif code into crypto/. I'll fix up the patch in the tree. Also I'm going to get rid of crc_t10dif_update_lib function. If you still want to maintain the ordering you should do so using the *_init constructs. 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
