Re: Disabling CPU vulnerabilities workarounds

[Casey Schaufler <casey@schaufler-ca.com>]

On 8/25/2018 3:42 AM, Artem S. Tashkinov wrote:
> Hello LKML,
>
> 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 in one fell swoop.

Many of the mitigations are unrelated to each other. There is no one
aspect of the system that identifies a behavior as a security issue.
I don't know anyone who could create a list of all the "fixes" that
have gone in over the years. Realize that features like speculative
execution have had security issues that are unrelated to obscure attacks
like side-channels. While you may think that you don't care, some of
those flaws affect correctness. My bet is you wouldn't want to disable
those.

> Disabling is a good option for strictly confined environments where no 3d 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.

Like maybe the software in centrifuges in a nuclear fuel processing plant?

All the examples you've cited are network connected and are vulnerable to attack.
And don't try the "no untrusted code" argument. You'll have code on those systems
that has been known vulnerable for decades.

> I wonder if someone could wrote a patch which implemented the following two options for the kernel:
>
> * A boot option option which allows to disable most runtime protections/workarounds/fixes (as far as I understand some of them can't be reverted since they are compiled in or use certain GCC flags), e.g. let's call it "insecure" or "insecurecpumode".

That would be an interesting exercise for the opposite case. A boot option
that enables all the runtime protections would certainly be interesting to
some people. If you could implement one, you could do the other.

I would be happy to review such a patch. Go for it.

> * A compile-time CONFIG_ option which disables all these fixes _permanently_ without a way to turn them later back on during runtime.

This suffers from all the challenges previously mentioned, but would
be equally interesting, again for the opposite case.

>
> 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.

I can't argue with you on that. Again, I believe the greater value would
come from documenting how to turn everything on.

> Best regards,
> Artem