Linux 6.5 To Add Support For Some New AMD CCP Hardware

[phoronix]

Phoronix: Linux 6.5 To Add Support For Some New AMD CCP Hardware

The upcoming Linux 6.5 kernel is set to add support for some new hardware to AMD's decade-old cryptographic co-processor (CCP) driver...

https://www.phoronix.com/news/Linux-6.5-New-AMD-CCP-Hardware

[kiffmet]

The "old" CCPs, and thus also SHA and AES acceleration, RAM encryption and SEV don't work in Linux. The choice of mainboard doesn't matter, the same goes for desktop Ryzen 3000/5000 - the driver can't even initialize the CCP device (PSP does activate though). This indicates a firmware issue.

On Windows, the device can be initialized and the AMD provided driver loads successfully. If that isn't a dummy driver to make device manager shut up about an unknown device, then this indicates an issue with the Linux driver.

[Anux]

The "old" CCPs, and thus also SHA and AES acceleration ... don't work in Linux. The choice of mainboard doesn't matter, the same goes for desktop Ryzen 3000/5000

Strange that I've been using it since forever. Either you are spreading bullshit or the cases where it doesn't work are much more specific than you claim here.

[r1348]

The "old" CCPs, and thus also SHA and AES acceleration, RAM encryption and SEV don't work in Linux. The choice of mainboard doesn't matter, the same goes for desktop Ryzen 3000/5000 - the driver can't even initialize the CCP device (PSP does activate though). This indicates a firmware issue.

On Windows, the device can be initialized and the AMD provided driver loads successfully. If that isn't a dummy driver to make device manager shut up about an unknown device, then this indicates an issue with the Linux driver.

My 2700U PRO laptop running Fedora 38 would beg to differ:

$ dmesg | grep ccp
[    1.990227] ccp 0000:04:00.2: enabling device (0000 -> 0002)
[    1.996245] ccp 0000:04:00.2: ccp enabled
[    2.007924] ccp 0000:04:00.2: tee enabled
[    2.007931] ccp 0000:04:00.2: psp enabled
​

[kiffmet]

r1348 because you are using a 2000 series chip. I explicitly wrote that this affects 2nd and 3rd gen desktop CPUs.

Anux what's your CPU, MB and UEFI version?

Here, this is the result that most people are getting - including me. I tried resolving this with GB's support ages ago, when they still had that competent guy in their firmware dept. and they weren't able to do anything, besides letting AMD know, since it's seemingly caused within the AGESA blackbox…

[Anux]

Not sure why you are asking about my mainboard if

The choice of mainboard doesn't matter

Some Asrock B350 first with 2400G now with 5700G, BIOS is from late last year. Exact names and versions later ...

The only thing I was spotting in this thread are mostly 5.X kernel versions, im runnning arch wich is somewhere around 6.3.

I'm not quiet the friend of generalizations if you come from a thread with < 100 users (that's not most) and extrapolate that problem to everything. It doesn't help your credibility nor your chance to solve the problem.

[kiffmet]

It doesn't work with recent kernel versions either. I try from time to time myself with a 3900X and a 5900X to see if something has changed. As for you not having issues, that actually makes perfect sense: 2400G is 2000 series, which do seem to work in general, and 5700G doesn't have an I/O die, which distinguishes it from the Ryzen 3000 and 5000 parts that are reported to not work (all of the affected ones I know of, are exclusively chiplet based). G series also gets different firmware and everything.

That reddit thread is by far not the only place where the issue is being talked about, just the first one I could find again quickly. I also have no hopes in this to ever get resolved, as the problem has been there since the launch of Zen2 throughout all of AM4's lifetime.

[brent]

Yeah, memory encryption works basically since forever for me with some older AsRock board. I do not doubt there are issues with specific configurations or specific motherboards, but I really don't see widespread problems.

[kiffmet]

brent and which CPU(s) are you using? Like that's my whole point. Server parts are fine, Ryzen 1000 and 2000 seem fine, G series chips seem fine, probably also most mobile U-series, but I've yet to see a single "Matisse" (3100, 3300X, 3500X, 3600, 3600X, 3600XT, 3700X, 3800X, 3800XT, 3900, 3900X, 3900XT, 3950X) or "Vermeer" (5600, 5600X, 5700X, 5800, 5800X, 5800X3D, 5900, 5900X, 5950X) part have a working CCP in Linux, to word is as precise and unequivocally as possible.

[Anux]

As for you not having issues, that actually makes perfect sense: 2400G is 2000 series, which do seem to work in general, and 5700G doesn't have an I/O die, which distinguishes it from the Ryzen 3000 and 5000 parts that are reported to not work (all of the affected ones I know of, are exclusively chiplet based). G series also gets different firmware and everything.

The first post in your link has the error with a 4750U, which is the predecessor of the 5700G (the G APUs are just notebook APUs that were not power efficient enough for mobile use). So it seems to be more of a motherboard/firmware problem of some specific borads or manufacturers.

Also I have millions of config tables in the bios where I could dis/enable virtually any feature including SME, SVM, etc. Maybe you have to dig deeper in your bios or you don't have that checkbox and it's disabled by standard.