Hacker News Reader

Comment by snvzz | Hacker News Reader

It looks like a tool to analyze the psp firmware, which is a necessary step in this process.

Necessary only because AMD isn't being cooperative, that is. It'd be as easy as providing a shim so that the machine can boot without enabling the psp.

View on HN

PSPTool author here. Since all PSP firmware must be signed by AMD, something like a psp_cleaner would be possible given that a bug in the firmware allows to inject arbitrary code. This was shown by CTS-Labs earlier. [1]

[1] https://msrnd-cdn-stor.azureedge.net/bluehat/bluehatil/2019/...

thanks for posting the link. looking forward to the day when we can run post-2012 cpus knowing we'll be able to lock the backdoor.

Wow, only the header is signed (for the Ryzenfall-1 bug)? That is a pretty big oversight, did AMD attempt to patch these bugs?

If there is anything these secret proprietary built in hardware backdoors are its that they are very poorly thought out.

It does seem to be a pattern. I can think of a few reasons off the top of my head:

1. Incompetence - The engineers try to get it right, but fail due to skill, budget or time constraints.

2. Malice - This allows bad actors to compromise the PSP for evil

3. Benevolence - This allows hardware owners to alter the PSP for their own protection.

I think the smart money is on #1, but they're all interesting to think about.

ARM is the designer of the PSP, if its incompetence then they're the ones at fault.

AMD states that the PSP is "ARM TrustZone ... Industry standard" https://www.amd.com/en/technologies/security

That's supposed for data-only modules, so they can patch in live data later, without the need to fetch it from some flash or bios. I think no-one should call code from it.

Would this be something you would be interested in implementing? I still use Intel stuff only because no psp_cleaner exists yet.

I think the coreboot guys would also be interested in something like this, too.

The PSP is licensed from ARM, meaning AMD owns none of the IP of the PSP. If they were to cooperate in this effort, ARM would likely sue them for breaking their licensing agreement.

Same reason the recently mainlined Mali drivers (another ARM IP block) got no assistance in development from any of the chip vendors. Touching those projects would break their licensing agreements with ARM and risk having to stop producing their chips that integrate Mali (aka most ARM based chips).

That all makes sense for the vendors.. but what does ARM get out of it? A false sense of security?

The good feeling of cooperating with the agencies.

thats the billion dollar question! not having the clear answer even in public traded companies is a travesty.

An excuse for AMD to switch to a secure enclave based on RISC-V.

I wish..

This doesn't sound right. The PSP is an ARM core, but the firmware running on it is likely mostly written by AMD. Also, license agreements can be negotiated.

Major parts of the firmware were licensed, I assume for time-to-market reasons. Some of the license issues are also AFAIK due to how, somehow, we let entertainment industry strangle hold us - both ME and PSP now have code involved in setting up "protected av path" which is queried by streaming services et al - and if it's not found, you don't get to play 4k media (at least, afaik, with Netflix, it's 4k).

AMD could release a friendlier version but it would not be able to do what majoroty of the market expects it to do.

n.b. there are license-built cpus that have alternative firmware in PSP, but it's also closed and they are not really available on open market.

AMD doesn't have the code nor the documentation from ARM to release a minimal PSP, and any attempt by them to do so will end with an injunction against AMD selling processors with TrustZone embedded, meaning they will have a yearlong gap before they can retool and start shipping any PSP-less processors (lead times on silicon changes are loooong).

Had AMD not been broke prior to the launch of Zen, they would have likely built their PSP in house, but they were so desperate to stay alive that they sold the 1st gen Zen CPU designs to a Chinese joint venture for $200 million (which kept AMD from bankruptcy).

AMD states that the PSP is "ARM TrustZone ... An Industry Standard Approach" right on their website: https://www.amd.com/en/technologies/security

Wrt renegotiating with ARM, there is no leverage for AMD. TrustZone is already baked into their chips for the next 2 to 3 years, and if the negotiations go badly then ARM could block AMD from selling any processors for at least a year.

AMD did hire a security consultant (due to the Change.org petition) that told them TrustZone was vulnerable, but this means they need to implement their own PSP which is something that will take 3 years or more (silicon has a very elongated development cycle).

Had AMD not been on death's doorstep for the years preceding the new Zen architecture, they likely would have built their own PSP. Being financially insolvent and desperate to meet the requirements of their OEM partners forced them to license a pre-built PSP.

This the first time I heard about a change.org petition having any effect.

ARM TrustZone is basically just a hypervisor-like execution level that runs above the actual hypervisor called the "secure world", along with ways of calling into it. There's already open-source implementations of the firmware for the secure world on ARM chips, including one from ARM themselves: https://github.com/ARM-software/arm-trusted-firmware

All of the really super-secret security and DRM critical stuff is in the vendor's hardware and code.

Sounds like a good reason to ditch ARM, and roll out their own solution for it.

In regards to Mali, why can't ARM support open source driver effort? Qualcomm for example are not against Freedreno, to the point that Google wants to make it the primary supported driver now. And Qualcomm are quite nasty in general, when it comes to patents and stuff. So why not the same thing with Mali?

You can find the PSP firmware linked from the https://developer.amd.com/sev/ site.

https://developer.amd.com/wp-content/resources/amd_sev_fam17...

Reply on news.ycombinator.com