If I had my choice between a CPU that has a vulnerability that can only be exploited if the system is already compromised
or a CPU that are full of oxidation cancer, or frying themselves and doing irreparable damage… Which the company is being excessively shady about concretely admitting to any RMA promises and wwill all eventually die in short order…
I think I’m gonna go with the Ryzen and not leave leave my computer outside at defcon.
Sure but we’re talking about several generation old CPUs: nothing’s wrong with Intel’s 10/9/8th gen CPUs, which would be the contemporary ones to the Ryzen chips in question.
How is that? Does risc-v have magical properties that make its designers infallible, or somehow make it possible to fix flaws in the physical design after the CPU has already been fabbed and sold?
Because it does not set in stone that there can be only 2 companies producing compatible chips, which can be however bad until both of them does the same shit practices.
So the short answer is by not stifling competition.
As much as I like RISC-V, it is kind of ironic to suggest RISC-V ist the solution to this. At least as it stands, because of RISC-V’s simplicity, most if not all current RISC-V CPUs don’t even run microcode, so there is nothing to update/fix in case of a CPU bug. There’s even a very current example of this problem with that chinese RISC-V cpu that has this “GhostWrite” bug that allows every unpriviliged process to gain root access.
As I said in an other reply, RISC-V is not the solution for the reason that they are perfect today. It is because it is not limited to being used by a few megacorporations that do whatever they want, but it allows competition where companies do what they need to become and remain a good choice.
I understood that. My point was rather that in this particular case (a CPU bug that could be fixed via microcode, but AMD chose not to do so for certain CPUs), RISC-V wouldn’t have been of any advantage, because there would be nothing to fix in the first place. Sure, one could introduce microcode for RISC-V and people have argued in favor of doing so for this exact reason, but the architecture was intentionally designed to not require microcode.
I dont know.
If I had my choice between a CPU that has a vulnerability that can only be exploited if the system is already compromised
or a CPU that are full of oxidation cancer, or frying themselves and doing irreparable damage… Which the company is being excessively shady about concretely admitting to any RMA promises and wwill all eventually die in short order…
I think I’m gonna go with the Ryzen and not leave leave my computer outside at defcon.
Sure but we’re talking about several generation old CPUs: nothing’s wrong with Intel’s 10/9/8th gen CPUs, which would be the contemporary ones to the Ryzen chips in question.
Risc-V is the real response to this problem
How is that? Does risc-v have magical properties that make its designers infallible, or somehow make it possible to fix flaws in the physical design after the CPU has already been fabbed and sold?
So what you are saying is, it’s just as Risc-E
Because it does not set in stone that there can be only 2 companies producing compatible chips, which can be however bad until both of them does the same shit practices.
So the short answer is by not stifling competition.
As much as I like RISC-V, it is kind of ironic to suggest RISC-V ist the solution to this. At least as it stands, because of RISC-V’s simplicity, most if not all current RISC-V CPUs don’t even run microcode, so there is nothing to update/fix in case of a CPU bug. There’s even a very current example of this problem with that chinese RISC-V cpu that has this “GhostWrite” bug that allows every unpriviliged process to gain root access.
As I said in an other reply, RISC-V is not the solution for the reason that they are perfect today. It is because it is not limited to being used by a few megacorporations that do whatever they want, but it allows competition where companies do what they need to become and remain a good choice.
I understood that. My point was rather that in this particular case (a CPU bug that could be fixed via microcode, but AMD chose not to do so for certain CPUs), RISC-V wouldn’t have been of any advantage, because there would be nothing to fix in the first place. Sure, one could introduce microcode for RISC-V and people have argued in favor of doing so for this exact reason, but the architecture was intentionally designed to not require microcode.
Now we just need a friendly neighbourhood nanoscale fab.
Removed by mod