Hacker News Reader

Comment by xmodem | Hacker News Reader

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

View on HN

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.

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-secu...

> 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.

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.

I can't follow the logic.

In the context of remote attestation, they can revoke the key and vulnerability like these won't help.

I was talking about the direct capabilities.

You're talking about the first order reaction.

The reaction to that reaction is that the noose of remote attestation develops slower. As things currently stand, they can't revoke the attestation keys of all the affected processors with websites (etc) just telling the large numbers of people with with those computers that they need to buy new ones. Rather the technological authoritarians have to continue waiting for a working scheme before they can push the expectation of remote attestation being something that is required.

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.

While you’re at it, allow for a few more ulp (units of least place) error for floating point ops.

Kidding aside, my understanding is this sort of thing cannot be microcode patched.

But I would be pleased to be proven wrong.

It can be patched, see example in "constant-time hardware division" section in https://misc0110.net/files/cpu_woot23.pdf (code: https://github.com/pietroborrello/CustomProcessingUnit/blob/...). You probably won't observe any improvement unless you know an algo massively better than reciprocals+newton.

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?

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)

Reply on news.ycombinator.com