Bug 212651 - Module signing & AMD Secure Processor => panic
Summary: Module signing & AMD Secure Processor => panic
Status: NEW
Alias: None
Product: Other
Classification: Unclassified
Component: Modules (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: other_modules
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-12 16:20 UTC by Roman Žilka
Modified: 2021-04-15 09:10 UTC (History)
2 users (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Complete 5.10.27 config w/o CRYPTO_DEV_CCP (110.82 KB, text/plain)
2021-04-12 16:20 UTC, Roman Žilka
Details
Complete 5.4.97 config, CRYPTO_DEV_CCP=y, MODULE_SIG=n (97.57 KB, text/plain)
2021-04-12 16:25 UTC, Roman Žilka
Details
dmesg, 5.10.27, CRYPTO_DEV_CCP=n, MODULE_SIG=y (61.21 KB, text/plain)
2021-04-12 16:28 UTC, Roman Žilka
Details
Crash screen 1 (867.16 KB, image/png)
2021-04-12 17:13 UTC, Roman Žilka
Details
Crash screen 2 (715.27 KB, image/png)
2021-04-12 17:18 UTC, Roman Žilka
Details
Crash screen 3 (1.23 MB, image/png)
2021-04-12 17:37 UTC, Roman Žilka
Details
cpuid (30.72 KB, text/plain)
2021-04-14 19:44 UTC, Roman Žilka
Details
Crash screen with CONFIG_CRYPTO_DEV_CCP_CRYPTO=m (1.21 MB, image/png)
2021-04-15 09:10 UTC, Roman Žilka
Details

Description Roman Žilka 2021-04-12 16:20:50 UTC
Created attachment 296337 [details]
Complete 5.10.27 config w/o CRYPTO_DEV_CCP

Hello,

on an x86_64 Gentoo PC I get a kernel panic during kernel boot when:
CONFIG_MODULE_SIG=y (Module signature verification)
CONFIG_CRYPTO_DEV_CCP=y (Support for AMD Secure Processor)

More precisely, this is the complete config diff which causes it:
3302d3301
< CONFIG_DMA_ENGINE=y
3319,3324d3317
< # DMA Clients
< #
< # CONFIG_ASYNC_TX_DMA is not set
< # CONFIG_DMATEST is not set
< 
< #
3834c3827
< CONFIG_CRYPTO_NULL=y
---
> CONFIG_CRYPTO_NULL=m
3838c3831
< CONFIG_CRYPTO_AUTHENC=y
---
> CONFIG_CRYPTO_AUTHENC=m
3914,3915c3907,3908
< CONFIG_CRYPTO_SHA1=y
< CONFIG_CRYPTO_SHA1_SSSE3=y
---
> # CONFIG_CRYPTO_SHA1 is not set
> # CONFIG_CRYPTO_SHA1_SSSE3 is not set
3986c3979
< CONFIG_CRYPTO_LIB_AES=y
---
> CONFIG_CRYPTO_LIB_AES=m
3994,4012c3987
< CONFIG_CRYPTO_HW=y
< # CONFIG_CRYPTO_DEV_PADLOCK is not set
< # CONFIG_CRYPTO_DEV_ATMEL_ECC is not set
< # CONFIG_CRYPTO_DEV_ATMEL_SHA204A is not set
< CONFIG_CRYPTO_DEV_CCP=y
< CONFIG_CRYPTO_DEV_CCP_DD=y
< CONFIG_CRYPTO_DEV_SP_CCP=y
< CONFIG_CRYPTO_DEV_CCP_CRYPTO=y
< # CONFIG_CRYPTO_DEV_SP_PSP is not set
< # CONFIG_CRYPTO_DEV_CCP_DEBUGFS is not set
< # CONFIG_CRYPTO_DEV_QAT_DH895xCC is not set
< # CONFIG_CRYPTO_DEV_QAT_C3XXX is not set
< # CONFIG_CRYPTO_DEV_QAT_C62X is not set
< # CONFIG_CRYPTO_DEV_QAT_DH895xCCVF is not set
< # CONFIG_CRYPTO_DEV_QAT_C3XXXVF is not set
< # CONFIG_CRYPTO_DEV_QAT_C62XVF is not set
< # CONFIG_CRYPTO_DEV_NITROX_CNN55XX is not set
< # CONFIG_CRYPTO_DEV_SAFEXCEL is not set
< # CONFIG_CRYPTO_DEV_AMLOGIC_GXL is not set
---
> # CONFIG_CRYPTO_HW is not set


No Secure Boot, booting in UEFI mode. MOBO: Gigabyte B450M S2H, BIOS F40, later F51 (https://www.gigabyte.com/Motherboard/B450M-S2H-rev-1x/support#support-dl-bios). Hit the bug on:
- multiple kernel vers between 5.4.28 and 5.4.60, gcc 9.[23].0
- 5.10.27, gcc 10.2.0
Always vanilla sources + Gentoo patchset w/o experimental Gentoo features like the extra -O and -marchs.

The panic usually occurs before /sbin/init, but on rare occassion I would get a portion of systemd boot (with lots of errors). The cause reported is usually an Oops, but GPFs do happen too. Most of the time, the panic message indicates some of the usual modules have been loaded.

Attached is my complete 5.10.27 config with the Secure Processor disabled.
Comment 1 Roman Žilka 2021-04-12 16:25:25 UTC
Created attachment 296339 [details]
Complete 5.4.97 config, CRYPTO_DEV_CCP=y, MODULE_SIG=n
Comment 2 Roman Žilka 2021-04-12 16:28:18 UTC
Created attachment 296341 [details]
dmesg, 5.10.27, CRYPTO_DEV_CCP=n, MODULE_SIG=y
Comment 3 Roman Žilka 2021-04-12 17:13:08 UTC
Created attachment 296347 [details]
Crash screen 1
Comment 4 Roman Žilka 2021-04-12 17:18:37 UTC
Created attachment 296349 [details]
Crash screen 2
Comment 5 Roman Žilka 2021-04-12 17:37:53 UTC
Created attachment 296353 [details]
Crash screen 3

Forgot about this one time I got all the way to an emergency shell. Panic moments later.
Comment 6 John Allen 2021-04-14 18:23:50 UTC
Hi Roman,

What is the specific processor you are using? A similar problem was reported a while ago, but I could never reproduce it on the hardware I have available (Naples server CPUs).

Thanks,
John
Comment 7 Roman Žilka 2021-04-14 19:44:59 UTC
Created attachment 296389 [details]
cpuid

Hi John,

it's a Ryzen 3 1200, the original 14nm model, running ucode 0x8001138. Building the file "amd/amd_sev_fam17h_model0xh.sbin" (MD5 64c8b9ac6b5e2ba5649b5e26f7bb7232) from linux-firmware into the kernel has no effect. Cpuid goes on to say (full output attached):
   AMD Secure Encryption (0x8000001f):
      SME: secure memory encryption support    = true
      SEV: secure encrypted virtualize support = true
      VM page flush MSR support                = true
      SEV-ES: SEV encrypted state support      = false
      SEV-SNP: SEV secure nested paging        = false
      VMPL: VM permission levels               = false
      hardware cache coher across enc domains  = false
      SEV guest exec only from 64-bit host     = false
      restricted injection                     = false
      alternate injection                      = false
      full debug state swap for SEV-ES guests  = false
      disallowing IBS use by host              = false
      encryption bit position in PTE           = 0x2f (47)
      physical address space width reduction   = 0x5 (5)
      number of VM permission levels           = 0x0 (0)
      number of SEV-enabled guests supported   = 0xf (15)
      minimum SEV guest ASID                   = 0x0 (0)

Thank you for your effort.
Comment 8 thomas.lendacky 2021-04-14 21:15:54 UTC
This issue has nothing to do the AMD memory encryption feature, it is an issue with the CCP driver. If you change your kernel config to:

CONFIG_CRYPTO_DEV_CCP_CRYPTO=m or
CONFIG_CRYPTO_DEV_CCP_CRYPTO=n

the problem will go away (but will still need to be fixed). The CONFIG_CRYPTO_DEV_CCP_CRYPTO option builds the ccp-crypto module, which participates in the kernel crypto API, and so is used to validate the module signatures. If you set that particular config to "m", the module will not autoload so the boot will be successful.
Comment 9 Roman Žilka 2021-04-15 09:10:10 UTC
Created attachment 296393 [details]
Crash screen with CONFIG_CRYPTO_DEV_CCP_CRYPTO=m

That worked. I'm now running this (kernel 5.10.27, signed modules) and all is fine:
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_CCP=y
CONFIG_CRYPTO_DEV_CCP_DD=y
CONFIG_CRYPTO_DEV_SP_CCP=y
# CONFIG_CRYPTO_DEV_CCP_CRYPTO is not set
# CONFIG_CRYPTO_DEV_SP_PSP is not set
# CONFIG_CRYPTO_DEV_CCP_DEBUGFS is not set

I first tried the above, except CONFIG_CRYPTO_DEV_CCP_CRYPTO=m. The system booted completely and ran fine. The usual modules had gotten auto-loaded, ccp-crypto hadn't. Just to test, I loaded it by hand and then loaded a bunch of random modules - all ok. Then I started an unrelated application and the kernel crashed (screenshot).

Note You need to log in before you can comment on or make changes to this bug.