Date:   Sat, 25 Aug 2018 23:28:16 +0000
From:   "Artem S. Tashkinov" <aros@....com>
To:     Casey Schaufler <casey@...aufler-ca.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Disabling CPU vulnerabilities workarounds

On 08/25/2018 06:39 PM, Casey Schaufler wrote:
> 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.

As far as I know mitigations started to appear in January 2018 and 
kernels released prior to this date all work just fine without any 
issues with "correctness", so I'm not sure what you're talking about.

I'm quite sure at least Intel perfectly knows, as well as Linus Torvalds 
who coordinates everything.

Also

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f73fa6f6d85e..e6362717c895 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -991,7 +991,7 @@ static void __init cpu_set_bug_bits(struct 
cpuinfo_x86 *c)
{
u64 ia32_cap = 0;

- if (x86_match_cpu(cpu_no_speculation))
+ //if (x86_match_cpu(cpu_no_speculation))
return;

setup_force_cpu_bug(X86_BUG_SPECTRE_V1);

and setting this in .config:

CONFIG_RETPOLINE=n
CONFIG_PAGE_TABLE_ISOLATION=n

Ostensibly disables all mitigations and everything continues to work 
just fine.

> 
>> 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'm not sure

1) why you're trying to mix unrelated classes of vulnerabilities - of 
course there are vulnerabilities other than the ones caused by 
speculative execution;

2) why you're insisting that my argument, that someone may never run 
untrusted code, has no merit. I may perfectly have a standard Linux 
distro installed on my PC/server and never run a web browser or any 
similar applications other than the ones provided by my distro in a form 
of various packages - which means I will never run any untrusted code. I 
will also never run any scriptable applications 
(bash/python/php/ruby/etc) from the net either. How such a configuration 
might be susceptible to speculative execution attacks?

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

I'd love to leave that task to those who are more proficient in writing 
kernel code and whose work is more likely to be merged. My patch might 
be never streamlined for totally unrelated reasons (and we've seen too 
many examples of that already).

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

Again, I see no challenges since, for instance, RHEL has gone as far as 
to backport all the patches to previously released officially 
unmaintained kernels, so all these patches could be easily disabled if 
one really wanted to.

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

I guess you meant "turn everything off".


Best regards,
Artem

Powered by blists - more mailing lists