Greeting,
FYI, we noticed the following commit (built with clang-14):
commit: d3b04a4398fe8022c9ca4b5ac6ab08059334b180 ("security: DH - use KDF implementation from crypto API")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: boot
on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+------------------------------------------------------+------------+------------+
| | d792134423 | d3b04a4398 |
+------------------------------------------------------+------------+------------+
| boot_successes | 14 | 0 |
| boot_failures | 0 | 16 |
| WARNING:at_crypto/kdf_sp800108.c:#crypto_kdf108_init | 0 | 16 |
| EIP:crypto_kdf108_init | 0 | 16 |
+------------------------------------------------------+------------+------------+
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <[email protected]>
[ 18.648980][ T1] WARNING: CPU: 0 PID: 1 at crypto/kdf_sp800108.c:138 crypto_kdf108_init (crypto/kdf_sp800108.c:136)
[ 18.649900][ T1] Modules linked in:
[ 18.650289][ T1] CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc1-00049-gd3b04a4398fe #1
[ 18.651136][ T1] EIP: crypto_kdf108_init (crypto/kdf_sp800108.c:136)
[ 18.651676][ T1] Code: ff ff 0f 44 f8 89 da 83 c2 08 89 d8 e8 cf 72 fa fe 89 f0 e8 08 70 eb fe 85 ff 74 39 57 68 39 26 d3 b1 e8 e9 4c d8 fe 83 c4 08 <0f> 0b 89 f8 5e 5f 5b 5d c3 68 85 74 d6 b1 68 85 17 d6 b1 e8 85 15
All code
========
0: ff (bad)
1: ff 0f decl (%rdi)
3: 44 f8 rex.R clc
5: 89 da mov %ebx,%edx
7: 83 c2 08 add $0x8,%edx
a: 89 d8 mov %ebx,%eax
c: e8 cf 72 fa fe callq 0xfffffffffefa72e0
11: 89 f0 mov %esi,%eax
13: e8 08 70 eb fe callq 0xfffffffffeeb7020
18: 85 ff test %edi,%edi
1a: 74 39 je 0x55
1c: 57 push %rdi
1d: 68 39 26 d3 b1 pushq $0xffffffffb1d32639
22: e8 e9 4c d8 fe callq 0xfffffffffed84d10
27: 83 c4 08 add $0x8,%esp
2a:* 0f 0b ud2 <-- trapping instruction
2c: 89 f8 mov %edi,%eax
2e: 5e pop %rsi
2f: 5f pop %rdi
30: 5b pop %rbx
31: 5d pop %rbp
32: c3 retq
33: 68 85 74 d6 b1 pushq $0xffffffffb1d67485
38: 68 85 17 d6 b1 pushq $0xffffffffb1d61785
3d: e8 .byte 0xe8
3e: 85 .byte 0x85
3f: 15 .byte 0x15
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: 89 f8 mov %edi,%eax
4: 5e pop %rsi
5: 5f pop %rdi
6: 5b pop %rbx
7: 5d pop %rbp
8: c3 retq
9: 68 85 74 d6 b1 pushq $0xffffffffb1d67485
e: 68 85 17 d6 b1 pushq $0xffffffffb1d61785
13: e8 .byte 0xe8
14: 85 .byte 0x85
15: 15 .byte 0x15
[ 18.653613][ T1] EAX: 0000003a EBX: 80000000 ECX: 00000000 EDX: b2cebcf0
[ 18.654334][ T1] ESI: b61c9310 EDI: fffffff4 EBP: b2cebdf0 ESP: b2cebde4
[ 18.655050][ T1] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010296
[ 18.655814][ T1] CR0: 80050033 CR2: 00000000 CR3: 02341000 CR4: 00040690
[ 18.656516][ T1] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 18.657216][ T1] DR6: fffe0ff0 DR7: 00000400
[ 18.657668][ T1] Call Trace:
[ 18.658019][ T1] ? __initstub__kmod_pkcs8_key_parser__180_176_pkcs8_key_init6 (crypto/kdf_sp800108.c:148)
[ 18.658857][ T1] __initstub__kmod_kdf_sp800108__96_148_crypto_kdf108_init6 (crypto/kdf_sp800108.c:148)
[ 18.659980][ T1] do_one_initcall (init/main.c:1297)
[ 18.660507][ T1] ? __initstub__kmod_pkcs8_key_parser__180_176_pkcs8_key_init6 (crypto/kdf_sp800108.c:148)
[ 18.661375][ T1] do_initcall_level (init/main.c:1369)
[ 18.661842][ T1] ? rest_init (init/main.c:1491)
[ 18.662268][ T1] do_initcalls (init/main.c:1383)
[ 18.662691][ T1] do_basic_setup (init/main.c:1406)
[ 18.663144][ T1] kernel_init_freeable (init/main.c:1614)
[ 18.663653][ T1] kernel_init (kernel/async.c:257 kernel/async.c:244 init/main.c:1501)
[ 18.664089][ T1] ret_from_fork (??:?)
[ 18.664544][ T1] irq event stamp: 175171
[ 18.664971][ T1] hardirqs last enabled at (175179): __up_console_sem (arch/x86/include/asm/irqflags.h:45 arch/x86/include/asm/irqflags.h:80 arch/x86/include/asm/irqflags.h:140 kernel/printk/printk.c:255)
[ 18.665846][ T1] hardirqs last disabled at (175188): __up_console_sem (kernel/printk/printk.c:253)
[ 18.666710][ T1] softirqs last enabled at (173350): do_softirq_own_stack (arch/x86/kernel/irq_32.c:60 arch/x86/kernel/irq_32.c:150)
[ 18.667665][ T1] softirqs last disabled at (173341): do_softirq_own_stack (arch/x86/kernel/irq_32.c:60 arch/x86/kernel/irq_32.c:150)
[ 18.668625][ T1] random: get_random_bytes called from __warn+0xc1/0x140 with crng_init=0
[ 18.668633][ T1] ---[ end trace b93351358662f7fd ]---
[ 18.670099][ T1] start plist test
[ 18.671957][ T1] end plist test
[ 18.673358][ T1] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[ 18.674227][ T1] ACPI: button: Power Button [PWRF]
[ 18.818315][ T1] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 18.819246][ T1] serial 00:05: GPIO lookup for consumer rs485-term
[ 18.819988][ T1] serial 00:05: using ACPI for GPIO lookup
[ 18.820589][ T1] acpi PNP0501:00: GPIO: looking up rs485-term-gpios
[ 18.821240][ T1] acpi PNP0501:00: GPIO: looking up rs485-term-gpio
[ 18.821876][ T1] serial 00:05: using lookup tables for GPIO lookup
[ 18.822547][ T1] serial 00:05: No GPIO consumer rs485-term found
[ 18.823340][ T1] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 18.825623][ T1] serial 00:06: GPIO lookup for consumer rs485-term
[ 18.826321][ T1] serial 00:06: using ACPI for GPIO lookup
[ 18.826881][ T1] acpi PNP0501:01: GPIO: looking up rs485-term-gpios
[ 18.827549][ T1] acpi PNP0501:01: GPIO: looking up rs485-term-gpio
[ 18.828236][ T1] serial 00:06: using lookup tables for GPIO lookup
[ 18.828923][ T1] serial 00:06: No GPIO consumer rs485-term found
[ 18.829702][ T1] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 18.836645][ T1] platform pc8736x_gpio.0: NatSemi pc8736x GPIO Driver Initializing
[ 18.837502][ T1] platform pc8736x_gpio.0: no device found
[ 18.838140][ T1] nsc_gpio initializing
[ 18.845377][ T1] e1000: Intel(R) PRO/1000 Network Driver
[ 18.846008][ T1] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 19.127869][ T1] ACPI: _SB_.LNKC: Enabled at IRQ 11
[ 19.466405][ T1] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56
[ 19.467380][ T1] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[ 19.468499][ T1] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
[ 19.475314][ T1] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 19.476051][ T1] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 19.487285][ T1] i2c_dev: i2c /dev entries driver
[ 19.494003][ T3] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
[ 19.497043][ T1] Driver for 1-wire Dallas network protocol.
[ 19.511630][ T1] Driver 'memconsole' was unable to register with bus_type 'coreboot' because the bus was not initialized.
[ 19.512985][ T1] SPI driver xlnx-slave-spi has no spi_device_id for xlnx,fpga-slave-serial
[ 19.517806][ T1] NET: Registered PF_INET6 protocol family
[ 19.518593][ T1] random: get_random_u32 called from neigh_hash_alloc+0x54/0xd0 with crng_init=0
[ 19.526205][ T1] Segment Routing with IPv6
[ 19.526785][ T1] In-situ OAM (IOAM) with IPv6
[ 19.529269][ T1] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 19.536497][ T1] NET: Registered PF_PACKET protocol family
[ 19.537223][ T1] 9pnet: Installing 9P2000 support
[ 19.538234][ T1] ... APIC ID: 00000000 (0)
[ 19.538743][ T1] ... APIC VERSION: 00050014
[ 19.539125][ T1] 0000000000000000000000000000000000000000000000000000000000000000
[ 19.539125][ T1] 0000000000000000000000000000000000000000000000000000000000001000
[ 19.539125][ T1]
[ 19.542112][ T1] number of MP IRQ sources: 15.
[ 19.542621][ T1] number of IO-APIC #0 registers: 24.
[ 19.543182][ T1] testing the IO APIC.......................
[ 19.544281][ T1] IO APIC #0......
[ 19.544687][ T1] .... register #00: 00000000
[ 19.545208][ T1] ....... : physical APIC id: 00
[ 19.545730][ T1] ....... : Delivery Type: 0
[ 19.546212][ T1] ....... : LTS : 0
[ 19.546682][ T1] .... register #01: 00170011
[ 19.547164][ T1] ....... : max redirection entries: 17
[ 19.547775][ T1] ....... : PRQ implemented: 0
[ 19.548308][ T1] ....... : IO APIC version: 11
[ 19.548840][ T1] .... register #02: 00000000
[ 19.549320][ T1] ....... : arbitration: 00
[ 19.549817][ T1] .... IRQ redirection table:
[ 19.550293][ T1] IOAPIC 0:
[ 19.550616][ T1] pin00, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.551513][ T1] pin01, enabled , edge , high, V(22), IRR(0), S(0), logical , D(0001), M(0)
[ 19.552435][ T1] pin02, enabled , edge , high, V(30), IRR(0), S(0), logical , D(0001), M(0)
[ 19.553416][ T1] pin03, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.554350][ T1] pin04, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.555264][ T1] pin05, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.556199][ T1] pin06, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.557158][ T1] pin07, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.558041][ T1] pin08, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.558974][ T1] pin09, enabled , level, high, V(20), IRR(0), S(0), logical , D(0001), M(0)
[ 19.559951][ T1] pin0a, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.560874][ T1] pin0b, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.561787][ T1] pin0c, enabled , edge , high, V(21), IRR(0), S(0), logical , D(0001), M(0)
[ 19.562724][ T1] pin0d, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
[ 19.563702][ T1] pin0e, disabled, edge , high, V(00), IRR(0), S(0), physical, D(0000), M(0)
To reproduce:
# build kernel
cd linux
cp config-5.16.0-rc1-00049-gd3b04a4398fe .config
make HOSTCC=clang-14 CC=clang-14 ARCH=i386 olddefconfig prepare modules_prepare bzImage modules
make HOSTCC=clang-14 CC=clang-14 ARCH=i386 INSTALL_MOD_PATH=<mod-install-dir> modules_install
cd <mod-install-dir>
find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
---
0DAY/LKP+ Test Infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/[email protected] Intel Corporation
Thanks,
Oliver Sang
Am Dienstag, 30. November 2021, 09:04:19 CET schrieb kernel test robot:
Hi,
...
>
>
> +------------------------------------------------------+------------+-------
> -----+
> | | d792134423 |
> | | d3b04a4398 |
>
> +------------------------------------------------------+------------+-------
> -----+
> | boot_successes | 14 | 0
> | | boot_failures | 0 |
> | 16 | WARNING:at_crypto/kdf_sp800108.c:#crypto_kdf108_init | 0
> | | 16 | EIP:crypto_kdf108_init
> | | 0 | 16 |
> +------------------------------------------------------+------------+-------
> -----+
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot <[email protected]>
>
>
> [ 18.648980][ T1] WARNING: CPU: 0 PID: 1 at crypto/kdf_sp800108.c:138
> crypto_kdf108_init (crypto/kdf_sp800108.c:136) [ 18.649900][ T1]
> Modules linked in:
The issue is that the self-test fails for 16 out of 30 times, i.e. it is kind
of random when it happens or not.
I am unable to reproduce it with i386 and clang-13. I can also not reproduce
it with GCC.
Nor do I see an obvious issue in the code that points to either uninitizlized
memory or otherwise could affect the test result.
I keep trying with Clang-14
Ciao
Stephan
Hi Stephan,
On 12/5/2021 6:21 PM, Stephan Müller wrote:
> Am Dienstag, 30. November 2021, 09:04:19 CET schrieb kernel test robot:
>
> Hi,
>
> ...
>>
>>
>> +------------------------------------------------------+------------+-------
>> -----+
>> | | d792134423 |
>> | | d3b04a4398 |
>>
>> +------------------------------------------------------+------------+-------
>> -----+
>> | boot_successes | 14 | 0
>> | | boot_failures | 0 |
>> | 16 | WARNING:at_crypto/kdf_sp800108.c:#crypto_kdf108_init | 0
>> | | 16 | EIP:crypto_kdf108_init
>> | | 0 | 16 |
>> +------------------------------------------------------+------------+-------
>> -----+
>>
>>
>> If you fix the issue, kindly add following tag
>> Reported-by: kernel test robot <[email protected]>
>>
>>
>> [ 18.648980][ T1] WARNING: CPU: 0 PID: 1 at crypto/kdf_sp800108.c:138
>> crypto_kdf108_init (crypto/kdf_sp800108.c:136) [ 18.649900][ T1]
>> Modules linked in:
>
> The issue is that the self-test fails for 16 out of 30 times, i.e. it is kind
> of random when it happens or not.
+------------------------------------------------------+------------+------------+
| | d792134423 | d3b04a4398 |
+------------------------------------------------------+------------+------------+
| boot_successes | 14 | 0 |
| boot_failures | 0 | 16 |
| WARNING:at_crypto/kdf_sp800108.c:#crypto_kdf108_init | 0 | 16 |
| EIP:crypto_kdf108_init | 0 | 16 |
+------------------------------------------------------+------------+------------+
This table shows that we have tested commit d3b04a4398("security: DH - use KDF
implementation from crypto API") for several runs of boot test in qemu but got
100% bad result. We have also tested its parent commit (i.e. commit d792134423
"security: DH - remove dead code for zero padding") and all the runs got 100%
good result. So this is not a random issue.
>
> I am unable to reproduce it with i386 and clang-13. I can also not reproduce
> it with GCC.
We have tested the i386 kernel built by gcc-9 or clang-14, and confirmed both
of them can reproduce this issue reliably.
Please be sure to follow the reproduce steps in original report mail. The full
reproduce log is attached.
>
> Nor do I see an obvious issue in the code that points to either uninitizlized
> memory or otherwise could affect the test result.
the dmesg warning introduced by commit d3b04a4398 is:
[ 11.061347][ T1] alg: kdf: could not allocate hash handle for hmac(sha256)
[ 11.061744][ T1] ------------[ cut here ]------------
[ 11.062032][ T1] alg: self-tests for CTR-KDF (hmac(sha256)) failed (rc=-12)
[ 11.062454][ T1] WARNING: CPU: 0 PID: 1 at crypto/kdf_sp800108.c:136 crypto_kdf108_init+0xec/0x107
[ 11.062959][ T1] Modules linked in:
[ 11.063164][ T1] CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc1-13186-gd3b04a4398fe #1
[ 11.063624][ T1] EIP: crypto_kdf108_init+0xec/0x107
...
We noticed that commit d3b04a4398 added "select CONFIG_CRYPTO_KDF800108_CTR" in
security/keys/Kconfig, so we speculate that this issue may have connection with
other code controlled by this config, not limited to the code introduced in
this commit. In other words, this is more likely a "For your reference" report.
Regards,
Yujie
Am Freitag, 10. Dezember 2021, 03:54:32 CET schrieb Yujie Liu:
Hi Yujie, Herbert,
> This table shows that we have tested commit d3b04a4398("security: DH - use
> KDF implementation from crypto API") for several runs of boot test in qemu
> but got 100% bad result. We have also tested its parent commit (i.e. commit
> d792134423 "security: DH - remove dead code for zero padding") and all the
> runs got 100% good result. So this is not a random issue.
>
> > I am unable to reproduce it with i386 and clang-13. I can also not
> > reproduce it with GCC.
>
> We have tested the i386 kernel built by gcc-9 or clang-14, and confirmed
> both of them can reproduce this issue reliably.
>
> Please be sure to follow the reproduce steps in original report mail. The
> full reproduce log is attached.
Thank you for your response. The key log info is:
alg: self-tests for CTR-KDF (hmac(sha256)) failed (rc=-12)
And I finally see what the problem is: you selected SHA-256 as module but the
KDF implementation is selected to be statically linked.
So the KDF self test tries to allocate the SHA-256 algorithm and fails which
causes the ENOMEM error.
Herbert, what is your preference in handling this:
- we could SELECT CRYPTO_SHA256 when the KDF is compiled. This would only be
necessary to satisfy the self test. Yet, there is no guarantee that SHA-256
would truly be needed because the DH code that calls the KDF obtains the
reference to the hash from user space. In the end we could hard compile a
crypto algorithm into the kernel that may never be used.
- we could relax the KDF self test a bit and could prevent the self test being
executed if we get an ENOENT back during the algorithm allocation. But that
would imply that the KDF self test would never be executed. Even when SHA-256
is compiled as module and insmod'ed at a later time the KDF self test is not
executed as it is only executed from the __init function.
I would prefer to consider the first option to also statically compile
SHA-256.
Ciao
Stephan
On Fri, Dec 10, 2021 at 03:16:34PM +0100, Stephan Mueller wrote:
>
> Herbert, what is your preference in handling this:
>
> - we could SELECT CRYPTO_SHA256 when the KDF is compiled. This would only be
> necessary to satisfy the self test. Yet, there is no guarantee that SHA-256
> would truly be needed because the DH code that calls the KDF obtains the
> reference to the hash from user space. In the end we could hard compile a
> crypto algorithm into the kernel that may never be used.
...
> I would prefer to consider the first option to also statically compile
> SHA-256.
I think KDF800108_CTR should select SHA256 instead of HASH.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt