AMD to consider coreboot/Libreboot support for Ryzen
reddit.com
reddit.com
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.
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?
"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.
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.
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...
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 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?
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.
Huh? Relying on the secrecy of keys rather than secrecy of the code is the _exact opposite_ of security through obscurity.
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.
"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.
"Thanks for the inquiry. Currently we do not have plans to release source code but you make a good argument for reasons to do so. We will evaluate and find a way to work with security vendors and the community to everyone's benefit."
To consider this 'consideration' seems rather.... hopeful.
> I will bring this to the attention of the product team for serious consideration, so please feel like you have been heard even if we were not able to give you an easy 'yes' right away.
Which is not a commitment of course, but goes the extra mile to make it clear that it's not your standard PR reply either.
Let's hope!
I'd love it if this happened, it would make me change my purchasing habits to prefer AMD over Intel. But I'll believe it when I see it, and I can't say this post on their forums changes my assessment of the probabilities at all.
Not a rhetorical question - I'm genuinely curious. What's the point of keeping BIOS blobs in secrecy? If it's some secret sauce know-hows - what sort of information could be possibly revealed, that a skilled competitor-hired reverse engineer can't obtain? I understand that it's hard to talk about actual secrets, but are there any similar-enough examples from the past?
I know many hardware companies are highly secretive-by-default, but is that a real thing, this secrecy protects, or just some business superstitions?
The problem is early initialization firmware on the CPU/chipset/etc. And the fact that parts of initialization are moved into Management Engine / Platform Security Processor which are tiny processors running a third party proprietary OS (Trustonic TEE OS in the case of AMD).
Of course there's no real thing to protect, these companies just don't give a fuck.
I have visions of the Windows 95 3D screensaver, with the walls, floor and ceiling displaying the many, many NDAs you need to sign to get access to this.
(I must admit that what initially came to mind was ~2:25 in http://youtu.be/EUXnJraKM3k (2:55).)
In all seriousness, this may be the tricky bit. AMD may need to release the PSP spec and get Libreboot to take it from there.
Considering the huge amount of support for this though, I can totally see a crowdfunded firmware implementation for the PSP working out.
Coreboot is a good thing, and if AMD could implement it, they should do so.
The downside for OEMs is that a lot of them use the BIOS as a way to differentiate themselves with extra features. I think there is going to be some initial resistance because of this but it shouldn't be too major.
There is also a huge potential disbenefit for OEMs: It can make it more difficult to "stand out" from competition by offering a firmware (UEFI, BIOS) that has vendor-specific "advantages": OEMs do of course like implementing such mainboard-vendor-specific modifications; I also heard there seem to be in particular gamers who love such implementations that offer more "graphical bling" in the UEFI firmware.
Since when open firmware becomes a desired property of mainboards, OEM will have to be better in terms of concrete features of the hardware instead of graphical tricks to stand out from competition (which is hard work), I can also imagine quite well that OEMs are cautious about such open firmware desires.
Not really. Look at what Samsung does to Android. Let the upstream maintainers do 99.7% of the real work, then change five random things for no reason other than to be able to claim your competitors don't have that.
The bastards are worse than Mormons.
;_) No, i need a citation that anyone actually cares what they say.
That's as clear a corporate "no" as you're going to find, folks. There's no story here. There will be no PSP source release.
Would like to drop this tidbit I found recently. The following is completely unverifiable and not going to convince some people but I found it interesting.
From the AMA linked in the link:
> 1) Security Through Obscurity doesn't work. As mention by /u/Gusec At some point in time, (somebody or some organization) will break this.
When I read that I remembered this:
https://www.reddit.com/r/onions/comments/5i6qa3/can_the_nsaf...
Mirror: http://archive.is/T8yVz
My focus is on the first paragraph in the wall of text, the bit about the signing keys floating around out there.
This is, again, totally unverifiable, and could for all I know be a skiddie strutting (it does read a bit like that). I thought it was an interesting bit of insight though, for what it's worth; and maybe some people could use it as a lead.
Regarding the views offered in that post, I am myself quite wary, simply because I don't know this person's providence and I have no idea if this is whatever you call the opposite of a scare campaign. (If it is it's a bit weird, so it probably isn't.)
(I will note that it looks like the person in question doesn't seem to want to be contactable, so poking them is unlikely to be helpful. I also wonder why they used a new Reddit account for each post.)
I found it when reading https://www.crowdsupply.com/raptor-computing-systems/talos-s... (mirror: http://archive.is/znkp3)
The problem is not only that this co-processor is running it's own operating system with full unrestricted access to the systems main memory and network interface, but also that the main processor can't actually tell what the co-processor is doing with this data or when does it access it, on top of that both Intel and AMD delivers you the software running on the co-processor as a binary blob so we can't really be sure if it's secure, has backdoors, spying on you, etc..
LibreBoot/Coreboot are projects to write an open-source BIOS for x86 hardware, and since a big part of the BIOS is running on this co-processor you only have a choice of either using the binary blob provided by Intel/AMD or lose the functionality provided.
The Intel Management Engine will make a lot of tinfoil hats tingle: http://hackaday.com/2016/11/28/neutralizing-intels-managemen...
Libre-boot and coreboot promote a kind of transparency where you know what your system is booting and why.
It's much better than having this proprietary walled garden with astounding amounts of power/control inaccessible to anyone but Intel in your machine.
Intel would of course argue that this is necessary for good crypto and it's for the users, not against them. Which may hold true a little bit....until it's compromised by someone.
Hardened? Have you tested it? This feature relies on obscurity for it's "security".
> all attacks
Also, stating that anything could be secure against "all" attacks is the kind of hubris that encourages complacency.
> independent operating system
That OS is monoculture[1], greatly increasing the utility of an exploit.
> even if those machines have been compromised
Only if you assume the builtin OS is magically secure. Intel/AMD have had many bugs in their products in the past.
[1] really a small set of monocultures
The first would probably require replacing lots of purchased code with code that can be disclosed, and doing a full security audit of the remaining code.
The second would require separate SKU's and validation for consumer vs business use.
The first would benefit enterprises too by replacing the current "security by obscurity" scheme with auditable security, so that's where we should probably focus our lobbying.
Providing hardware documentation and a way to flash the firmware is enough. This shouldn't put AMD in front of significant problems.
This is (as far as I know) only one use-case. Another one (that makes Hollywood drool) is implementing DRM.
This is all for some definition of security, but since you the user do not have access to, or control over it is most certainly not for your security.