Hi Stephan,
Following up from the other thread:
While trying to boot in FIPS mode, kernel panics with the following
message. So far, I don?t have success to get more information about which
module or symbol is causing this. I haven?t found any errors or warnings
in kernel compilation. It boots fine in a non-fips mode.
I am also pasting the CRYPTO related configs that I have enabled (See
below).
-Tapas
/boot/vmlinuz-4.7.0-1.tos2_5: OK
modprobe: ERROR: could not insert 'drbg': Unknown symbol in module, or
unknown parameter (see dmesg)
[ 1.330798] dracut: FATAL: FIPS integrity test failed
[ 1.331534] dracut: Refusing to continue
[ 1.333491] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000100
[ 1.333491]
[ 1.334768] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-1.tos2_5 #1
[ 1.335632] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.8.2-20150714_191134- 04/01/2014
[ 1.336114] 0000000000000000 ffff88003e1dfbc8 ffffffff812ae299
0000000000000001
[ 1.336114] 0000000000000001 ffffffff81716b00 ffff88003e210000
ffff88003e1dfc48
[ 1.336114] ffffffff81104fd4 0000000000000010 ffff88003e1dfc58
ffff88003e1dfbf8
[ 1.336114] Call Trace:
[ 1.336114] [<ffffffff812ae299>] dump_stack+0x51/0x78
[ 1.336114] [<ffffffff81104fd4>] panic+0xc1/0x211
[ 1.336114] [<ffffffff81058781>] forget_original_parent+0x411/0x420
[ 1.336114] [<ffffffff810f4a12>] ? perf_pin_task_context+0x12/0x40
[ 1.336114] [<ffffffff810fcd52>] ? perf_event_exit_task+0x3b2/0x470
[ 1.336114] [<ffffffff81058cb6>] exit_notify+0x36/0x1e0
[ 1.336114] [<ffffffff810d4b61>] ? cgroup_exit+0x71/0xc0
[ 1.336114] [<ffffffff81070fdf>] ? task_work_run+0x5f/0x90
[ 1.336114] [<ffffffff8105a4ff>] do_exit+0x31f/0x640
[ 1.336114] [<ffffffff811726d9>] ? ____fput+0x9/0x10
[ 1.336114] [<ffffffff81070fdf>] ? task_work_run+0x5f/0x90
[ 1.336114] [<ffffffff81046d0e>] ? __do_page_fault+0x17e/0x450
[ 1.336114] [<ffffffff8105a869>] do_group_exit+0x49/0xb0
[ 1.336114] [<ffffffff8105a8e2>] SyS_exit_group+0x12/0x20
[ 1.336114] [<ffffffff8154dd9b>] entry_SYSCALL_64_fastpath+0x13/0x8f
[ 1.336114] Kernel Offset: disabled
[ 1.336114] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x00000100
[ 1.336114]
# Enabled CRYPTO configs
[root@localhost ~]# egrep 'CRYPTO.*=y|CRYPTO.*=m'
/boot/config-4.7.0-1.tos2_5
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=m
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_RSA=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_MCRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=m
CONFIG_CRYPTO_GLUE_HELPER_X86=m
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m
CONFIG_CRYPTO_ECHAINIV=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRYPTO_GHASH=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=m
CONFIG_CRYPTO_SHA256_SSSE3=m
CONFIG_CRYPTO_SHA512_SSSE3=m
CONFIG_CRYPTO_SHA1_MB=m
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_BLOWFISH_X86_64=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_CAST6_AVX_X86_64=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_DES3_EDE_X86_64=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_LZO=m
CONFIG_CRYPTO_LZ4=m
CONFIG_CRYPTO_LZ4HC=m
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=m
CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG=m
CONFIG_CRYPTO_JITTERENTROPY=m
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_CCP=y
CONFIG_CRYPTO_DEV_CCP_DD=m
CONFIG_CRYPTO_DEV_CCP_CRYPTO=m
CONFIG_CRYPTO_DEV_QAT=m
CONFIG_CRYPTO_DEV_QAT_DH895xCC=m
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
Am Dienstag, 9. August 2016, 16:34:59 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hi Stephan,
>
> Following up from the other thread:
>
> While trying to boot in FIPS mode, kernel panics with the following
> message. So far, I don?t have success to get more information about which
> module or symbol is causing this. I haven?t found any errors or warnings
> in kernel compilation. It boots fine in a non-fips mode.
>
> I am also pasting the CRYPTO related configs that I have enabled (See
> below).
I do not see the issue immediately. Could you boot without fips=1 and do a
modprobe drbg ?
I am also testing fips=1 now.
Ciao
Stephan
Hi Stephan,
Thanks. I have already tried that. ??drbg?? module is loaded fine in a
non-fips mode. Here are output from some commands.
I see that at some point you had a patch to use CONFIG_CRYPTO_LRNG. I am
not using that, could that be a problem ?
-Tapas
[root@localhost ~]# modprobe drbg
[root@localhost ~]# echo $?
0
[root@localhost ~]# dmesg | tail -5
[ 3.636174] nf_conntrack version 0.5.0 (7168 buckets, 28672 max)
[ 3.738645] NET: Registered protocol family 10
[ 3.743004] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 3.773384] input: ImExPS/2 BYD TouchPad as
/devices/platform/i8042/serio1/input/input3
[ 3.776803] mousedev: PS/2 mouse device common for all mice
[root@localhost ~]# lsmod | grep drbg
drbg 14147 1
[root@localhost ~]# modinfo drbg
filename: /lib/modules/4.7.0-1.tos2_5/kernel/crypto/drbg.ko.gz
alias: crypto-stdrng
alias: stdrng
description: NIST SP800-90A Deterministic Random Bit Generator (DRBG)
using following cores: HMAC
author: Stephan Mueller <[email protected]>
license: GPL
alias: crypto-drbg_nopr_hmac_sha1
alias: drbg_nopr_hmac_sha1
alias: crypto-drbg_pr_hmac_sha1
alias: drbg_pr_hmac_sha1
alias: crypto-drbg_nopr_hmac_sha256
alias: drbg_nopr_hmac_sha256
alias: crypto-drbg_pr_hmac_sha256
alias: drbg_pr_hmac_sha256
alias: crypto-drbg_nopr_hmac_sha384
alias: drbg_nopr_hmac_sha384
alias: crypto-drbg_pr_hmac_sha384
alias: drbg_pr_hmac_sha384
alias: crypto-drbg_nopr_hmac_sha512
alias: drbg_nopr_hmac_sha512
alias: crypto-drbg_pr_hmac_sha512
alias: drbg_pr_hmac_sha512
depends:
intree: Y
vermagic: 4.7.0-1.tos2_5 SMP mod_unload modversions
On 8/9/16, 12:05 PM, "Stephan Mueller" <[email protected]> wrote:
>Am Dienstag, 9. August 2016, 16:34:59 CEST schrieb Tapas Sarangi:
>
>Hi Tapas,
>
>> Hi Stephan,
>>
>> Following up from the other thread:
>>
>> While trying to boot in FIPS mode, kernel panics with the following
>> message. So far, I don??t have success to get more information about
>>which
>> module or symbol is causing this. I haven??t found any errors or warnings
>> in kernel compilation. It boots fine in a non-fips mode.
>>
>> I am also pasting the CRYPTO related configs that I have enabled (See
>> below).
>
>I do not see the issue immediately. Could you boot without fips=1 and do
>a
>modprobe drbg ?
>
>I am also testing fips=1 now.
>
>Ciao
>Stephan
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
Am Dienstag, 9. August 2016, 17:11:09 CEST schrieb Tapas Sarangi:
Hi Tapas, Herbert,
> Hi Stephan,
>
> Thanks. I have already tried that. ‘drbg’ module is loaded fine in a
> non-fips mode. Here are output from some commands.
There is something strange going on. I have to compile the DRBG statically.
When booting the kernel with fips=1 (of course after changing the key size to
2k or 3k in certs/x509.genkey), the DRBG does not show up in /proc/crypto nor
can I find testmgr entries about the DRBG.
When I reboot the kernel without fips=1, all works as expected.
When I create a copy of the drbg.c code and have it compiled as a module to
ensure it is signed, I can insmod it and the testmgr successfully tests it.
Note, with fips=1, my kernel crashes randomly somewhere in the elf loading
code -- I guess it is because there is no stdrng.
>
> I see that at some point you had a patch to use CONFIG_CRYPTO_LRNG. I am
> not using that, could that be a problem ?
Nope, this LRNG is something completely different -- it is my proposal to
replace the current /dev/random and /dev/urandom implementation as documented
in [1].
[1] http://www.chronox.de/lrng.html
Ciao
Stephan
Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller:
Hi Tapas,
I think I found the issue. Can you please test the attached patch?
---8<---
When calling the DRBG health test in FIPS mode, the Jitter RNG is not
yet present in the kernel crypto API which will cause the instantiation
to fail and thus the health test to fail.
As the health tests cover the enforcement of various thresholds, invoke
the functions that are supposed to enforce the thresholds directly.
This patch also saves precious seed.
Reported-by: Tapas Sarangi <[email protected]>
Signed-off-by: Stephan Mueller <[email protected]>
---
crypto/drbg.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index f752da3..edf3ce0 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1917,6 +1917,8 @@ static inline int __init drbg_healthcheck_sanity(void)
return -ENOMEM;
mutex_init(&drbg->drbg_mutex);
+ drbg->core = &drbg_cores[coreref];
+ drbg->reseed_threshold = drbg_max_requests(drbg);
/*
* if the following tests fail, it is likely that there is a buffer
@@ -1926,12 +1928,6 @@ static inline int __init drbg_healthcheck_sanity(void)
* grave bug.
*/
- /* get a valid instance of DRBG for following tests */
- ret = drbg_instantiate(drbg, NULL, coreref, pr);
- if (ret) {
- rc = ret;
- goto outbuf;
- }
max_addtllen = drbg_max_addtl(drbg);
max_request_bytes = drbg_max_request_bytes(drbg);
drbg_string_fill(&addtl, buf, max_addtllen + 1);
@@ -1941,10 +1937,9 @@ static inline int __init drbg_healthcheck_sanity(void)
/* overflow max_bits */
len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL);
BUG_ON(0 < len);
- drbg_uninstantiate(drbg);
/* overflow max addtllen with personalization string */
- ret = drbg_instantiate(drbg, &addtl, coreref, pr);
+ ret = drbg_seed(drbg, &addtl, false);
BUG_ON(0 == ret);
/* all tests passed */
rc = 0;
@@ -1952,9 +1947,7 @@ static inline int __init drbg_healthcheck_sanity(void)
pr_devel("DRBG: Sanity tests for failure code paths successfully "
"completed\n");
- drbg_uninstantiate(drbg);
-outbuf:
- kzfree(drbg);
+ kfree(drbg);
return rc;
}
--
2.7.4
Hi Stephan,
Thanks. The patch that I applied have different line numbers than yours.
In any case, patch worked to get rid of ?drbg? related error.
Now, fips mode is failing on self-test:
/boot/vmlinuz-4.7.0-1.tos2_5: OK
[ 1.296714] alg: skcipher: setkey failed on test 1 for xts(aes-asm):
flags=100000
[ 1.297665] Kernel panic - not syncing: xts(aes): xts(aes) alg self
test failed in fips mode!
[ 1.297665]
Thanks
-Tapas
On 8/9/16, 2:02 PM, "Stephan Mueller" <[email protected]> wrote:
>Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller:
>
>Hi Tapas,
>
>I think I found the issue. Can you please test the attached patch?
>
>---8<---
>
>When calling the DRBG health test in FIPS mode, the Jitter RNG is not
>yet present in the kernel crypto API which will cause the instantiation
>to fail and thus the health test to fail.
>
>As the health tests cover the enforcement of various thresholds, invoke
>the functions that are supposed to enforce the thresholds directly.
>
>This patch also saves precious seed.
>
>Reported-by: Tapas Sarangi <[email protected]>
>Signed-off-by: Stephan Mueller <[email protected]>
>---
> crypto/drbg.c | 15 ++++-----------
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
>diff --git a/crypto/drbg.c b/crypto/drbg.c
>index f752da3..edf3ce0 100644
>--- a/crypto/drbg.c
>+++ b/crypto/drbg.c
>@@ -1917,6 +1917,8 @@ static inline int __init
>drbg_healthcheck_sanity(void)
> return -ENOMEM;
>
> mutex_init(&drbg->drbg_mutex);
>+ drbg->core = &drbg_cores[coreref];
>+ drbg->reseed_threshold = drbg_max_requests(drbg);
>
> /*
> * if the following tests fail, it is likely that there is a buffer
>@@ -1926,12 +1928,6 @@ static inline int __init
>drbg_healthcheck_sanity(void)
> * grave bug.
> */
>
>- /* get a valid instance of DRBG for following tests */
>- ret = drbg_instantiate(drbg, NULL, coreref, pr);
>- if (ret) {
>- rc = ret;
>- goto outbuf;
>- }
> max_addtllen = drbg_max_addtl(drbg);
> max_request_bytes = drbg_max_request_bytes(drbg);
> drbg_string_fill(&addtl, buf, max_addtllen + 1);
>@@ -1941,10 +1937,9 @@ static inline int __init
>drbg_healthcheck_sanity(void)
> /* overflow max_bits */
> len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL);
> BUG_ON(0 < len);
>- drbg_uninstantiate(drbg);
>
> /* overflow max addtllen with personalization string */
>- ret = drbg_instantiate(drbg, &addtl, coreref, pr);
>+ ret = drbg_seed(drbg, &addtl, false);
> BUG_ON(0 == ret);
> /* all tests passed */
> rc = 0;
>@@ -1952,9 +1947,7 @@ static inline int __init
>drbg_healthcheck_sanity(void)
> pr_devel("DRBG: Sanity tests for failure code paths successfully "
> "completed\n");
>
>- drbg_uninstantiate(drbg);
>-outbuf:
>- kzfree(drbg);
>+ kfree(drbg);
> return rc;
> }
>
>--
>2.7.4
>
>
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
Hi Tapas, Herbert,
Tapas: this patch should fix it. Can you please test?
Herbert: The reason why I have to caught this issue in my tests is the following: I compile xts-aes-aesni statically as you can see below. The self test is marked as passed, although there is no XTS test performed. When you boot in FIPS mode, the testmgr prints out all tests. But XTS is not among them. Do you have an idea why that happens?
name : xts(aes)
driver : xts-aes-aesni
module : kernel
priority : 400
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
geniv : <default>
---8<---
In FIPS mode, setting XTS keys where the AES key is identical to the
tweak key is forbidden. Thus, the self test with such property will fail
in FIPS mode.
As we have other tests available for XTS, this patch simply removes the
offending test vectors.
Reported-by: Tapas Sarangi <[email protected]>
Signed-off-by: Stephan Mueller <[email protected]>
---
crypto/testmgr.h | 36 ------------------------------------
1 file changed, 36 deletions(-)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index acb6bbf..e4b58f5 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -10179,24 +10179,6 @@ static struct cipher_testvec tf_lrw_dec_tv_template[] = {
static struct cipher_testvec tf_xts_enc_tv_template[] = {
/* Generated from AES-XTS test vectors */
{
- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .klen = 32,
- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .ilen = 32,
- .result = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
- "\x30\x74\xe4\x44\x52\x77\x97\x43"
- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
- .rlen = 32,
- }, {
.key = "\x11\x11\x11\x11\x11\x11\x11\x11"
"\x11\x11\x11\x11\x11\x11\x11\x11"
"\x22\x22\x22\x22\x22\x22\x22\x22"
@@ -10522,24 +10504,6 @@ static struct cipher_testvec tf_xts_dec_tv_template[] = {
/* Generated from AES-XTS test vectors */
/* same as enc vectors with input and result reversed */
{
- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .klen = 32,
- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .input = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
- "\x30\x74\xe4\x44\x52\x77\x97\x43"
- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
- .ilen = 32,
- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .rlen = 32,
- }, {
.key = "\x11\x11\x11\x11\x11\x11\x11\x11"
"\x11\x11\x11\x11\x11\x11\x11\x11"
"\x22\x22\x22\x22\x22\x22\x22\x22"
--
2.7.4
Hi Stephan,
Thanks. Sorry for a late reply to this.
I did test your patch for testmgr.h with the vanilla kernel 4.7 source.
This doesn?t solve the xts(aes) self-test failure in FIPS mode. I get the
exact same error as before.
Thanks
-Tapas
On 8/10/16, 12:49 AM, "Stephan Mueller" <[email protected]> wrote:
>Hi Tapas, Herbert,
>
>Tapas: this patch should fix it. Can you please test?
>
>Herbert: The reason why I have to caught this issue in my tests is the
>following: I compile xts-aes-aesni statically as you can see below. The
>self test is marked as passed, although there is no XTS test performed.
>When you boot in FIPS mode, the testmgr prints out all tests. But XTS is
>not among them. Do you have an idea why that happens?
>
>name : xts(aes)
>driver : xts-aes-aesni
>module : kernel
>priority : 400
>refcnt : 1
>selftest : passed
>internal : no
>type : ablkcipher
>async : yes
>blocksize : 16
>min keysize : 32
>max keysize : 64
>ivsize : 16
>geniv : <default>
>
>---8<---
>
>In FIPS mode, setting XTS keys where the AES key is identical to the
>tweak key is forbidden. Thus, the self test with such property will fail
>in FIPS mode.
>
>As we have other tests available for XTS, this patch simply removes the
>offending test vectors.
>
>Reported-by: Tapas Sarangi <[email protected]>
>Signed-off-by: Stephan Mueller <[email protected]>
>---
> crypto/testmgr.h | 36 ------------------------------------
> 1 file changed, 36 deletions(-)
>
>diff --git a/crypto/testmgr.h b/crypto/testmgr.h
>index acb6bbf..e4b58f5 100644
>--- a/crypto/testmgr.h
>+++ b/crypto/testmgr.h
>@@ -10179,24 +10179,6 @@ static struct cipher_testvec
>tf_lrw_dec_tv_template[] = {
> static struct cipher_testvec tf_xts_enc_tv_template[] = {
> /* Generated from AES-XTS test vectors */
> {
>- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .klen = 32,
>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .ilen = 32,
>- .result = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
>- "\x30\x74\xe4\x44\x52\x77\x97\x43"
>- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
>- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
>- .rlen = 32,
>- }, {
> .key = "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x22\x22\x22\x22\x22\x22\x22\x22"
>@@ -10522,24 +10504,6 @@ static struct cipher_testvec
>tf_xts_dec_tv_template[] = {
> /* Generated from AES-XTS test vectors */
> /* same as enc vectors with input and result reversed */
> {
>- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .klen = 32,
>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .input = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
>- "\x30\x74\xe4\x44\x52\x77\x97\x43"
>- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
>- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
>- .ilen = 32,
>- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .rlen = 32,
>- }, {
> .key = "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x22\x22\x22\x22\x22\x22\x22\x22"
>--
>2.7.4
>
>
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
Hi Stephan,
Any other ideas about this problem ? Since XTS is not amongst the
self-tests as you observed, is it safe to disable .fips_allowed for
xts(aes) in testmgr.c ?
Thanks
-Tapas
On 8/10/16, 5:08 PM, "Tapas Sarangi" <[email protected]> wrote:
>Hi Stephan,
>
>Thanks. Sorry for a late reply to this.
>
>I did test your patch for testmgr.h with the vanilla kernel 4.7 source.
>This doesn??t solve the xts(aes) self-test failure in FIPS mode. I get the
>exact same error as before.
>
>Thanks
>-Tapas
>
>
>
>
>
>
>
>On 8/10/16, 12:49 AM, "Stephan Mueller" <[email protected]> wrote:
>
>>Hi Tapas, Herbert,
>>
>>Tapas: this patch should fix it. Can you please test?
>>
>>Herbert: The reason why I have to caught this issue in my tests is the
>>following: I compile xts-aes-aesni statically as you can see below. The
>>self test is marked as passed, although there is no XTS test performed.
>>When you boot in FIPS mode, the testmgr prints out all tests. But XTS is
>>not among them. Do you have an idea why that happens?
>>
>>name : xts(aes)
>>driver : xts-aes-aesni
>>module : kernel
>>priority : 400
>>refcnt : 1
>>selftest : passed
>>internal : no
>>type : ablkcipher
>>async : yes
>>blocksize : 16
>>min keysize : 32
>>max keysize : 64
>>ivsize : 16
>>geniv : <default>
>>
>>---8<---
>>
>>In FIPS mode, setting XTS keys where the AES key is identical to the
>>tweak key is forbidden. Thus, the self test with such property will fail
>>in FIPS mode.
>>
>>As we have other tests available for XTS, this patch simply removes the
>>offending test vectors.
>>
>>Reported-by: Tapas Sarangi <[email protected]>
>>Signed-off-by: Stephan Mueller <[email protected]>
>>---
>> crypto/testmgr.h | 36 ------------------------------------
>> 1 file changed, 36 deletions(-)
>>
>>diff --git a/crypto/testmgr.h b/crypto/testmgr.h
>>index acb6bbf..e4b58f5 100644
>>--- a/crypto/testmgr.h
>>+++ b/crypto/testmgr.h
>>@@ -10179,24 +10179,6 @@ static struct cipher_testvec
>>tf_lrw_dec_tv_template[] = {
>> static struct cipher_testvec tf_xts_enc_tv_template[] = {
>> /* Generated from AES-XTS test vectors */
>> {
>>- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .klen = 32,
>>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .ilen = 32,
>>- .result = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
>>- "\x30\x74\xe4\x44\x52\x77\x97\x43"
>>- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
>>- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
>>- .rlen = 32,
>>- }, {
>> .key = "\x11\x11\x11\x11\x11\x11\x11\x11"
>> "\x11\x11\x11\x11\x11\x11\x11\x11"
>> "\x22\x22\x22\x22\x22\x22\x22\x22"
>>@@ -10522,24 +10504,6 @@ static struct cipher_testvec
>>tf_xts_dec_tv_template[] = {
>> /* Generated from AES-XTS test vectors */
>> /* same as enc vectors with input and result reversed */
>> {
>>- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .klen = 32,
>>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .input = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
>>- "\x30\x74\xe4\x44\x52\x77\x97\x43"
>>- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
>>- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
>>- .ilen = 32,
>>- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .rlen = 32,
>>- }, {
>> .key = "\x11\x11\x11\x11\x11\x11\x11\x11"
>> "\x11\x11\x11\x11\x11\x11\x11\x11"
>> "\x22\x22\x22\x22\x22\x22\x22\x22"
>>--
>>2.7.4
>>
>>
>
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
Am Donnerstag, 11. August 2016, 19:42:54 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hi Stephan,
>
> Any other ideas about this problem ? Since XTS is not amongst the
> self-tests as you observed, is it safe to disable .fips_allowed for
> xts(aes) in testmgr.c ?
If you do that, none of your XTS implementations will be allowed and work in
FIPS mode. The thing is that I cannot reproduce the issue (yet). I am still
looking.
Ciao
Stephan
Hi Tapas,
I was able to reproduce the issue now.
I tested the patch below and it works for me now. Yet, I see that dracut-fips seems to need some fixes too as it cannot find cmac when compiled as module and has some issues with the authenc() ciphers too.
---8<---
In FIPS mode, setting XTS keys where the AES key is identical to the
tweak key is forbidden. Thus, the self test with such property will fail
in FIPS mode.
As we have other tests available for XTS, this patch simply removes the
offending test vectors.
Reported-by: Tapas Sarangi <[email protected]>
Signed-off-by: Stephan Mueller <[email protected]>
---
crypto/testmgr.h | 44 ++++----------------------------------------
1 file changed, 4 insertions(+), 40 deletions(-)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index acb6bbf..893b321 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -15179,8 +15179,8 @@ static struct cipher_testvec cast6_xts_dec_tv_template[] = {
#define HMAC_SHA512_AES_CBC_ENC_TEST_VEC 7
#define AES_LRW_ENC_TEST_VECTORS 8
#define AES_LRW_DEC_TEST_VECTORS 8
-#define AES_XTS_ENC_TEST_VECTORS 5
-#define AES_XTS_DEC_TEST_VECTORS 5
+#define AES_XTS_ENC_TEST_VECTORS 4
+#define AES_XTS_DEC_TEST_VECTORS 4
#define AES_CTR_ENC_TEST_VECTORS 5
#define AES_CTR_DEC_TEST_VECTORS 5
#define AES_OFB_ENC_TEST_VECTORS 1
@@ -18218,25 +18218,7 @@ static struct cipher_testvec aes_lrw_dec_tv_template[] = {
static struct cipher_testvec aes_xts_enc_tv_template[] = {
/* http://grouper.ieee.org/groups/1619/email/pdf00086.pdf */
- { /* XTS-AES 1 */
- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .klen = 32,
- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .ilen = 32,
- .result = "\x91\x7c\xf6\x9e\xbd\x68\xb2\xec"
- "\x9b\x9f\xe9\xa3\xea\xdd\xa6\x92"
- "\xcd\x43\xd2\xf5\x95\x98\xed\x85"
- "\x8c\x02\xc2\x65\x2f\xbf\x92\x2e",
- .rlen = 32,
- }, { /* XTS-AES 2 */
+ { /* XTS-AES 2 */
.key = "\x11\x11\x11\x11\x11\x11\x11\x11"
"\x11\x11\x11\x11\x11\x11\x11\x11"
"\x22\x22\x22\x22\x22\x22\x22\x22"
@@ -18560,25 +18542,7 @@ static struct cipher_testvec aes_xts_enc_tv_template[] = {
static struct cipher_testvec aes_xts_dec_tv_template[] = {
/* http://grouper.ieee.org/groups/1619/email/pdf00086.pdf */
- { /* XTS-AES 1 */
- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .klen = 32,
- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .input = "\x91\x7c\xf6\x9e\xbd\x68\xb2\xec"
- "\x9b\x9f\xe9\xa3\xea\xdd\xa6\x92"
- "\xcd\x43\xd2\xf5\x95\x98\xed\x85"
- "\x8c\x02\xc2\x65\x2f\xbf\x92\x2e",
- .ilen = 32,
- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .rlen = 32,
- }, { /* XTS-AES 2 */
+ { /* XTS-AES 2 */
.key = "\x11\x11\x11\x11\x11\x11\x11\x11"
"\x11\x11\x11\x11\x11\x11\x11\x11"
"\x22\x22\x22\x22\x22\x22\x22\x22"
--
2.7.4
Stephan Mueller <[email protected]> wrote:
> Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller:
>
> Hi Tapas,
>
> I think I found the issue. Can you please test the attached patch?
>
> ---8<---
>
> When calling the DRBG health test in FIPS mode, the Jitter RNG is not
> yet present in the kernel crypto API which will cause the instantiation
> to fail and thus the health test to fail.
>
> As the health tests cover the enforcement of various thresholds, invoke
> the functions that are supposed to enforce the thresholds directly.
>
> This patch also saves precious seed.
>
> Reported-by: Tapas Sarangi <[email protected]>
> Signed-off-by: Stephan Mueller <[email protected]>
Patch applied. Thanks.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Stephan,
Yes, can you give me some more detail about your findings on dracut-fips
!? This seems to be the major difference between our test environments
where a bunch of algorithms are failing self-test during boot with fips=1.
Thanks
-Tapas
On 8/16/16, 4:38 AM, "Stephan Mueller" <[email protected]> wrote:
>Hi Tapas,
>
>I was able to reproduce the issue now.
>
>I tested the patch below and it works for me now. Yet, I see that
>dracut-fips seems to need some fixes too as it cannot find cmac when
>compiled as module and has some issues with the authenc() ciphers too.
>
>
>---8<---
>
>In FIPS mode, setting XTS keys where the AES key is identical to the
>tweak key is forbidden. Thus, the self test with such property will fail
>in FIPS mode.
>
>As we have other tests available for XTS, this patch simply removes the
>offending test vectors.
>
>Reported-by: Tapas Sarangi <[email protected]>
>Signed-off-by: Stephan Mueller <[email protected]>
>---
> crypto/testmgr.h | 44 ++++----------------------------------------
> 1 file changed, 4 insertions(+), 40 deletions(-)
>
>diff --git a/crypto/testmgr.h b/crypto/testmgr.h
>index acb6bbf..893b321 100644
>--- a/crypto/testmgr.h
>+++ b/crypto/testmgr.h
>@@ -15179,8 +15179,8 @@ static struct cipher_testvec
>cast6_xts_dec_tv_template[] = {
> #define HMAC_SHA512_AES_CBC_ENC_TEST_VEC 7
> #define AES_LRW_ENC_TEST_VECTORS 8
> #define AES_LRW_DEC_TEST_VECTORS 8
>-#define AES_XTS_ENC_TEST_VECTORS 5
>-#define AES_XTS_DEC_TEST_VECTORS 5
>+#define AES_XTS_ENC_TEST_VECTORS 4
>+#define AES_XTS_DEC_TEST_VECTORS 4
> #define AES_CTR_ENC_TEST_VECTORS 5
> #define AES_CTR_DEC_TEST_VECTORS 5
> #define AES_OFB_ENC_TEST_VECTORS 1
>@@ -18218,25 +18218,7 @@ static struct cipher_testvec
>aes_lrw_dec_tv_template[] = {
>
> static struct cipher_testvec aes_xts_enc_tv_template[] = {
> /*
>http://scanmail.trustwave.com/?c=4062&d=-96y1wXsB1ZUProHtkc64VYvnNekxXtLFt
>hU_sfSVw&s=5&u=http%3a%2f%2fgrouper%2eieee%2eorg%2fgroups%2f1619%2femail%2
>fpdf00086%2epdf */
>- { /* XTS-AES 1 */
>- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .klen = 32,
>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .ilen = 32,
>- .result = "\x91\x7c\xf6\x9e\xbd\x68\xb2\xec"
>- "\x9b\x9f\xe9\xa3\xea\xdd\xa6\x92"
>- "\xcd\x43\xd2\xf5\x95\x98\xed\x85"
>- "\x8c\x02\xc2\x65\x2f\xbf\x92\x2e",
>- .rlen = 32,
>- }, { /* XTS-AES 2 */
>+ { /* XTS-AES 2 */
> .key = "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x22\x22\x22\x22\x22\x22\x22\x22"
>@@ -18560,25 +18542,7 @@ static struct cipher_testvec
>aes_xts_enc_tv_template[] = {
>
> static struct cipher_testvec aes_xts_dec_tv_template[] = {
> /*
>http://scanmail.trustwave.com/?c=4062&d=-96y1wXsB1ZUProHtkc64VYvnNekxXtLFt
>hU_sfSVw&s=5&u=http%3a%2f%2fgrouper%2eieee%2eorg%2fgroups%2f1619%2femail%2
>fpdf00086%2epdf */
>- { /* XTS-AES 1 */
>- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .klen = 32,
>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .input = "\x91\x7c\xf6\x9e\xbd\x68\xb2\xec"
>- "\x9b\x9f\xe9\xa3\xea\xdd\xa6\x92"
>- "\xcd\x43\xd2\xf5\x95\x98\xed\x85"
>- "\x8c\x02\xc2\x65\x2f\xbf\x92\x2e",
>- .ilen = 32,
>- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .rlen = 32,
>- }, { /* XTS-AES 2 */
>+ { /* XTS-AES 2 */
> .key = "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x22\x22\x22\x22\x22\x22\x22\x22"
>--
>2.7.4
>
>
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
Am Mittwoch, 17. August 2016, 14:52:32 CEST schrieb Tapas Sarangi:
Hi Tapas,
(please, do not top-post)
> Hi Stephan,
>
> Yes, can you give me some more detail about your findings on dracut-fips
> !? This seems to be the major difference between our test environments
> where a bunch of algorithms are failing self-test during boot with fips=1.
cmac must be statically compiled as otherwise dracut-fips does not find it (it
misses it in the module list).
The authenc() cipher must not be compiled as somehow the modprobe in dracut-
fips does not find some components -- I am not sure what the issue is yet. I
even have compiled all parts forming an authenc cipher (authenc, hmac, the
hashes, the block chaining modes, the symmetric ciphers) to be bound into the
kernel statically. But still, something is not found by the tcrypt module in
dracut-fips.
Ciao
Stephan
Hi Stephan,
On 8/17/16, 9:57 AM, "Stephan Mueller" <[email protected]> wrote:
>Am Mittwoch, 17. August 2016, 14:52:32 CEST schrieb Tapas Sarangi:
>
>Hi Tapas,
>
>(please, do not top-post)
DNT, Sorry.
>
>> Hi Stephan,
>>
>> Yes, can you give me some more detail about your findings on dracut-fips
>> !? This seems to be the major difference between our test environments
>> where a bunch of algorithms are failing self-test during boot with
>>fips=1.
>
>cmac must be statically compiled as otherwise dracut-fips does not find
>it (it
>misses it in the module list).
>
>The authenc() cipher must not be compiled as somehow the modprobe in
>dracut-
>fips does not find some components -- I am not sure what the issue is
>yet. I
>even have compiled all parts forming an authenc cipher (authenc, hmac,
>the
>hashes, the block chaining modes, the symmetric ciphers) to be bound into
>the
>kernel statically. But still, something is not found by the tcrypt module
>in
>dracut-fips.
Is that all the authenc() ciphers, or only some of them ? In my patch
where I had disabled .fips_allowed are mostly authenc() ciphers with
cbc(des3_ede) algo. Not all the authenc() ciphers were needed to be
disabled, but some.
For your XTS related findings and patches, are they going to 4.8 or 4.9 ?
Thanks
-Tapas
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
Am Mittwoch, 17. August 2016, 15:09:11 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Is that all the authenc() ciphers, or only some of them ? In my patch
I have not yet had the chance to fully dissect the authenc issue yet.
> where I had disabled .fips_allowed are mostly authenc() ciphers with
> cbc(des3_ede) algo. Not all the authenc() ciphers were needed to be
> disabled, but some.
Can you please point me to your patch?
>
> For your XTS related findings and patches, are they going to 4.8 or 4.9 ?
The XTS patch set is for 4.8-rc1 and should therefore go into 4.9 if accepted
by the maintainer.
Ciao
Stephan
On Tue, Aug 16, 2016 at 11:38:00AM +0200, Stephan Mueller wrote:
> Hi Tapas,
>
> I was able to reproduce the issue now.
>
> I tested the patch below and it works for me now. Yet, I see that dracut-fips seems to need some fixes too as it cannot find cmac when compiled as module and has some issues with the authenc() ciphers too.
>
>
> ---8<---
>
> In FIPS mode, setting XTS keys where the AES key is identical to the
> tweak key is forbidden. Thus, the self test with such property will fail
> in FIPS mode.
>
> As we have other tests available for XTS, this patch simply removes the
> offending test vectors.
>
> Reported-by: Tapas Sarangi <[email protected]>
> Signed-off-by: Stephan Mueller <[email protected]>
We should fix this without removing tests. Perhaps add a field
in the vector to indicate that it should be skipped when in FIPS
mode, just like we do for expected weak keys.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt