The number of commits game does not necessarily help you to become a trusted member of the community. That's a pure number which is mostly used inside companies for the completely wrong reasons, which makes people game the system. I personally do not care about the number of commits someone has, what I care about is whether I came to the conclusion that the contributions are well thought out or not. And that's something which builds up over time and surely not with a large amount of 'fixes' which mechanically address the output of some tool.

You should have warned me before I stumbled over this:

https://www.the-postillon.com/...

Emphasis on quick analysis. There is no way to actually claim for sure that the gadgets do not exist.

The main reason why that particular issue is not a big problem for Linux is the fact that Linux does not support the FSGSBASE feature which allows user space to write arbitrary GS/FS base values. Linux does not support that and limits GS to the canonical user space address space which does not allow the attacker to direct it at arbitrary kernel addresses. So the main thing which an attacker can observe is it's own address space which is not particularly useful. There are a few corner cases which are even interesting with this restriction. Therefore adding the mitigation to Linux makes tons of sense.

See: https://git.kernel.org/linus/4...

While AMD does not speculate through SWAPGS, it still is affected by a mis-speculated branch which does NOT issue SWAPGS when it should.

That means on an entry from user space the CPU speculates around the SWAPGS path and any subsequent GS based access uses the user GS base. So AMD is affected as well, but only on one of the possible mis-speculated branches.

So AMD has just 50% of the problem, but as Intel is affected by Meltdown, the Meltdown mitigation - if enabled - mitigates the Intel only path already because the CR3 write is serializing.

The other path has the same problem on both vendors and that's a fundamental issue of speculative execution and branch (mis)prediction.

The 20180703 micro code release has the mitigations for a set of server class CPUs and comes with the old micro code license, which does not contain any of those restrictions. Also experimentation has shown, that the micro code variant for flushing L1D on VMENTER is not really much different slowdown wise from the software L1D flush mitigation which is used by the Linux kernel/KVM when the magic new MSR is not available.

While Joe Desktop User does not worry much about the L1TF mess, he very much is interested in the other fixes and mitigations which come with those updates.

It's a sad state of affairs, that corporates seem to be able to screw their customers in any way they see fit. Seems to be a common scheme. Just look at the Diesel disaster where now the car owners are facing driving restrictions in certain cities because their cars do not comply to the emission standards.

"4K replay is causing the 4 fans to run full speed. The ventilation slots are at the bottom of the device so it starts to take off the shelf like a copter" Nightly explained.

That would be outright hillarious!