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
>
