News AMD Open System Firmware to Replace AGESA On Server, Client CPUs by 2026

[Admin]

AMD details its plans for openSIL at the 2023 OCP Regional Summit in Prague.

AMD Open System Firmware to Replace AGESA On Server, Client CPUs by 2026 : Read more

 

[Alvar "Miles" Udell]

So basically when Socket AM5 and current server sockets are replaced by new ones. Think AMD just inadvertently confirmed Socket AM5's end of life.

 

[Kamen Rider Blade]

I think this is the right direction for AMD to go down.

Open-Source & Transparency FTW!

 

[Deleted member 2731765]

It looks like AMD will use the "Agnostic 3 Static Library" solution written in standard C-17/18 programming language for the silicon, platform & utilities.

 

[RedBear87]

I think this is the right direction for AMD to go down.

Open-Source & Transparency FTW!

Sure, meanwhile the Platform Security Platform remains and will remain a blackbox and its exact functioning is known only to AMD and the US security bureaus, even though this approach doesn't make it inherently more secure.

 

[Kamen Rider Blade]

Sure, meanwhile the Platform Security Platform remains and will remain a blackbox and its exact functioning is known only to AMD and the US security bureaus, even though this approach doesn't make it inherently more secure.

Platform Security Platform?

Do you mean "Microsoft's Pluton Security Processor" that AMD implemented at the behest of Microsoft?

 

[Vanderlindemedia]

So basically when Socket AM5 and current server sockets are replaced by new ones. Think AMD just inadvertently confirmed Socket AM5's end of life.

Servers are something completely different then consumer versions.

Every socket has a expected life cycle. AM4 was longest.

 

[Amdlova]

If prioritary can make S. Think with open standards... Amd right now is ship of garbage looking only for money.

 

[RedBear87]

Platform Security Platform?

Do you mean "Microsoft's Pluton Security Processor" that AMD implemented at the behest of Microsoft?

I meant AMD's own Platform Security Processor, which was used on every AMD's CPU/APU since Zen 1; but yeah, Pluton is an additional recent example of AMD's opacity and lack of interest in open source solutions.

 

[RichardtST]

As a security professional deep into the depths of it all for over 40 years, I can tell you unequivocally that Open Source is NEVER more secure and is always and invariably a bad idea. It will only add more complexity, more unreliability, and more 0days. Never give up control of important software to the Open Source crowd. That's where code goes to die.

 

[Kamen Rider Blade]

As a security professional deep into the depths of it all for over 40 years, I can tell you unequivocally that Open Source is NEVER more secure and is always and invariably a bad idea. It will only add more complexity, more unreliability, and more 0days. Never give up control of important software to the Open Source crowd. That's where code goes to die.

So what is the optimum solution?

Closed Source Only?

 

[TJ Hooker]

As a security professional deep into the depths of it all for over 40 years, I can tell you unequivocally that Open Source is NEVER more secure and is always and invariably a bad idea. It will only add more complexity, more unreliability, and more 0days. Never give up control of important software to the Open Source crowd. That's where code goes to die.

"Never give up control of important software to the Open Source crowd. That's where code goes to die"

Posted to a website that uses open source webserver software (nginx), likely hosted on a server running an open source kernel/utilities (i.e. the hypervisor and/or guest or host kernel), which was reached via network infrastructure that often runs on open source software (e.g. linux kernel), probably using a browser based on open source code (either chromium-based or Firefox).

I also find it odd that someone claiming to have 40+ years of cyber security experience apparently doesn't understand the concept of password hashing, seemingly thinks you can break TLS or VPN encryption using hashcat and some RTX 4090s, and gives the impression they don't really understand the difference between hashing and encryption. Based on past comments like this one:

Well, there are a few caveats.... If your password looks like random gibberish then the device would not even know that it had succeeded and cruise right by it. And most password-protected devices these days have timeouts and limited retries exactly to prevent machines from trying a bazillion in an instant. Sorry, three tries and you're locked out for 24 hours.

What it does do, however, is to create a big mess for crypto/security in general. It used to be a pain to crack a secure encrypted connection. Now it is not. Random password or no, I can rerun your packet streams with different keys as many times and as fast as I want.

You think you get privacy with your VPN? Lol! No.

 

[hotaru.hino]

The cynic in me is thinking that AMD is trying to shirk its software development responsibilities to someone else and taking the FOSS route produces the best PR.

If you noticed in practically every FOSS license, there's something like this or similar:

From the MIT license

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

From the BSD license

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

