51–60 of 69 posts
Are there any examples of using this for non-nefarious reasons? For instance, could I add new instructions that made some specific calculation faster?
Yes. It's been done before for Intel CPUs. https://misc0110.net/files/cpu_woot23.pdf It's interesting to think about the sorts of things we could do if we had low level control over our hardware. Unfortunately things seem consistently headed in the opposite direction.
Random off topic question: could one theoretically (with infinite time and resources) write new microcode firmware for a modern processor that turns it into an armv8+ processor?
Random off topic question: could one theoretically (with infinite time and resources) write new microcode firmware for a modern processor that turns it into an armv8+ processor?
Random off topic question: could one theoretically (with infinite time and resources) write new microcode firmware for a modern processor that turns it into an armv8+ processor?
Random off topic question: could one theoretically (with infinite time and resources) write new microcode firmware for a modern processor that turns it into an armv8+ processor?
"The first question everyone has about microcode updates is something like "So can I execute ARM64 code natively on my Athlon?" It's a fun idea, but now we know that a microcode patch doesn't work like that -- so the answer is no, sorry!"
Wow, so providing a tool for bypassing the protection mechanism of a device (cpu) is accepted when it comes from google? Try this on any game console or drm protected device ans you are DMCAed before you know it.
only if it's a nintendo console :)
https://github.com/github/dmca/blob/master/2025/02/2025-02-2...
Random off topic question: could one theoretically (with infinite time and resources) write new microcode firmware for a modern processor that turns it into an armv8+ processor?
However, maybe, there is a way. Back when we were researching microcode we found a talk [1] that ran multiple ISAs in parallel on the same processor using microcode. We never figured out how this worked, our best guess is either swapping microcode from RAM as needed or branching to an emulator in x86 code. If this was a K10 cpu, which might be a bit old at the time of the talk, then there is no way you could fit an ARM interpreter into the update. You had, iirc, 32 triads of 3 operations each. Maybe, just maybe, you could fit a bytecode interpreter that then executes the actual ISA emulator. However you would need to hook every instruction, or at least trap on each instruction fetch and hook the appropriate handling routine and both sound very complicated.
If your infinite resources include manufacturing new silicon with the proper fast path and microcode decoder, then yes, but note that x86 and ARM have different memory models. Also at that point you just have a very expensive, very inefficient ARM processor.
[1] https://troopers.de/events/troopers16/655_the_chimaera_proce...
Earlier quoted context omitted.
Yes. It's been done before for Intel CPUs. https://misc0110.net/files/cpu_woot23.pdf It's interesting to think about the sorts of things we could do if we had low level control over our hardware. Unfortunately things seem consistently headed in the opposite direction.
Hopefully RISC-V changes things a bit.