Having done a bit of homebrew and other things with my Sony PSP, this post was a little confusing until I hit the readme (Sony PSP uses MIPS instead of AMD). Especially since a tool of this name already exists: https://gbatemp.net/download/psp-tool.7590/
Many tools and programs have started life as a niche hacking tool. For example, XBMC. I also had to pause and wonder if this tied into the PSP somehow.
> Many tools and programs have started life as a niche hacking tool. For example, XBMC
Your little story is relevant.. how?
The rest of the title literally has nothing to do with the Sony PSP... If you open the article, you'll see it has even less to do with the Sony PSP. It's not hard, folks, even for "Hacker" "News".
Not sure, did you stop reading my post after "little confusing"? Because I explained exactly why, and it had everything to do with the "AMD Secure Processor" portion.
Not really useful for me at this stage of development, but I will up-vote any baby-step towards getting less proprietary magic firmware in my Ryzen rig.
I certainly hope this is useful to the firmware-hacking community and helps spur interest for more AMD-oriented libre firmware efforts.
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.
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]
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.
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).
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?
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.
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.
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.
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).
The PSP is responsible for memory training and re-enabling after wake-up. So neutralizing might work (given that signatures can be tricked), but you have to be very careful to keep a sizable set of modules alive.
