LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: "Artem S. Tashkinov" <aros@gmx.com>, linux-kernel@vger.kernel.org
Subject: Re: Disabling CPU vulnerabilities workarounds
Date: Sat, 25 Aug 2018 11:39:48 -0700
Message-ID: <3830fa4c-29d6-99e9-6c8e-b1a30cba59f0@schaufler-ca.com> (raw)
In-Reply-To: <575b6581-7dcb-96a9-b06e-9f74dda5fa86@gmx.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


  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-25 10:42 Artem S. Tashkinov
2018-08-25 18:39 ` Casey Schaufler [this message]
2018-08-25 23:28   ` Artem S. Tashkinov
2018-08-26 20:54     ` Casey Schaufler
  -- strict thread matches above, loose matches on Subject: below --
2018-08-23 16:33 Artem S. Tashkinov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3830fa4c-29d6-99e9-6c8e-b1a30cba59f0@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=aros@gmx.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git