this post was submitted on 14 Jun 2023
206 points (100.0% liked)
Technology
37747 readers
203 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
When you power on a computer, before any software (any operating system) has a chance to run, there's "firmware" (kind of similar to software, except stored directly in the motherboard) that has to get things going (called "Platform Initialization"). Generally the two jobs of the Platform Initialization firmware: (1) to detect (and maybe initialize) some hardware; and (2) to find the operating system and boot the operating system.
We have a standard interface for #2, which is called UEFI. But for #1, it's always been sort of a mysterious black box. It necessarily has to be different for every chipset/every motherboard. Manufacturers never really saw much reason to open source it. The major community-driven open source project at doing #1 is called "coreboot". Due to the fact that it requires a new implementation for every chipset/motherboard and they are generally not documented (and may require some reverse-engineering of the hardware), coreboot has very very limited support.
So what AMD is open sourcing here is a collection of 3 C libraries which they will be using in all of their firmware, going forward. These libraries are not chipset/motherboard-specific (you still need custom code for each motherboard) and do not implement UEFI (you would still need to implement UEFI/bootloader on top of it), but they're helper functions that do a lot of what's needed to implement firmware. I just took a cursory look through the source code, but I saw a lot of code in there for detecting RAM DIMMs (how much RAM, what kind of RAM, etc.), which is useful code.
The fact that AMD is going to use this in their own firmware, and also make it available for coreboot under an MIT licence, means that coreboot may* have a much easier time in the future supporting AMD motherboards.
* we will see
But wouldn't opening up such an important (from what I understand) part of a computer to everyone mean that malicious actors have a much easier time doing malicious stuff? I understand (and support) that enthusiasts will have many more options when presented with the actual code to a program. Nonetheless, I can't help but feel like if you give everyone a tour and show them how their super secure door locks work, including how to break them open, then those that want to break in, will be very happy about it and the security system quickly becomes useless.
Please feel free to correct me on wherever I am wrong. I tried reading through the article, but I only understand a fraction of it.