Comment by moppl | Hacker News Reader

Comment by moppl | Hacker News Reader

This is a futile discussion. It would not make any difference if AMD released the PSP source code. The problem with the PSP is not it's firmware, it is a much deeper fundamental architectural problem as outlined in (unfortunately dead link) https://www.reddit.com/r/linux/comments/5x5xl3/amd_to_consid...

If AMD would release the source code, the PSP would still remain a black box controlled by the manufacturer. It is an autonomous universal computer (with it's own CPU, RAM, ROM, clock...) which can load/run anytime any software AMD wants it to. There is no way for the user to tell what software it is running at the moment and what it is doing on the platform. It has fully privileged access to the users resources while it offers no interface for the user (only a very minimal low level interface).

So the fundamental problem is, that it takes the control of the platform away from the user, the manufacturer is ultimately in control on the platform. This is what goes against the philosophy of Coreboot/Libreboot (of being completely in control of the platform), not simply the encrypted PSP firmware blob.

Knowing that blob would not compromise the PSP and would not give the control back to the user.

Unfortunately the link you just provided just died.

If you're on Linux, your best bet is likely to be attaching to each renderer process and running `generate-core-file`. Unfortunately (and very annoyingly) chrome://cache stores HTTPS-encrypted data, which you would need to have previously exported SSLKEYLOGFILE to decrypt.

Alternatively, if you still have the tab open, CTRL+S :D

Regarding your point though, if the PSP is _completely laid open_ so we can understand how it works, can't we load our own firmware into the PSP and then be confident that that's what's running?

Oh, sorry for the dead link. So I repost it here:

"Hello!? Releasing the source code would NOT change the fundamental problem with the PSP! It will still remain a black box under the control of the manufacturer! The problem is not the obfuscation of the source code, it is a much deeper platform architecture issue.

The PSP is a universal computer with it's own CPU, RAM, ROM, clock etc, that can run whatever software AMD wants it to run, hidden from the user. It could load software anytime without you even noticing. AMD controls the PSP by using unique cryptographic keys which are burnt into each PSP.

As the Intel IME engineer Xiaoyu Ruan wrote in his book "Platform Embedded Security Technology Revealed", the security architecture of the IME does not rely on security through obscurity, it relies much more on the burnt in cryptographic keys and it's architecture. The designers of the IME took into account that the firmware might be unscrambled and realeased by somebody, so they designed it in a way that this would not compromise it.

Even if you have it's source code (it's OS so to speak), there is no way for the user to tell what software it has loaded into memory and what it is doing at the moment (since it is a universal computer in its own right which offers no interface to the user). It is a parallel world on the platform the user has no access to (while the PSP has fully privileged access to all the users resources).

So the only real way to support Coreboot/Libreboot would be to remove the PSP completely (which is probably not possible, since it became an integral part of the system) or to offer the option to disable it and/or feed it with one's own cryptographic keys.

IMHO it stays an uncontrollable risk as long as there is an PSP on the platform (likewise the IME on Intel platforms). The source code doesn't make a difference. The only advantage of releasing the source would be, that it could be checked for potential security risks to avoid hostile takeovers of the PSP (which would be a true disaster).

So don't be naive, don't believe this hype."

To further answer your question (as far as I am able to do that), if the PSP is _completely laid open, it would not change its fundamental design, and it would not allow you to put your own firmware. It would be necessary to know its burnt in and unique cryptographic keys, to be able to load your own firmware/software. I would say those cryptographic keys are the crown jewels of the PSP (or IME), which allow you to take control of the PSP. And those are (hopefully) only known to the manufacturer and will not be released with the source code ;)

The problem is cast in silicon so to speak.

Thanks for the paste! I'm curious what user it was from (anything you put on the Internet, stays on the Internet...).

And thanks for the explanation about the crypto keys in the PSP. That makes perfect sense, and it's really sad that this is a case of a security architecture that is literally founded upon obscurity (ie, keeping the keys secret).

So the only real solution here would be for AMD to release a PSP firmware that essentially did nothing. I can only hope the people that AMD talk to will explain that this is the sort of approach that would be needed. Being able to disable enterprise security solutions for my non-enterprise desktop and know they are off would be awesome - and that's all I'd need.

