Going out on a limb here, but won't picking different vendor with less hardware problems fix the issue? Let the free market forces weed out weak vendors.

Right but Torvalds point is still important even if the work still has to be done. Are there changes the hardware vendors could make to do a better job of catching some of these things up front? Do they need to reconsider some aspects of their architecture with the security first mindset? If it's purely theoretical does the code get written but not implemented until it's needed? Because it's also true that if we have to implement software fixes that in some cripple the hardware after release you're not real

> It's easy (and true) to say it is the fault of the hardware vendors.

> However, once the product ships, it's unfixable. The only solution is a software fix.

There's another level between hardware and OS: microcode updates shipped by the CPU manufacturers including both Intel and AMD.

These are loaded into CPUs at boot to patch problems found after manufacturing. Fixes made entirely in microcode don't require OS changes.

In some cases, yes, but many hardware issues can also be patched around through microcode/firmware updates.

The issue is more how much time/effort you want to spend hardening yourself against theoretical problems. Until something can be demonstrated practically, I certainly wouldn't be spending much time on it. This has always been a point of tension between security researchers and kernel/SW developers, long before HW-based attack vectors started to become more common.

True, but AMD and Intel firing large numbers of QA staff from their chip lines and trying to accelerate development to stay ahead of the game isn't helping matters.

This was a gamble that was always doomed to lead to spectacular crashes, it was merely a case of how many and when.

Yes. But I think the hardware vendors should provide developer resources here to mitigate the problem they created.

The thing to watch for is that sometimes the set-up to demonstrate the exploit is so specific and so designed to be exploitable that it becomes the moral equivalent of placing a plate of cookies in a kindergarten, loudly announcing "Gee, I hope nobody eats these delicious cookies when I leave the room for half an hour!", then announcing that the "hungry kiddee" attack is a threat level 25 out of 10 and claim that it would be irresponsible not to lock all cookies in a vault with at least a 10 disc lock.

> It would be interesting to see a hardware "minumum standard", perhaps. Worst case, if someone has cruddy hardware, emulate their crap, Bochs style, and then point the finger at them for having something that cannot be done in software, so the entire segment has to be emulated on a low level, just to ensure that it won't cause issues with the rest of the system.

The problem is that the current generation of hardware flaws that Linux is being asked to work around are for a fairly new class of security vulnerabilities, vulnerabilities that exploit modern CPUs' branch prediction and speculative execution. We can't define a list of all of the things hardware must do, and how it must do it, to be safe from these vulnerabilities because we don't yet fully understand them. We do know that we could get rid of them all by eliminating speculative execution, but the perform

Ask ARM to sponsor the Intel bad list and ask Intel to sponsor the ARM bad list.

A list of zero vendors is trivial to maintain. /s

EVERY platform has bugs. Who is going to prioritize what is "critical" versus "mostly harmless"?

If you eliminate the crap machines, what is left? You've pretty much removed all of the available cpus, motherboards, pre-built system, most custom rigs, ...

that is not at all what he said and your second point is complete bs, that whole discussion is that Linus does not see any difference between a bug that affects the kernel in some way and a "security" bug in the kernel, as he sees it they are both bugs and the one can very easily be turned into the other one. That is _all_ that discussion was about. Which pissed of a bunch of security researches that wants to collect fame and bounties.

Unfortunately (or not?), the days of Linux being maintained and controlled by pure-minded volunteers are long gone. Trying to shift back to that a) is not practical; and b) would likely result in a buggier, more vulnerable ecosystem.

If you want highly-skilled devs, you likely need to pay them - and pay them well. How many stories have we seen on Slashdot about FOSS projects languishing specifically because they *didn't* have financial support?

```

How about getting back to our roots ? If your hardware product does not use fully open firmware, we will ban it from being used on Linux.

```

Linux started on i386 with IBMPC BIOS.

What roots are we talking about?

You're going to disable everything but RISC-V and Power on an open source kernel?

Please lay out your strategy.

He speaks plainly about the problem that hardware vendors do not take responsibility for bugs in the hardware. It's a very real problem with very real consequences, and one of those consequences is unfair blame placed on Linux, and its chief maintainer.

If you don't want to read his legitimate complaints, affect change in how the hardware vendors handle the situation. Or just don't read it.

They developed along with "new" ideas of the time like preprocessing doing a database operation to check if an instruction was assembled from a language that allows overloading or not.