Me too. I don't need more performance right now so I have no plan to buy a new system, but if AMD received coreboot support without blobs, I would buy new hardware right away.
The actual percent of users who use it may be small, but they're the most vocal and activist group who recommend products to the majority of ignorant people.
Coreboot is a good thing, and if AMD could implement it, they should do so.
I think there is also a huge benifit for OEMs: it would reduce the cost of developping a Ryzen system. If you're Asus and you want to make a Ryzen motherboard, you have to write or license a BIOS. If Ryzen supports coreboot, this is something you no longer have to do and the system is much closer to working out of the box.
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.
> I think there is also a huge benifit for OEMs: it would reduce the cost of developping a Ryzen system.
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.
> It can make it more difficult to "stand out" from competition by offering a firmware (UEFI, BIOS) that has vendor-specific "advantages"
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 actual percent of users who use it may be small, but they're the most vocal and activist group who recommend products to the majority of ignorant people.
"
Citation needed?
GNU proponents are heavily evangelical. But, if you look at what software and hardware gets used, they don't seem to be very influential. People seem to ask their Windows-using friends and relatives for recommendations, not their closest GNU evangelist.
Yes. The real trick is this dozen is usually very influential and should be counted as a force multiplier. This is how Macs became THE multimedia machines 15 years ago(final cut pro).
They could aggressively go after certain corporate/government clients (and obviously also consumers but I'd guess not many really care...sadly) with a "no Management Engine, no secrets, no back doors, just secure" pitch. Not saying it's the right play but there's a strategy.
Don't forget that some companies might wish to run core boot in their stack, to for example allow remote debugging of many servers. (Without costly third party hard/firmware.)
"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.
Still sounds like a standard customer service response to me, just from a good CSR. "Please feel like you have been heard"? I think that captures it.
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.
The slam-dunk would be if a factory-new processor's purchaser has the option to have the built in TrustZone ARM management chip able to trust keys provided by the owner (blow a fuse or something?), so unlike Intel IME, someone who wants to avoid their computer's Ring -3 being owned by organized crime can take steps more reasonable than http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_f...
Currently most modern hardware we own contains a backdoor at the BIOS level. It's a black-box blob of code that does all the initialization and can potentially call home (Intel/AMD) and do almost everything on your system. Another thing is that we can't debug and fix BIOS-related problems (like software suspend). More here https://libreboot.org/faq/#intelme
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.
A couple of years ago both Intel and AMD started developing their own solutions that allows them to offload some the functionality that used to happen on the main processor to another co-processor placed inside the chipset on the motherboard, functionalities like power management, secure booting, USB handling..etc
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.
This is a feature designed for enterprises. Imagine you had tens of thousands of machines in your company. A secondary processor that's hardened against virtually all attacks running an independent operating system allows you to manage and audit those machines even if those machines have been compromised maliciously or just messed up accidentally.
If that were the use-case then nothing speaks against giving full control to private customers over their chips or not including these features into chips for private customers, while neither of both is done.
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.
> If that were the use-case then nothing speaks against giving full control to private customers over their chips or not including these features into chips for private customers, while neither of both is done.
This is (as far as I know) only one use-case. Another one (that makes Hollywood drool) is implementing DRM.
At some point (maybe already), the malware will catch up and infect these secondary OS/processors, leading to machines that are securely and permanently infected!
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?
BIOS blobs aren't the problem, coreboot actually replaces them.
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.
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?
"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 ;)
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.
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.
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?
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.
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.
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.)
Uh... what they said was: "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."
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.
While corporatese is not one of my key strengths, I think they've commited now to something that can't be dealt with with a simple "No, you won't get source code."
I'm dumb and don't really understand why this is beneficial. I also don't have a lot of in-depth knowledge about CPUs, would someone mind explaining what the problem is and how AMD doing this solves it?
There is a secret OS running inside the CPU that you don't have access to.
Only Intel/AMD know whats really inside and it has access to everything in your system.
Usually it even interjects itself into the LAN controller listening and sending network traffic.
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.
64 comments
[ 6.6 ms ] story [ 729 ms ] threadCoreboot 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.
"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.
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.
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 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.
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
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.
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.
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...
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.
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.
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.
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?
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.
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)
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.
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.