4 ms·

Security implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding

by xmodem 2y ago

Security implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding them better.

AnotherGoodName 2y ago
Also I’m curious if there’s opportunity for an all out perf variant from home brewers. Eg. Throw away all spectre mitigations, find all the hacks to get each instructions timing down, etc.
- basementcat 2y ago
  While you’re at it, allow for a few more ulp (units of least place) error for floating point ops.
  - basementcat 2y ago
    Kidding aside, my understanding is this sort of thing cannot be microcode patched. But I would be pleased to be proven wrong.
    - Lockal 2y ago
      It can be patched, see example in "constant-time hardware division" section in https://misc0110.net/files/cpu_woot23.pdf https://misc0110.net/files/cpu_woot23.pdf (code: https://github.com/pietroborrello/CustomProcessingUnit/blob/master/bios/ucode_patches/ctdiv.u https://github.com/pietroborrello/CustomProcessingUnit/blob/...). You probably won't observe any improvement unless you know an algo massively better than reciprocals+newton.
mindslight 2y ago
Security implications? This is a win for distributed security - it's a "vulnerability" in the sense of the end of a movie where the evil overlord's plan falls apart. > This vulnerability could be used by an adversary to compromise confidential computing workloads protected by the newest version of AMD Secure Encrypted Virtualization, SEV-SNP or to compromise Dynamic Root of Trust Measurement. I don't know whether the people who write this upside-down corpo newspeak are so coked up on the authoritarian paradigm that they've lost touch with the reality, or if they're just paid well enough by the corpos to not care about making society worse, or what. But I'll translate: This "vulnerability" might be used by the owner of a computer to inspect what their computer is actually doing or to defend themselves against coercion aiming to control the software they're running.
- ngneer 2y ago
  I am all for Right to Repair, and am upset with the "evil overlords" as much as the next guy. But, to present the treacherous computing argument all on its own, is, well, incomplete. I am a huge fan of Ross Anderson, RIP. However, the reality is that while DRTM was originally envisioned primarily for DRM applications, it is nowadays leveraged to protect PCs against bootkits and the like. YOU may like to own your computer through and through, down to the microcode, but, for most people, their computer is viewed as a product, that they trust vendors to secure for them. If ultimate control is so important to you, can you not buy any machine you like, including one based on a RISC-V open-source processor? https://community.amd.com/t5/business/amd-and-microsoft-secured-core-pc/ba-p/418204 https://community.amd.com/t5/business/amd-and-microsoft-secu...
  - mindslight 2y ago
    > If ultimate control is so important to you, can you not buy any machine you like, including one based on a RISC-V open-source processor? This argument (or the individualist approach in general) no longer works in the context of remote attestation ("Dynamic Root of Trust Measurement"). As soon as the "average person" has a computer that can be counted on to betray what software they're running, remote parties will start turning the screws of coercion and making everyone use such a machine.
    - ngneer 2y ago
      Yes, remote attestation is tantamount to the hardware snitching on the execution, and not necessarily to the benefit of the platform owner. I agree with you, that from a game theoretic perspective, as soon as the vast majority of platforms betray user trust, those seeking to use other machines will be left stranded. However, despite the above dynamics, you could still buy any machine you like and use it any way you like, just like app stores have alternatives. You may not like the alternative, but that is a different story. Knowing nothing about you, it is safe to assume that you may use the dollar or similar currency, either directly or indirectly. Why would you choose to do that? Such currencies come with lots of rules and regulations about what you can and cannot do. Society must keep track of who has how much in banks, and individuals are held liable should there be an overdraft. Remote attestation may certainly put a damper on doing your own thing with your computer, but you can choose whether you wish to pay the price of participating in the economy. Not sure if the above is a great analogy, probably a terrible one, but the bygone ideal of having your computer acting solely in your interest is simply not very realistic. At the very least, controlling the microcode will not give you the control you seek, because there are too many other layers in the stack that are routinely broken, and you are always one exploit away from joining a botnet. No matter how you wish to spin it, your computer is not yours, and obeys many masters. If you feel otherwise, please offer a counterexample to the preceding statement.
