Message-ID: <6ddf1956-2501-407f-de01-a7f369527185@schaufler-ca.com>
Date:   Sun, 26 Aug 2018 13:54:03 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     "Artem S. Tashkinov" <aros@....com>, linux-kernel@...r.kernel.org
Subject: Re: Disabling CPU vulnerabilities workarounds

On 8/25/2018 4:28 PM, Artem S. Tashkinov wrote:
> 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.

Mitigations specific to Specture and Meltdown started showing up then.
Speculative execution has been around for a very long time. It would be
foolish to assume that no work has been done in response to other related
issues before then.

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

Don't believe for a minute that no work had been done to address known issues
prior to January.  

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

Well, then there's your answer.

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

I am.

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

Most of the other vulnerabilities are massively easier to exploit than
side-channel. To that end you're right, enabling side-channel mitigations
may be pointless of your systems.

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

You have millions of lines of code in a standard distribution.
Some of that code has not been updated since the Reagan administration.
Why on earth would you trust it?

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

OK, but if you want the feature, who better than you to
contribute 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.
>
> 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.

If you really want to, go ahead and do it!

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

Oh no, I'm pretty good at distinguishing "on" from "off".

>
>
> Best regards,
> Artem
>

Powered by blists - more mailing lists