sec17-koppe-reverse-engineering-AMD-microcode.pdf

Notices where this attachment appears

1. Embed this notice
   翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Saturday, 24-Dec-2022 17:31:39 JST 翠星石

   in reply to
   @vitali64sur >Linux itself as a whole isn't proprietary.
   I'm sorry, Linux is made up of free and proprietary parts, but if you look at it a whole, it's proprietary due to the proprietary parts.
   You're seem to be trying to say something akin to: "The well isn't poisoned as only 1% of the volume is poison and 99% is still water".
   
   >I don't think microcode source code makes sense (it's binary made to run in a CPU directly. How can you write microcode using C for example?)
   I don't know much about PowerPC microcode, but I know a bit about AMD64 microcode, so I'll write about that.
   
   For AMD64 CPU's, microcode does have source code, although it's likely in a custom language and probably not C (there's no way to be sure unless Intel or AMD note how they do it).
   The only setup that makes sense is if microcode is programmed, "compiled" and then built into the CPU as ROM.
   
   As for microcode updates, those are typically hooks applied to certain instructions in the microcode in ROM and I really doubt those patches would be done in the "machine code" form.
   Rather, the updates are likely programmed in the same source code form, hooking against the ROM binary and then "compiled".
   
   If the above is correct, the microcode source is therefore the source code form of the microcode in ROM as well as the source code form of the patches.
   
   
   See attached for an analysis into the microcode of certain AMD processors.
   
   
   >so this isn't proprietary in my opinion.
   It's so proprietary that both Intel and AMD have carefully written disgraceful proprietary software licenses for their microcode updates (referring to the updates as software).