From the Apache license

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

i.e., "use this software at your own risk because we won't provide any support"

 

[RichardtST]

So what is the optimum solution?

Closed Source Only?

Unfortunately there is no "optimal" solution. There are only less bad ones. Yes, closed source with tight quality control is the best way to go. It keeps foreign entities and bad actors from sneaking bad code into the codebase. That said... even under tight control, testing, testing, testing, and the KISS PRINCIPLE are the best solutions.

 

[bit_user]

It looks like AMD will use the "Agnostic 3 Static Library" solution

I was trying to figure out what that is. As best I can discern, no such thing exists.

If you look at the whitepaper (?) on AMD's website, they talk about "an agnostic set of library functions" organized into "a set of three statically linked libraries – xSIM (x86 Silicon Initialization Libraries), xPRF (x86 Platform Reference Library) & xUSL (x86 Utilities & Services Library), that can be statically linked to any host firmware during compile/link time."

It goes into quite a bit more detail, so take a look if it interests you:

​

https://community.amd.com/t5/busine...-open-system-firmware-amd-opensil/ba-p/599644​

​

BTW, I thought it was more likely than not that they'd use Rust.

 

[bit_user]

The cynic in me is thinking that AMD is trying to shirk its software development responsibilities to someone else and taking the FOSS route produces the best PR.

If you noticed in practically every FOSS license, there's something like this or similar:

No, because they have a vested interest in the success of their platform and they have business contracts with key partners and customers which formalize their obligations. This is definitely not a ploy to get themselves off the hook.

Other than visibility, it also lets their partners and customers more easily customize and also contribute fixes & improvements back upstream.

 

[hotaru.hino]

No, because they have a vested interest in the success of their platform and they have business contracts with key partners and customers which formalize their obligations. This is definitely not a ploy to get themselves off the hook.

To continue on with my cynicism, if this only applies to AMD's platforms, then open sourcing it still feels lip service.

Other than visibility, it also lets their partners and customers more easily customize and also contribute fixes & improvements back upstream.

I was under the impression that AGESA was already available in some form or fashion for customization anyway. Confusingly though, Wikipedia claims AGESA was open sourced.

I just see this having the same value as Apple open sourcing the Mach kernel. Sure it opens up more eyes to the code and allows for contributions, but at the end of the day you're still not allowed to run macOS/iOS/whateverOS except on Apple devices because the stuff on top of the kernel is still proprietary.

I might see more value in this if AMD goes the way of RISC-V.

 

[bit_user]

To continue on with my cynicism, if this only applies to AMD's platforms, then open sourcing it still feels lip service.

It's not useless, either from a transparency point of view or as a means of collaboration with its ecosystem partners (platform vendors, BIOS makers, etc.), as I already explained.

However, if you read the article, you'd have seen where it says:

"It isn't limited to AMD silicon, either. AMD openSIL is open to other silicon vendors, and the chipmaker has invited them to participate in the venture."
​

I was under the impression that AGESA was already available in some form or fashion for customization anyway. Confusingly though, Wikipedia claims AGESA was open sourced.

I don't know about that, but even if AGESA is already open source, consider openSIL a redesign.

I just see this having the same value as Apple open sourcing the Mach kernel.

Sure it opens up more eyes to the code and allows for contributions, but at the end of the day you're still not allowed to run macOS/iOS/whateverOS except on Apple devices because the stuff on top of the kernel is still proprietary.

It's different, because AGESA isn't the end product. End users make use of it by it being integrated into platform BIOS, and that's developed by others and customized by board makers.

I think you're trying too hard to find fault, here. Truth be told, it's really not something you should even think about, as an end user. Unless they use CoreBoot, the devices you use have BIOS that's not open to you, so why do you really even care what's inside of it?

I might see more value in this if AMD goes the way of RISC-V.

The matters of what ISA the CPU runs and whether its firmware initialization interface is open source are orthogonal.

If you're going to invest any more time on this subject, you should really take a few minutes and read AMD's whitepaper, before anything else.

https://community.amd.com/t5/busine...-open-system-firmware-amd-opensil/ba-p/599644
​

 

[chewy_tha_baller]

