Linux 6.12-rc5 Disabling Intel's Linear Address Masking "LAM" Due To Security Concerns

[cutterjohn]

It's also ridiculous to speculate on CPU designs when you can BARELY even simulate them, along w/the mfg process and so many other factors that can contricute to hw vulnerabilities...

i.e. it's NOT just a PURELY desgn methodology that introduces any vulnerabilities, and these have only relatively recently become all of the security 'rage'... i.e. perhaps in the future there will be methodologies that tend to avoid such problems, but who knows... better smaller scale simulation at more useful simulations 'speeds'? Who knows....

[Phoronos]

It's also ridiculous to speculate on CPU designs when you can BARELY even simulate them, along w/the mfg process and so many other factors that can contricute to hw vulnerabilities...

i.e. it's NOT just a PURELY desgn methodology that introduces any vulnerabilities, and these have only relatively recently become all of the security 'rage'... i.e. perhaps in the future there will be methodologies that tend to avoid such problems, but who knows... better smaller scale simulation at more useful simulations 'speeds'? Who knows....

ok..... what are the solutions to avoid CPU vulnerabilities ???

[uxmkt]

ok..... what are the solutions to avoid CPU vulnerabilities ???

Avoiding speculative execution and possibly also avoiding out-of-order execution. See for example the UltraSPARC T1. It was not necessarily fast, but it wasn't outrageously slow either (at least subjectively).

[Avamander]

My next CPU will be a Chinese RISC-V.
And if it takes five to ten years till they get ready, i will wait.

Judging by how Chinese vendors have implemented stuff like vector extensions in the past, it seems basically guaranteed that you'll have severe vulnerabilities in your silicon you can't even microcode your way out of. While on x86_64 you'd be applying a few patches here and there for hard-to-exploit bugs and a bunch of people are trying to do so without sacrificing much performance. Up to you though.

[Phoronos]

Judging by how Chinese vendors have implemented stuff like vector extensions in the past, it seems basically guaranteed that you'll have severe vulnerabilities in your silicon you can't even microcode your way out of. While on x86_64 you'd be applying a few patches here and there for hard-to-exploit bugs and a bunch of people are trying to do so without sacrificing much performance. Up to you though.

Chinese vendors can solve theses problems too, like any other countries do. Don't think they are inferior or more stupid than other countries.

[Phoronos]

Avoiding speculative execution and possibly also avoiding out-of-order execution. See for example the UltraSPARC T1. It was not necessarily fast, but it wasn't outrageously slow either (at least subjectively).

There are 2 problems I can see ?
1/ UltraSPARC T1 uses complicated algorithms to avoid those CPU problems. Seems complex to generalize to other CPUs (especially x86).
2/ We cannot be sure those algorithms are robust, because SPARC CPUs were not as much tested as Intel or AMD CPUs.
But why not ? You can ask Intel and AMD to make those changes, but I guess they already have very good hardware engineers who already did research about these algorithms and solutions ?

[Avamander]

Chinese vendors can solve theses problems too, like any other countries do. Don't think they are inferior or more stupid than other countries.

That's the thing though, they haven't gotten the attention and haven't had the chance to iterate over designs. Plus RISC-V implementation flaws tend to be much more permanent (and can't be patched with microcode).

[Phoronos]

That's the thing though, they haven't gotten the attention and haven't had the chance to iterate over designs. Plus RISC-V implementation flaws tend to be much more permanent (and can't be patched with microcode).

I agree....But that's mostly the job of the RISC-V international foundation in Switzerland to do the improvements in the architecture and specifications, isn't it ?
Or you mean chinese or indian companies can do their own RISC-V but it won't be "real" RISC-V anymore, but a "FORK", "DERIVATIVE".

[uxmkt]

There are 2 problems I can see ?
1/ UltraSPARC T1 uses complicated algorithms to avoid those CPU problems.

Do you have sources for this claim? If Wikipedia is anything to go off, the concept of a barrel processor--a core simply round-robin-ing over (hardware) threads and just skipping over the ones that are busy e.g. due to memory transaction--seems pretty trivial.

[Phoronos]

Do you have sources for this claim? If Wikipedia is anything to go off, the concept of a barrel processor--a core simply round-robin-ing over (hardware) threads and just skipping over the ones that are busy e.g. due to memory transaction--seems pretty trivial.

Not trivial. Sources are in the sparc documentations.