Will AMD's 'openSIL' Library Enable Open-Source Silicon Initialization With Coreboot? (phoronix.com) 29
Formerly known as LinuxBIOS, coreboot is defined by Wikipedia as "a software project aimed at replacing proprietary firmware (BIOS or UEFI) found in most computers with a lightweight firmware."
Phoronix is wondering if there's about to be a big announcement from AMD: AMD dropped a juicy tid-bit of information to be announced next month with "openSIL" [an open-source AMD x86 silicon initialization library], complete with AMD Coreboot support....
While about a decade ago AMD was big into Coreboot and at the time committed to it for future hardware platforms (2011: AMD To Support Coreboot On All Future CPUs) [and] open-source AGESA at the time did a lot of enabling around it, that work had died off. In more recent years, AMD's Coreboot contributions have largely been limited to select consumer APU/SoC platforms for Google Chromebook use. But issues around closing up the AGESA as well as concerns with the AMD Platform Security Processor (PSP) have diminished open-source firmware hopes in recent years....
For the Open Compute Project Regional Summit in Prague, there is a new entry added with a title of OSF on AMD — Enabled by openSIL (yes, folks, OSF as in "Open-Source Firmware").... [H]opefully this will prove to be a monumental shift for open-source firmware in the HPC server space.
From the talk's description: openSIL (AMD open-source x86 Silicon Initialization Library) offers the versatility, scalability, and light weight interface to allow for ease of integration with open-source and/or proprietary host boot solutions such as coreboot, UEFI and others and adds major flexibility to the overall platform design.
In other words, this library-based solution simply allows a platform integrator to scale from feature rich solutions such as UEFI to slim, lightweight, and secure solutions such as coreboot.
The description promises the talk will include demonstrations "highlighting system bring-up using openSIL integrated with coreboot and UEFI Host Firmware stacks on AMD's Genoa based platforms."
Phoronix is wondering if there's about to be a big announcement from AMD: AMD dropped a juicy tid-bit of information to be announced next month with "openSIL" [an open-source AMD x86 silicon initialization library], complete with AMD Coreboot support....
While about a decade ago AMD was big into Coreboot and at the time committed to it for future hardware platforms (2011: AMD To Support Coreboot On All Future CPUs) [and] open-source AGESA at the time did a lot of enabling around it, that work had died off. In more recent years, AMD's Coreboot contributions have largely been limited to select consumer APU/SoC platforms for Google Chromebook use. But issues around closing up the AGESA as well as concerns with the AMD Platform Security Processor (PSP) have diminished open-source firmware hopes in recent years....
For the Open Compute Project Regional Summit in Prague, there is a new entry added with a title of OSF on AMD — Enabled by openSIL (yes, folks, OSF as in "Open-Source Firmware").... [H]opefully this will prove to be a monumental shift for open-source firmware in the HPC server space.
From the talk's description: openSIL (AMD open-source x86 Silicon Initialization Library) offers the versatility, scalability, and light weight interface to allow for ease of integration with open-source and/or proprietary host boot solutions such as coreboot, UEFI and others and adds major flexibility to the overall platform design.
In other words, this library-based solution simply allows a platform integrator to scale from feature rich solutions such as UEFI to slim, lightweight, and secure solutions such as coreboot.
The description promises the talk will include demonstrations "highlighting system bring-up using openSIL integrated with coreboot and UEFI Host Firmware stacks on AMD's Genoa based platforms."
will microcode updates be opensource (Score:1)
will microcode updates be opensource
In 1960 Microcode was fairly open source (Score:3)
Re: In 1960 Microcode was fairly open source (Score:2)
. It is my sincere hope that the Apple M* processors keep on getting better...
Because nothing says "freedom" like a closed ecosystem.
Re: (Score:1)
I doubt RISC V will ever be competitive in the performance market segment. It requires a huge investment and many years of work to produce a chip that is as fast as modern x86 parts from AMD and Intel, and anyone with the resources to do it is unlikely to give it away for free.
Speculative execution is necessary for high performance, and can be done completely securely with proper design. Another option is disabling it for critical parts of the code, leaving it on for stuff which is unlikely to be affected b
Re: (Score:2)
What was it's name again? Elbow or foot or something?
Re: (Score:1)
ARM had a lot of commercial investment, but it's still not all that close to x86 single core performance. It also needs some pretty severe compromises to reach even that level, like very tightly coupled RAM. AMD is going to have on-die RAM next generation, although only as a sort of cache rather than as the entirety of the computer's memory.
The issue is that RISC is fundamentally less efficient in terms of code density, so you need much bigger on-die caches and more memory bandwidth. If you look at the desi
Re: (Score:2)
Re: (Score:2)
why ? (Score:2)
The Unified Extensible Firmware Interface Specification (UEFI) has become the default for booting on AArch64 and x86 systems. It provides a stable API for
the interaction of drivers and applications with the firmware. The API comprises access to block storage, network, and console to name a few. The Linux kernel
and boot loaders like GRUB or the FreeBSD loader can be executed.
https://www.arm.com/architecture/system-architectures/systemready-certification-program/sr
Re: (Score:3)
Because Google demands Coreboot for Chromebook SoCs .
Re:why ? (Score:4, Informative)
Re: (Score:3, Interesting)
In the older days of BIOS, system calls such as disk reads consisted of loading some specific registers with some specific values, then executing a specific interrupt. The interrupt handler would change the CPU to SMM (system management) mode, perform the read, populate more specific registers, then exit SMM and the interrupt handler.
All that except without switching back and forth to SMM aka "ring -2". BIOS existed before wintendo even had rings, that's a feature added in the 386. SMM got added in the 386SL (adding quite a few more transistors than were needed for just running programs). It'll switch to that on its own accord for reasons it deems good. At the start mostly for power management and such.
Modern operating systems (ie anything more advanced than MS-DOS), when booting through BIOS, pretty much only use BIOS for bootloading.
Re: (Score:2)
It's actually worse than that. There's also the iME/PSP, that has started to actively block third party (ie coreboot) BIOS/UEFI replacements "for security reasons".
You can replace anything illegitimate with something legitimate and then add a few quotes to make it sound like a conspiracy. There's nothing of the sort though. Allowing arbitrary 3rd party code execution in a part of the boot process that allows you to create firmware level residency is a major security risk and this has been exploited several times.
The right answer is getting Coreboot signed/approved. Not delegitimising an actual security improvement. Same with SecureBoot. It is objectively a good thing
Re: (Score:3)
Allowing arbitrary 3rd party code execution in a part of the boot process that allows you to create firmware level residency is a major security risk and this has been exploited several times.
That's because the idiots in charge allowed the BASIC input output system to be automagicly in-circuit updatable post boot in the first place. Had they required moving a physical hardware jumper (like the systems before it), or required that the update could only be given in the pre-boot environment via external media (and only after the user explicitly told the system to update), most of those exploits would have never happened. Instead, a bunch of corporate users wanted all of these fancy OS-level featur
Re: (Score:3)
Essentially that's right. It's one of the things that Secure Boot protects against, by requiring the firmware to be signed, and the OS loader to be signed, so that malware can't insert itself before the OS reaches a point where it can defend against such attacks.
Re: (Score:2)
This [theregister.com] UEFI?
Re: (Score:2)
UEFI booting is stupid and slow. It offers only a fraction of the functionality of coreboot, since coreboot is based on a Linux kernel. The only thing it used to offer was additional security, before Google produced verified boot [coreboot.org].
The only downside to coreboot is getting it running without vendor support. Well, this is vendor support. Hopefully this time they actually mean it, unlike last time, where it was just a lie.
Don't get your hopes up (Score:2, Insightful)
They've promised openess and coreboot before, then reneged. Instead they followed intel, added "security processors" and other crap that made the hardware entirely untrustable for the owner and/or end-user. They're not there for you. They dance to microsoft's tune.
Once burned, twice shy.
Blame Hollywood (Score:2)
Every major streaming platform relies heavily on AMD PSP and related components (and matching Intel tech like ME) for their DRM and if manufacturers stopped including all that stuff in their hardware, streaming platforms would refuse to play DRM content on said hardware.
Re: (Score:3)
Every major streaming platform relies heavily on AMD PSP and related components
No they don't. The PSP and ME are not available to any software. You may be thinking about "Intel Insider" which was a DRM solution provided in 2011 for streaming platforms. But no equivalent was ever adopted by AMD and as such no streaming service currently has any requirement for any hardware security device on a PC.
The closest any CPU came to providing any mechanism for DRM is by integrating an fTPM into the CPU, but that is nothing more than a trusted key store, it doesn't create any DRM and since it's
Re: (Score:1)
And this shows yet again how out-of-touch AMD is. Coreboot is a dead project and has been for years. Progress was always slow and unreliable.
We DO need something like Coreboot but Coreboot isn't it.
On top of this, AMD doesn't even have a wholly integrated chipset solution that can use Coreboot anyway (unlike Intel). I mean this is part of the reason why AMD stuff is so buggy. They haven't made anything good since the 90's when everyone was using the same chipsets and all they had to do was make a copycat CP
Re: (Score:2)
this is part of the reason why AMD stuff is so buggy. They haven't made anything good since the 90's when everyone was using the same chipsets and all they had to do was make a copycat CPU.
Sure, except that's completely wrong. The 90s was when AMD stopped making copycat CPUs like the Am386 and Am486. The K5 was an internally-RISC design, so was the K6 more or less, after that they weren't any more. The K5 was great at being a 486, and held its own OK against a Pentium. The K6 was pretty terrible at being a Pentium 2, compatibility was weak. But if you actually had code compiled for it (which was phenomenally rare, unless you ran gentoo, which didn't exist until 2002) then all variants were fa
Re: (Score:1)
> when swhe changed gender,
I would say that was a symptom, not a precursor
Oxide (Score:2)
phones too? (Score:2)
Betteridge's Law? (Score:1)
Nobody citing Betteridge's Law of Headlines?