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.
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_other
URL:
Keywords:
Depends on:
Blocks:
 
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
Tree: Mainline
Regression: No


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

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.

https://lkml.org/lkml/2018/2/21/812

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.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.16.y&id=9023a578c1a807dd7103cd0ad61eeef56055878f
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 1.0.0.4C & 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:

https://bugzilla.kernel.org/show_bug.cgi?id=199267
https://bugzilla.kernel.org/show_bug.cgi?id=201129
https://bugzilla.redhat.com/show_bug.cgi?id=1608242

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 1.0.0.4C & Linux Kernel
To: <ng0177@gmail.com>, <linux-crypto@vger.kernel.org>
Cc: <brijesh.singh@amd.com>

Hi,

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

https://marc.info/?l=linux-crypto-vger&m=153436754612783&w=2

And patch is accepted in crypto tree

https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=3702a0585e64d70d5bf73bf3e943b8d6005b72c1

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

-Brijesh

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