AMD openSIL Detailed For Advancing Open-Source System Firmware

[kiffmet]

So these static libraries will be distributed with headers but without source code?

[stormcrow]

From what I'm reading of the announcement, it's a lot of buzzwords to obscure the fact that all they're doing is moving the majority of the code that matters in bringing up the CPU and PSP into statically linked closed (and probably obfuscated) libraries while opening the glue code in the AEGSA. This is one step forward but two or even three steps back. It's still a nothing burger. I don't see anything to be excited about once you toss the purposely misleading jargon.

The only positive is that the static libraries might be written in some language other than assembly or C although all they actually say is another vague "industry standard language", which can mean anything.

I use a lot of AMD products, because they have historically been open source friendly - more or less. But this... this is nothing. Show us the code not "statically linked [closed] interface libraries and headers."

[Developer12]

How does this affect the prevalence of CPU microcode? I hope—beyond opening up system firmware—it will help eliminate binary blobs elsewhere, thus advance FSF libre aspirations.

You're crazy if you think CPUs will stop using microcode. Every CPU made since the 8086 contains it, and the preloaded microcode has only grown larger and larger

Plus, there are far worse things than microcode on AMD platforms. All the ram init and other key stuff has been pushed down into the far more locked down Platform Security Processor firmware, making it worse than intel who at lest leave it up in the closed-source FSP binaries that you can load or (theoretically) replace yourself.

The FSF's libre hardware aspirations are dead. RYF is itself has always been in complete contradiction with reality.

[Developer12]

It's important to acknowledge that open firmware still has a ways to go, but AMD has been a valuable contributor to its development. While the current state of affairs is not without its flaws, it is much improved compared to previous iterations.

While it's understandable that companies prioritize financial gain, AMD's investment in open source is an admirable strategy. The company has a notable track record of producing high-quality FOSS projects and contributions, and this benefits everyone involved.

It's hard to say this is any better than previous iterations when AMD provided full open source code for family 15h chips that did *everything* including the ram init now done by locked down PSP firmware. And now that code has been dropped by coreboot because in the 10 years since it was provided by AMD nobody stepped up to clean it up.

[stormcrow]

You're crazy if you think CPUs will stop using microcode. Every CPU made since the 8086 contains it, and the preloaded microcode has only grown larger and larger

Plus, there are far worse things than microcode on AMD platforms. All the ram init and other key stuff has been pushed down into the far more locked down Platform Security Processor firmware, making it worse than intel who at lest leave it up in the closed-source FSP binaries that you can load or (theoretically) replace yourself.

The FSF's libre hardware aspirations are dead. RYF is itself has always been in complete contradiction with reality.

To elaborate on your comment, it's not just x86 descendants. Any complex CPU has microcode. It's the programming language the CPU's hardware executes, not the human written program code. Programs break down into instructions for which equivalent microcode sequences are run with the CPU itself usually figuring out what order they run in out of order processors. If microcode wasn't a thing, it would be impossible to fix soft errata on any CPU giving rise to a huge number of hardware step iterations along with much larger, more complex, and proportionately more expensive chips. Some of the execution speed along with the power requirements are predicated on the distance between sections of a CPU and its peripherals. Without microcode CPUs would be much slower, far more power hungry, generate proportionally more heat, and less capable than we have now regardless of the ISA. In some senses, the microcode is the CPU's personality while the transistors are its neurons. For that reason, I don't see traditional chip makers ever opening their microcode to the general public. It would be great if they did for those with the skills to review it. But unlike firmware, microcode is fundamentally an inseparable part of what makes a processor of any lineage x86, ARM, RISC V, POWER, etc. It's also why I don't agree with the extremists when it comes to microcode being open. It might be a good thing (there are reasonable arguments it may not be a good thing, too!), but it's just not realistic to say CPU makers are strictly hardware companies. They are both a hardware and code company because you can't separate the microcode from the processor hardware.

[Ironmask]

You're crazy if you think CPUs will stop using microcode. Every CPU made since the 8086 contains it, and the preloaded microcode has only grown larger and larger

Plus, there are far worse things than microcode on AMD platforms. All the ram init and other key stuff has been pushed down into the far more locked down Platform Security Processor firmware, making it worse than intel who at lest leave it up in the closed-source FSP binaries that you can load or (theoretically) replace yourself.

