[HN Gopher] AMD Details OpenSIL for Advancing Open-Source System...
___________________________________________________________________
AMD Details OpenSIL for Advancing Open-Source System Firmware
Author : YakBizzarro
Score : 77 points
Date : 2023-04-14 14:47 UTC (8 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| oneplane wrote:
| This is great. It's hopefully slightly better on the technical
| side than the FSP that we usually get, while also being less of a
| NDA-encumbered mess that you currently get with any of the big
| hardware and silicon vendors.
| [deleted]
| bradfa wrote:
| I was wondering how Oxide would be able to follow through on
| their claims to be open sourcing even the firmware for their AMD
| systems. This makes it a little more clear.
| wmf wrote:
| Oxide phbl https://github.com/oxidecomputer/phbl doesn't use
| OpenSIL. I assume it's written from scratch based on
| documentation and maybe looking at AGESA. Why can't other
| server/firmware vendors do the same? Because they're just not
| willing to.
| dfox wrote:
| On AMD's amd64 platforms there is not much for the firmware
| to do in terms of the platform bring up as everything that is
| inside the CPU MCM gets initialized to some sane state (by a
| PSP-like additional management core, but AFAIK it is distinct
| hardware from PSP) before the actual CPU cores come out of
| reset. Most of what BIOS/UEFI firmware do on these platforms
| is about providing the right PC-like abstractions to the
| running OS.
|
| If you control the OS and do not have to support backward
| compatibility you can shift lot of that logic into the OS
| itself and you end up with the firmware being essentially an
| ELF loader, which is not a bad description of what PHBL
| actually does.
|
| On the Intels side of things the FSP is somewhat complex
| piece of software that does various low-level poking at the
| hardware in order to make running sane code possible.
|
| There probably is a historical reason for that in that AMD
| started with K8 Opterons which are ccNUMA with packet
| switched interconnect from the inception and relegating
| initial power on configuration of that to the amd64-side
| firmware is not exactly an practical design (at least without
| breaking various assumptions inherent in the "PC" platform).
| Contrast that to Intel who got something like 15 years worth
| of products that used variations of the same Pentium Pro FSB
| (which as an shared bus removes some of the complexity
| involved in the platform initialization).
| mmphosis wrote:
| Does any of this do away with things like AMD Platform Security
| Processor?
| https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...
| [deleted]
| oneplane wrote:
| Probably not, both because the PSP can be part of the SIL
| bringup which you statically link anyway, and because plenty of
| business customers want a Secure Enclave and the legal world is
| having a hard time getting paperwork to suggest it's both
| secure and open at the same time.
| kmeisthax wrote:
| No, and you can't remove the PSP without rearchitecturing the
| processor.
|
| However, they could release a PSP firmware that just loads the
| x86 cores with your chosen BIOS and then halts. Businesses that
| want their systems to have management backdoors[0] can use the
| PSP firmware that implements that functionality, while users
| that care about Free boot chains can use the minimized
| firmware.
|
| [0] Is it a backdoor if the owner put it there deliberately to
| be able to detect regular OS-level viruses?
| gray_charger wrote:
| PSP is a trusted execution environment not a remote
| management platform. There is no reason anyone should want to
| remove this from a privacy perspective. In fact, privacy and
| security software may be hindered without something like PSP
| or SGX.
| justinclift wrote:
| "Trusted by whom" is the problem.
|
| If the end user was in control of the PSP, that'd be great.
| :)
|
| However that's not the case. :(
| kmeisthax wrote:
| So, if I remember correctly AMD PSP started out as a
| response to Intel ME, whose main selling point at the time
| was that businesses could remote into a compromised system
| and wipe malware without the malware being able to fight
| back. PSP also enables a few other things like encrypted
| virtualization - being able to lock AWS's staff out of the
| contents of my VMs' memory. That sort of feature isn't
| really useful to individual consumers.
|
| SGX is an interesting case since Intel actually _axed_ the
| feature a year ago. The only thing it did was enable more
| DRM for 4K Blu-Rays, and Hollywood 's response to that
| feature going away has been to just refuse to let you play
| 4K Blu-Rays on PCs.
|
| I'm not sure what other feature is involved here that would
| make sense in this use case. I mean, yes, PSP also can be
| used to enforce BIOS signing requirements, but the whole
| point of Coreboot is to be able to have a Free-as-in-
| freedom BIOS that you can legally and technically modify.
| If you wanted to do Apple-style secure local signing[0] of
| the modified BIOS, that'd be cool, but as far as I'm aware
| that's not on offer. So the PSP is a security deadweight
| for the kinds of techies that would care about Free BIOS.
|
| Furthermore, there IS a very large customer that has wanted
| to remove these kinds of secure enclaves from their
| systems: the US government, specifically the National
| Security Administration[1]. There's a special configuration
| option in Intel ME to turn off everything but basic system
| bring-up. Why would the NSA want to turn off "privacy and
| security software" on their own machines? Well, again, the
| whole "wipe a compromised system without the malware being
| able to resist" thing implies that this isn't merely a
| security enclave, but a backdoor that could be compromised
| by a third-party. If you aren't specifically using that
| remote management stuff, you want the ME to be as brain-
| dead as possible.
|
| [0] On Apple silicon that is fused for Macs, the bootloader
| allows booting operating systems that are signed with the
| Secure Enclave's local key. There is no unsigned boot;
| instead the Owner account on macOS has to authorize signing
| a new third-party OS in a special recovery mode in order to
| install, say, Linux or whatever.
|
| Oh, and Apple doesn't actually give the Secure Enclave the
| ability to mess with the main application processor. It's
| more akin to a TPM, where it can withhold encryption keys
| from the regular OS but it can't actively snoop on it. So
| they also understand why PSP/ME were bad ideas.
|
| [1] https://www.csoonline.com/article/3220476/researchers-
| say-no...
| the8472 wrote:
| Perhaps if you could replace the trust root with your own.
| But as they are now it's the manufacturer that's in
| control.
| yarg wrote:
| Be better to take control of it, and run it as a chunk of your
| hypervisor.
|
| (This is only possible if there's support for custom signing of
| device control. Cloud environments need to know that the
| security core is under the control of vendor signed firmware.
|
| (This provides cloud service providers with the inability to
| read their customers data and the customers with security.))
| eigenform wrote:
| I don't think so - seems more likely that something like
| OpenSIL would need to talk to the PSP. The difference here
| [hopefully] is that those interfaces are documented.
|
| edit: ie. from the blog post, on the xSIM part:
|
| > "Provides a set of API services that initialize the platform
| host silicon. Most of the silicon initialization on AMD-based
| platforms is performed by embedded uControllers prior to x86
| reset de-assertion."
| gray_charger wrote:
| Why would you want to do away with AMD PSP? It's a trusted
| execution environment that privacy and security software (e.g.
| Signal) makes use of for it's confidentiality and integrity
| guarantees.
| codedokode wrote:
| Because I don't need uncontrolled backdoors in my PC. By the
| way, my laptop has an option to disable PSP in BIOS but I
| don't understand how it works because PSP is still visible on
| the PCI bus as "encryption controller".
|
| > It's a trusted execution environment
|
| It is "trusted" only by manufacturers and cannot be
| controlled by the user. Why cannot it be controlled by the
| user? Probably because it is intented to be used as a
| backdoor or to report users who install pirated software, or
| download unapproved materials etc.
___________________________________________________________________
(page generated 2023-04-14 23:02 UTC)