As an aside, I commented in this thread - https://news.ycombinator.com/item?id=13782508 - regarding the potential existence of ME keys in the wild. Really reassuring...

> a case of a security architecture that is literally founded upon obscurity (ie, keeping the keys secret)

Huh? Relying on the secrecy of keys rather than secrecy of the code is the _exact opposite_ of security through obscurity.

I can see their point. One can view obscurity as "not common knowledge" or "information that can be found if you look hard enough."

A secret key technically falls in the later. You have it somewhere. If someone looks hard enough, they can find it. It may take ridiculous effort to the point of being impractical, but that is still obscurity.

I recognize that when people speak of "security through obscurity" they are referring to esoteric knowledge that is difficult but not impractical to find.

Ruan writes in his book in chapter 4 "The Engine: Safeguarding Itself before Safeguarding Others":

"In addition, there is a basic guideline for realizing security: Never rely on security through obscurity. When designing security hardening features for the engine, it is always assumed that all firmware source code and internal architecture documentation may be obtained by attackers. The engine’s security design principle is to harden the product by applying proven cryptography and security primitives, rather than rely on hiding secrets in the code or documents."

So they cast their secrets in silicon I guess, which would be incomparably harder to recover.

That reddit post was mine. I just created a new account there, but somehow my comment doesn't show up, no idea why. But fortunately there is HN :)

I would not call it an enterprise security solution. It is also very much aimed at the ordinary user's machine. It is important for DRM (the infamous TPM chip is now basically an app running inside the IME/PSP). Decryption of DRM content takes place inside the IME and it is presented using a protected media path. So the content industry wants to have that on your computer. Intel also tries to market it by offering security solutions like 'Intel Anti Theft Technology' or its 'True Key' App which utilizes the IME. It makes your machine uniquely identifiable and it should serve as a store for all your secrets (like biometrics, passwords etc). Intel is also opening the IME up for third parties to create software for it. So your bank might e.g. run it's software inside the (considered safe and secure) IME. But of course such software has to be signed by Intel before.

Ruan even hints in his book at the possibility that one day the IME might become just as powerful as the user system. So it would be possible to run e.g. a game completely inside the IME, absolutely safe from the malicious user who might try to copy it. All you get is the output on the screen and the speakers. So the (considered unsafe) ordinary user space would just remain for running and storing trivial tasks and information. Everything else runs hidden away from you.

And all of this is supposedly for your own good and security. I would call it a dual use technology which (dis)owns the user.

> I just created a new account there, but somehow my comment doesn't show up, no idea why.

Probably just got detected as spam by Automod and removed. If you message the mods for /r/linux they'll probably approve it for you.

But then I don't get why they wouldn't market two different CPU's, one backdoored and user-controlling one and a normal maliciousness-free one. It's then up to the game developers to require a system of the former type to play their game. Then gamers get these and people who mind their privacy and security in computing get the latter. Win-win, right?

I mean, people will anyways get computers that obey them. Either an ARM-based or something completely different.

There are (at least) two different markets here. People who just want to enjoy products and media (which might be DRM'ed but they don't care) and people who want a computer they can trust. Why should AMD or Intel restrict themselves to the former market?

Platform Embedded Security Technology Revealed gets mentioned a lot around IME PSP discussions and it's actually available as a (legitimately) free epub and pdf: https://link.springer.com/book/10.1007/978-1-4302-6572-6

The problems with AMD PSP and other things are well known to the coreboot/libreboot teams: https://libreboot.org/faq/#amd

As noted, AMD used to work with coreboot but for some reason or another stopped.

If this effort means a return to working with the coreboot project then I think this is a good thing.

That said, I think you are correct to be highly skeptical that anything great can come of it since the architectural goals of the PSP are at odds with the goals of coreboot.

Unless AMD allows coreboot/libreboot to control the PSP then any coreboot/libreboot support would be superficial. But again, the coreboot/libreboot teams are well aware of this...so I would be confident they walk into any AMD collaboration with eyes wide open.

Well yeah, but the choice shifts from "closed-source firmware and completely closed PSP", which is what you get with Intel with no choice in the matter, to "open-source firmware and completely closed PSP", which is a clear improvement. Vendor UEFI implementations have been flaky in the past for me, so I'm looking at it from the point of view of better stability, user-friendlyness and customisation options.

Reply on news.ycombinator.com