The FSF's libre hardware aspirations are dead. RYF is itself has always been in complete contradiction with reality.

I always found the politics behind microcode to be funny.

>This is my CPU architecture. You can see the layout, but given that it's too complex to modify or make for yourself, there's no need to worry about licenses or anything.
>Oh great, can't wait to use it.
>And of course some of the logic was done in microcode instead of physical circuits to save on development costs.
>NO NO NO I HAVE TO BE ABLE TO EDIT THAT PART THATS DIFFERENT

[kvuj]

I always found the politics behind microcode to be funny.

>This is my CPU architecture. You can see the layout, but given that it's too complex to modify or make for yourself, there's no need to worry about licenses or anything.
>Oh great, can't wait to use it.
>And of course some of the logic was done in microcode instead of physical circuits to save on development costs.
>NO NO NO I HAVE TO BE ABLE TO EDIT THAT PART THATS DIFFERENT

Maybe, just maybe looking at some code is more fun and educational than trying to physically reverse engineer an extremely complex CPU? Can you imagine how cool it would be to be able to hack on your microcode.

The argument being exaggerated with sarcasm is also correct. If Intel can modify the software running on my CPU, then I should too. If Intel can't modify my hardware then I don't mind as much if I do not possess the rights to do so, though it would be pretty cool if I could peek at how it works.

[NotMine999]

http://www.righto.com

Ken Shiriff has a number of wonderful and extensive blog posts on reverse engineering the 8086 CPU...including the microcode and why it exists.

[stormcrow]

Maybe, just maybe looking at some code is more fun and educational than trying to physically reverse engineer an extremely complex CPU? Can you imagine how cool it would be to be able to hack on your microcode.

The argument being exaggerated with sarcasm is also correct. If Intel can modify the software running on my CPU, then I should too. If Intel can't modify my hardware then I don't mind as much if I do not possess the rights to do so, though it would be pretty cool if I could peek at how it works.

So can people that have malicious intent. I'm not saying they can't do that already (given that somehow they also manage to get the signatures which isn't likely), what I'm saying is that the ability of the odd hacker that wants to play with their microcode is far and away a tiny minority compared to the amount of harm that can be wreaked by skilled malicious actors being able to modify microcode at will - if you can, they can.

The number of people that can look at microcode, understand it, and fix or otherwise meaningfully alter it is tiny. Most are already employed by CPU and firmware companies, the majority of the rest are employed by national intelligence agencies and criminal gangs. The tiny number that are left are not enough to have a meaningful long term impact on the security of all microcode. In order for open source to work you must have an economy of scale of skilled eyes on that code that are at least neutral if not beneficial to the public good. Otherwise, you're just whistling in the dark. Don't bother saying anyone can. That's not true. Not everyone has the skill, nor the time, to audit every single piece of code running on their computer from the CPU microcode to the UI. Not even if you put it to the community at large. We already see plenty of examples of this where projects both heavily and rarely used don't get the scrutiny they need to remain secure in the face of determined malicious actors because few people want the thankless task of auditing and debugging software. They only want to write it.

I don't want to give up my security and the security of the general public just because a handful of people want to look at microcode without obfuscation (use Ghidra if you're all fired up to learn microcode). Obscurity is a necessary layer of security that shouldn't be hand-waved away because an absolutist zealot doesn't like its politics, but doesn't actually care about reviewing what they're demanding be open - only that someone (vaguely hand waving) review it somewhere sometime... hopefully (while it's for sure the bad guys will).

[Ironmask]

Maybe, just maybe looking at some code is more fun and educational than trying to physically reverse engineer an extremely complex CPU? Can you imagine how cool it would be to be able to hack on your microcode.

The argument being exaggerated with sarcasm is also correct. If Intel can modify the software running on my CPU, then I should too. If Intel can't modify my hardware then I don't mind as much if I do not possess the rights to do so, though it would be pretty cool if I could peek at how it works.

Oh no I'm not saying it's not a good thing or cool to do, I was just making fun of people who insist even their microcode be GPL and the like or else they have a panic attack. You know, politics.