This open source AGESA replacement isn't for end users. Rather, it isn't targeting consumer users or organizations which purchase hundreds or even thousands of users, this is targeting hyperscale customers who buy servers by the hundreds of thousands. There has been a serious effort for several years now by the hyperscale crowd to replace closed source black-box BIOS with something along the lines of Coreboot + Linuxboot. The issue has been the black box nature of Intel Microcode and AMD AGESA. Memory initialization in particular has proven too difficult to reverse engineer in time to be useful for production deployment. The main issue being that the typical UEFI BIOS implementation has too many attack vectors and too much crap in it which the hyperscale datacenter guys don't use, so they want to gut the thing to the absolute bare minimum necessary to light the platform. By providing an open source replacement for AGESA, AMD is taking the first step towards an open BIOS implementation and given themselves a big selling point over intel to the hyperscale crowd. This isn't something the home gamer knows or cares about, but this is a big deal to the guys buying 6+ figures worth of servers every year. This happened first in the industry with OpenBMC, and the next major step is to open up the server BIOS.

 

[bit_user]

this is targeting hyperscale customers who buy servers by the hundreds of thousands.

That's what OCP is, but AMD was clear that OpenSIL will also be coming to their client processor platform and roughly when.

 

[Deleted member 2731765]

I was trying to figure out what that is. As best I can discern, no such thing exists.

If you look at the whitepaper (?) on AMD's website, they talk about "an agnostic set of library functions" organized into "a set of three statically linked libraries – xSIM (x86 Silicon Initialization Libraries), xPRF (x86 Platform Reference Library) & xUSL (x86 Utilities & Services Library), that can be statically linked to any host firmware during compile/link time."

It goes into quite a bit more detail, so take a look if it interests you:

​

https://community.amd.com/t5/busine...-open-system-firmware-amd-opensil/ba-p/599644​

​

BTW, I thought it was more likely than not that they'd use Rust.

Oh, that's seems interesting. Thanks for the link. I will go through it soon. Was very busy yesterday.

Kind of off topic.

But when it comes to RUST vs C/C++, basics/coding, I think Rust has the potential to replace C++ and some other low-level languages. Although C has 50 years of history, it has managed to retain its simple design. But Rust is a good and well designed language, since it also takes care of memory management in compilation time.

C leaves the memory management to the developer. If the memory allocation and releases are not at the right points, segfault and overflow problems may occur.

For example, we can write a C program that segfaults at runtime, but the Rust compiler on the other hand realizes that this program will encounter a memory problem at runtime, and hence will not compile the program.

 

[bit_user]

But when it comes to RUST vs C/C++, basics/coding, I think Rust has the potential to replace C++ and some other low-level languages. Although C has 50 years of history, it has managed to retain its simple design. But Rust is a good and well designed language, since it also takes care of memory management in compilation time.

Not being experienced with Rust, myself, I was surprised to hear it characterized as lower-level than C++ and therefore more suitable for embedded systems that currently use C.

Also, the Linux kernel, which famously resisted C++, has added support for device drivers to be written in Rust. Depending on how that goes, it seems like they're willing to consider integrating it into other parts of the kernel.

C leaves the memory management to the developer. If the memory allocation and releases are not at the right points, segfault and overflow problems may occur.

Classes of dynamic memory errors, in C:

• Use before/without allocation - tends to result in segfaults (abnormal program termination), but can be tricky to debug if the pointer wasn't initialized, which could behave like "use after free", if the pointer happens to contain a previously-valid memory address.
• Read before/without initialization - a common source of non-determinism, often resulting in inconsistent or "impossible" program states.
• Failed allocation - cannot allocate memory. If not carefully handled, tends to result in segfaults (abnormal program termination).
• Leaked - allocated but not free; results in memory over-consumption, possibly leading to swapping and future allocation failures.
• Use after free - can cause unpredictable behavior or heap corruption, which can lead to abnormal program termination. Tricky to debug, since symptoms typically manifest elsewhere than the original error.
• Double-free - memory is freed twice (or more). Sometimes detectable, but if the second free happens after the memory has been reallocated elsewhere, then it can reduce to "use after free".
• Out-of-bounds access - can result from too little memory being allocated. Can behave like a "read of uninitialized memory", "use after free", or simply cause a segfault.

That's all that come to mind.

A lot of features of C++ and its runtime library are aimed at tackling these, but mainly through the cooperation of the developer. C++ doesn't force you to do things safely, which means you can still shoot yourself in the foot. It also means you get to decide when you want the overhead of additional runtime or compile-time safety.

For example, we can write a C program that segfaults at runtime, but the Rust compiler on the other hand realizes that this program will encounter a memory problem at runtime, and hence will not compile the program.

Yeah, it's designed to make memory errors impossible, at the expense of longer compile times.

It was pioneered by the Mozilla folks, and Firefox uses it (formerly written in C++).