
Initial Performance Benchmarks of Linux's x86 Security Changes - chowyuncat
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1
======
lathiat
Really glad to see some more useful benchmarks here from Phoronix!

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.

------
adrianN
Is it possible to sue Intel if you need ~30% more web servers because Intel
built faulty processors? The argument would be that you had bought AMD if you
had known about the flaw.

~~~
otp124
Meta question: Why is everyone so eager and trigger-happy to sue these days?
It seems like awful attrition on both humans and the economy. Has this always
been the case? Or has it truly exploded in the last 50-70 years (which is my
assumption)?

~~~
eesmith
They aren't. Most of what you hear about people being "eager and trigger-happy
to sue these days" is due to two factors.

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.

------
cypherpunks01
Historical context:

"The mysterious case of the Linux Page Table Isolation patches"

[https://news.ycombinator.com/item?id=16046636](https://news.ycombinator.com/item?id=16046636)

------
derekp7
With what is known about this bug so far, wouldn't it be possible to mitigate
it by locking the kernel to one CPU core, and run user processes on the other
cores?

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.

~~~
phire
That might improve single core performance.

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.

~~~
craftyguy
It's quite common on HPC systems to schedule jobs on every logical CPU
_except_ cpu0, and give the OS cpu0 for doing OS stuff. In many workloads it
actually improves performance since your job is not stalled waiting for
something on cpu0, which was preempted for executing OS tasks.

~~~
lathiat
I once debugged a pathological case of this where OnApp would configure Xen
with a CPU limit of 200% on a 24 core machine for Dom0, so it could only spend
1/12th of the time in Dom0 - this is measured in time spent but also applies
to all 24 cores. It would more or less totally lock the machine because 1 core
was waiting on a spinlock or similar from another core, and they just
scheduled so slowly it took FOREVER. Combine that with minimimum timeslices of
30ms.. basically each 30ms if would spinlock and do nothing useful. Good
times.

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.

------
bredren
It is interesting to see how posts and comments are written in a way that so
far hides or downplays the severity and owner of this flaw.

~~~
CGamesPlay
The RAM manufacturers, for building their circuits too small? Or Intel, for
allowing a side-channel attack to exist? Or Linux, for assuming that
randomizing some pointers would mitigate any side-channel? This bug is
definitely a product of lots of different issues coming together.

~~~
Zardoz84
> Linux, for assuming that randomizing some pointers would mitigate any side-
> channel?

Windows, *BSD and macOS are having the same kind of patches.

------
keldaris
So, as I understand it, the only way to avoid the rather huge performance hit
is to use the pti=off switch, in effect opting out of KASLR on any Intel CPU
newer than Pentium. Is this correct?

------
Sephr
These cache vulnerabilities can probably be mitigated with lower performance
penalties on CPUs with Intel CAT. It's only available on Intel's Xeon SKUs
though.

