Hello,
I'm resending my last email since the first one didn't draw enough
attention despite the gravity of the situation and the issue has been
exacerbated by the recent kernel 4.20 changes which incur even a larger
performance loss - up to 50% according to the most recent Phoronix testing:
https://www.phoronix.com/scan.php?page=article&item=linux-420-stibp
It looks like only pure compute loads are not affected by the new code
which renders hyper-threading in Intel CPUs almost useless.
The original email follows:
***
As time goes by more and more fixes of Intel/AMD/ARM CPUs
vulnerabilities are added to the Linux kernel without a simple way to
disable them *all*.
Disabling is a good option for strictly confined environments where no
third-party untrusted code is ever to be run, e.g. a rendering farm, a
supercomputer, or even a home server which runs Samba/SSH server and
nothing else.
I wonder if someone could write a patch which implements the following
two options for the kernel:
* A boot option which allows to disable *most*
protections/workarounds/fixes (as far as I understand some of them can't
be reverted since they are compiled-in or use certain GCC workarounds),
e.g. let's call it "insecure" or "insecurecpumode"
* A compile-time config option which disables the said fixes
_permanently_ without a way to turn them back on.
Right now linux/Documentation/admin-guide/kernel-parameters.txt is a
mess of various things which take ages to sift through and there's zero
understanding whether you've found everything and correctly disabled it.
***
Addendum:
I can imagine that writing such a patch is not trivial and no one is
eager to do that. In this case people would love to see an extra file in
the kernel documentation, e.g. CPU-vulnerabilities.txt which lists all
the existing protections in the kernel and the boot options to disable them.
The Internet is already rife with questions how to disable the said
protections and the results are quite different.
In short, it would be great to have some organization in regard to the
issue.
Regards,
Artem