Bug 199267 - A6-6310 APU, enabling CONFIG_CRYPTO_DEV_SP_PSP cause kernel panic on early boot.
Summary: A6-6310 APU, enabling CONFIG_CRYPTO_DEV_SP_PSP cause kernel panic on early boot.
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_other
Depends on:
Reported: 2018-04-03 13:02 UTC by Przemek
Modified: 2018-09-23 08:19 UTC (History)
3 users (show)

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

picture of the screen when kernel panic occured (663.04 KB, image/jpeg)
2018-04-03 13:02 UTC, Przemek
picture v2 (564.10 KB, image/jpeg)
2018-04-03 13:03 UTC, Przemek
dmesg without SP_PSP enabled (57.94 KB, text/plain)
2018-04-03 13:05 UTC, Przemek
kernel 4.16 config file (118.31 KB, text/plain)
2018-04-03 13:07 UTC, Przemek

Description Przemek 2018-04-03 13:02:56 UTC
Created attachment 275071 [details]
picture of the screen when kernel panic occured

Hi all,
I am using gentoo on Lenovo g50-45 netbook with AMD APU A6-6310 mullins, and kernel 4.16.

This APU have arm cortex-A5 called AMD's PSP TrustZone processor on-board, and was introduced in April 29th of 2014.

Enabling CONFIG_CRYPTO_DEV_SP_PSP module is causing a kernel panic. (BTW it is enabled by default in kernel's .config file during "make oldconfig")

Since kernel panic occurs very early I cannot get anything in dmesg so I took a picture of the screen when panic happen.

Moreover, I attached dmesg without CONFIG_CRYPTO_DEV_SP_PSP being enabled and full kernel's .config file.
Comment 1 Przemek 2018-04-03 13:03:54 UTC
Created attachment 275073 [details]
picture v2

picture v2
Comment 2 Przemek 2018-04-03 13:05:01 UTC
Created attachment 275075 [details]
dmesg without SP_PSP enabled
Comment 3 Przemek 2018-04-03 13:07:09 UTC
Created attachment 275077 [details]
kernel 4.16 config file
Comment 4 Przemek 2018-04-06 09:14:12 UTC
Ok than, it seems that I have answered myself.

I have red that this APU does not support PSP/SEV firmware, and have found the LKML post with patch which enable additional checks if PSP/SEV firmware is supported like on Ryzen CPU.


Manually applying this patch resolved problem with kernel panic at boot time.

I also wonder why this patch has not been merged yet to 4.16 tree since is dated 21 Feb 2018, so I will keep this bug open till merge.
Comment 5 Andreas 2018-04-08 15:27:36 UTC
I just hit the same issue. I had a working .config from 4.15.14. On 4.16.0 I did a "make oldconfig" and psp seemed like something I could try. Also, I think, it is the default setting when just hitting enter.

I have a Ryzen 7 system (1800X, ASUS PRIME X370-PRO).

With CRYPTO_DEV_SP_PSP enabled, this is the last I see before the kernel panic:

ccp 0000:0d:00.2: enabling device (0000 -> 0002)
ccp 0000:0d:00.2: ccp enabled
ccp 0000:0d:00.2: psp initialization failed
ccp 0000:0d:00.2: enabled
BUG: unable to handle kernel NULL pointer dereference at 0000000000000073
IP: 0xffffffffb34d0988
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
Modules linked in:
CPU:5 PID: 1 Comm: swapper/0 Not tainted 4.16.0-gentoo #1
Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 3803 01/22/2018
RIP: 0010:0xffffffffb34d0988
RSP: 0018:ffffa20bc005be58 EFLAGS: 00010082
RAX: ffffffffb34d0981 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 00000000000000ff RSI: ffff906337bd1000 RDI: ffffffffb3d5da8c
RBP: 0000000000000246 R08: 0000000000000000 R09: ffff906337bd114e
R10: ffff90633a58b268 R11: ffff906337bd1161 R12: ffffffffb3c91640
R13: 0000000000000007 R14: ffffffffb3b63834 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff90635ed40000(0000) knlFS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000073 CR3: 000000026e60a000 CR4: 00000000003406e0
Call Trace:
 ? sp_get_psp_master_device+0x54/0x70
 ? efibc_init+0x33/0x33
 ? psp_pci_init+0x1b/0xd0
 ? efibc_init+0x33/0x33
 ? sp_mod_init+0x11/0x15
 ? do_one_initcall+0x49/0x190
 ? kernel_init_freeable+0x119/0x19b
 ? rest_init+0xb0/0xb0
 ? kernel_init+0x5/0x100
 ? ret_from_fork+0x22/0x40
Code: 6e 74 72 79 52 65 62 6f 6f 74 52 65 61 73 6f 6e 00 4c 6f 61 64 65 72 45 6e 74 72 79 4f 6e 65 53 68 6f 74 00 b0 2e 31 2e 30 00 6d <69> 73 73 69 6e 67 20 64 72 69 76 65 72 20 64 61 74 61 0a 00 44
RIP: 0xffffffffb34d0988 RSP: ffffa20bc005be58
CR2: 0000000000000073
---[ end trace c3daf89eade7be35 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00800009

Kernel Offset: 0x31000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00800009
Comment 6 Przemek 2018-05-03 11:26:36 UTC
I am closing this bug report since the patch has been pulled in to the 4.16.7 stable kernel.

Comment 7 Thomas Biesinger 2018-09-14 12:31:46 UTC
Is this unresolved issue related?
Comment 8 Przemek 2018-09-14 18:18:29 UTC
(In reply to Thomas Biesinger from comment #7)
> Is this unresolved issue related?

Which one?
If you mean this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=201129 IMHO it is not.

The patch has added only extra checking function to determine if machine firmware support PSP/SEV and then activate the master device on valid hardware. ("i->get_psp_master_device").

Personally I think that good move would be add Brijesh Singh <brijesh.singh@amd.com> (the author of this patch) to the CC list of your bug report.
Comment 9 Przemek 2018-09-14 18:26:34 UTC
I have forget to add that I have CONFIG_CRYPTO_DEV_SP_PSP=y whole the time in my .config and don't have kernel panic. Machine is using 4.18.7 stable.
Comment 10 Thomas Biesinger 2018-09-14 18:29:00 UTC
Yep, good idea but I do not see how:

CC:	brijesh.singh@amd.com did not match anything

Sorry that I forgot to attach the link - well spotted.
Comment 11 Przemek 2018-09-14 18:41:20 UTC
(In reply to Thomas Biesinger from comment #10)
> Yep, good idea but I do not see how:
> CC:   brijesh.singh@amd.com did not match anything
> Sorry that I forgot to attach the link - well spotted.

Top, right corner of the screen in your bug report:
CC List: -> (edit) -> paste email adress -> Save Changes.
Comment 12 Thomas Biesinger 2018-09-14 19:43:08 UTC
It looks like only registered addresses can be added. I now have soprwa@gmail.com on the list.
Comment 13 Przemek 2018-09-14 20:36:18 UTC
It seems that you are right about registered users.
soprwa@gmail.com this is my account email address.
You could send just an email and attach a bug report link from bugzilla and redhat web page to this guy, or post an email in LKML list (linux-crypto@vger.kernel.org - presumably, for valid mailing lists please see http://vger.kernel.org/vger-lists.html) and wait if someone will respond, eventually wait if someone in bugzilla will address it properly.
Comment 14 Thomas Biesinger 2018-09-15 08:58:40 UTC
From: <ng0177@gmail.com>
Date: Sat, Sep 15, 2018 at 10:57 AM
Subject: AM4 BIOS AGESA Code & Linux Kernel
To: <brijesh.singh@amd.com>, <linux-crypto@vger.kernel.org>

Hi, please find below a list of related bugs to a blocker that affects existing systems and even prevents the installation of several Linux distributions:


I read about an upstream fix to 4.20 but this is a long way to go. I guess that anyone who keeps their AM4 BIOS AGESA Code update-to-date and would like to run Linux is affected.

A co-operation between AMD & Linux Kernel experts to achieve a solution fast is encouraged. Thank you!
Comment 15 Thomas Biesinger 2018-09-15 12:31:43 UTC
From: Brijesh Singh <brijesh.singh@amd.com>
Date: Sat, Sep 15, 2018 at 1:44 PM
Subject: Re: AM4 BIOS AGESA Code & Linux Kernel
To: <ng0177@gmail.com>, <linux-crypto@vger.kernel.org>
Cc: <brijesh.singh@amd.com>


The workaround to handle this FW bug has been submitted last month


And patch is accepted in crypto tree


It will soon show up in Linus tree. After that we will work to get it
backport to stable tree's.


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