Disabling CPU vulnerabilities workarounds (second try)

[Artem S. Tashkinov]

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