Anyone who has done a lot of storage, or NFS, etc.. knows that the du usecase is pathological and likely the worst case.
Staying tuned for additional updates, for example he could use the boot flags to disable/enable the support for this in order to eliminate other changes within the kernel.
First, the US has weak consumer protection agencies, which means when a company does do something wrong, the only effective resolution is through the civil court system.
Second, companies hate class-action lawsuits and have spent decades promoting the idea that people sue too much and that the court system is full of frivolous cases.
Remember, most people can't afford a lawsuit. It's very expensive, and there's always the chance of failing. Class-action lawsuits are the only way to make it practical when a company actually does something seriously negligent.
Which is why companies don't like it. What they really want is to minimize consumer protections. Hence the trend to switch customers to mandatory arbitration, which keep people from being able to file class-action lawsuit. Hence laws like the Texas damage caps, which make it easier for a company to carry out grossly negligent practices with out worrying about punitive damages.
And why they publish lists of "outrageous" court filings. They want people like you to think it's a problem, so be biased against lawsuits and those who file for lawsuits.
"The mysterious case of the Linux Page Table Isolation patches"
Also, if this bug lets the kernel leak data to user processes, would it also not be the case that different processes would leak data to each other? If that is true, then it seems that just isolating the kernel wouldn't be enough.
That would be a much, much more invasive architectural change - and it would perform much worse than the page table isolation fixes.
Also, if this bug lets the kernel leak data to user processes, would it also not be the case that different processes would leak data to each other?
No. The problem is with pages that are mapped, but (supposed to be) inaccessible from your current privilege level. The user mappings of other processes aren't in your page tables at all.
From one user process to another user process is already solved. The CR3 register gets reloaded, even on older kernels. Well, it's true for anything released after about 1992. If you have Linux 0.01 or 0.02, you might need a patch for that too.
I have to wonder how this extra code compares to just letting the hardware switch CR3 via a doublefault exception task gate. With a doublefault task switch, the last bit of executable code could be unmapped.
There is already a TLB flush when context-switching from one user-space process to the other. This is one of the basis of multitasking. The problem here, if I understand correctly, is processes accessing arbitrary kernel region.
But you lock up two entire cores doing so.
For multi-core workloads, performance obviously decreases, mostly because you are missing an entire CPU core. Also, you would introduce locking between cores as only one user core could call the kernel at any one time.
Additionally, we have no idea how this bug (whatever it is) interacts with hyperthreading.
Windows, *BSD and macOS are having the same kind of patches.
Even their support team couldn't figure that out despite having other customers running into it, I managed to figure it out using xenalyze or something basically tracing the scheduler actions and found that all the dom0 cores were only being scheduled something like once per second each. Was kinda crazy.
No Batch Core scheduling in that version of Xen either. I think newer versions might have it? Might not work when you have every core assigned to a domain though.
The solution was to only plug 2 CPUs into Dom0, rather than plug all 24 and give it a 200% slice of them.