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