pabs3 2y ago
I wonder how much of the built-in microcode you could replace with Free-as-in-Freedom equivalents, I expect not all of it due to available SRAM?
- p_l 2y ago
  Unless you want to break the CPU, huge portions would have to be bit-to-bit equal, which makes the exercise have easy lower value (is it "free as in freedom" if it's effectively a bit wise copy?) while adding legal issues (it would not just be derivative work, it works be mostly an exact copy)

by xmodem 2y ago

Security implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding them better.

AnotherGoodName 2y ago

Also I’m curious if there’s opportunity for an all out perf variant from home brewers. Eg. Throw away all spectre mitigations, find all the hacks to get each instructions timing down, etc.

basementcat 2y ago
While you’re at it, allow for a few more ulp (units of least place) error for floating point ops.
- basementcat 2y ago
  Kidding aside, my understanding is this sort of thing cannot be microcode patched. But I would be pleased to be proven wrong.
  - Lockal 2y ago
    It can be patched, see example in "constant-time hardware division" section in https://misc0110.net/files/cpu_woot23.pdf https://misc0110.net/files/cpu_woot23.pdf (code: https://github.com/pietroborrello/CustomProcessingUnit/blob/master/bios/ucode_patches/ctdiv.u https://github.com/pietroborrello/CustomProcessingUnit/blob/...). You probably won't observe any improvement unless you know an algo massively better than reciprocals+newton.

mindslight 2y ago

Security implications? This is a win for distributed security - it's a "vulnerability" in the sense of the end of a movie where the evil overlord's plan falls apart. > This vulnerability could be used by an adversary to compromise confidential computing workloads protected by the newest version of AMD Secure Encrypted Virtualization, SEV-SNP or to compromise Dynamic Root of Trust Measurement. I don't know whether the people who write this upside-down corpo newspeak are so coked up on the authoritarian paradigm that they've lost touch with the reality, or if they're just paid well enough by the corpos to not care about making society worse, or what. But I'll translate: This "vulnerability" might be used by the owner of a computer to inspect what their computer is actually doing or to defend themselves against coercion aiming to control the software they're running.

ngneer 2y ago
I am all for Right to Repair, and am upset with the "evil overlords" as much as the next guy. But, to present the treacherous computing argument all on its own, is, well, incomplete. I am a huge fan of Ross Anderson, RIP. However, the reality is that while DRTM was originally envisioned primarily for DRM applications, it is nowadays leveraged to protect PCs against bootkits and the like. YOU may like to own your computer through and through, down to the microcode, but, for most people, their computer is viewed as a product, that they trust vendors to secure for them. If ultimate control is so important to you, can you not buy any machine you like, including one based on a RISC-V open-source processor? https://community.amd.com/t5/business/amd-and-microsoft-secured-core-pc/ba-p/418204 https://community.amd.com/t5/business/amd-and-microsoft-secu...
- mindslight 2y ago
  > If ultimate control is so important to you, can you not buy any machine you like, including one based on a RISC-V open-source processor? This argument (or the individualist approach in general) no longer works in the context of remote attestation ("Dynamic Root of Trust Measurement"). As soon as the "average person" has a computer that can be counted on to betray what software they're running, remote parties will start turning the screws of coercion and making everyone use such a machine.
  - ngneer 2y ago
    Yes, remote attestation is tantamount to the hardware snitching on the execution, and not necessarily to the benefit of the platform owner. I agree with you, that from a game theoretic perspective, as soon as the vast majority of platforms betray user trust, those seeking to use other machines will be left stranded. However, despite the above dynamics, you could still buy any machine you like and use it any way you like, just like app stores have alternatives. You may not like the alternative, but that is a different story. Knowing nothing about you, it is safe to assume that you may use the dollar or similar currency, either directly or indirectly. Why would you choose to do that? Such currencies come with lots of rules and regulations about what you can and cannot do. Society must keep track of who has how much in banks, and individuals are held liable should there be an overdraft. Remote attestation may certainly put a damper on doing your own thing with your computer, but you can choose whether you wish to pay the price of participating in the economy. Not sure if the above is a great analogy, probably a terrible one, but the bygone ideal of having your computer acting solely in your interest is simply not very realistic. At the very least, controlling the microcode will not give you the control you seek, because there are too many other layers in the stack that are routinely broken, and you are always one exploit away from joining a botnet. No matter how you wish to spin it, your computer is not yours, and obeys many masters. If you feel otherwise, please offer a counterexample to the preceding statement.

pabs3 2y ago

I wonder how much of the built-in microcode you could replace with Free-as-in-Freedom equivalents, I expect not all of it due to available SRAM?

p_l 2y ago
Unless you want to break the CPU, huge portions would have to be bit-to-bit equal, which makes the exercise have easy lower value (is it "free as in freedom" if it's effectively a bit wise copy?) while adding legal issues (it would not just be derivative work, it works be mostly an exact copy)