All of
 help / color / mirror / Atom feed
From: Kees Cook <>
Subject: [MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1
Date: Thu, 3 May 2018 16:17:26 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, May 03, 2018 at 11:58:14AM -0700, speck for Andi Kleen wrote:
> > My goal is providing SOME kind of "by default" coverage that doesn't
> > require an admin to write new code or wait for a software vendor to provide
> > an update.
> What's your target for this? Is it the web browser or something else?

My target is "something unexpected" as we can't know what all the
containers in the world are actually containing. (And, while SpectreV1
is still an issue, it'd be nice to have coverage against SSB for browsers
that are slow with Site Isolation.)

> > If it is tolerable to wait for a vendor to _enable_ the mitigation, then
> > it should be tolerable to wait for a vendor to _disable_ the mitigation
> > as well. i.e. we protect a targeted subset of processes (those using
> > seccomp) but provide a way to disable it later. To that end, how about
> > a new prctl or seccomp flag that indicates "do no enable speculation
> > mitigations under seccomp"? That would give any seccomp users the ability
> > to opt-out if they wanted to.
> Yes if you add it to seccomp that would be needed.
> It should already work with the existing prctl?  Need to test that.  
> The problem with the prctl of course is that it would override external
> user choice. But perhaps that is ok.

I think tglx and I cooked up a workable solution. seccomp users will
now be able to individually opt out of the automatic mitigation (by
adding the new SECCOMP_FILTER_FLAG_SPEC_ALLOW flag), and sysadmins will
be able to globally opt out of the seccomp behavior by booting with
"spec_store_bypass_disable=prctl". (The default is "seccomp" which is
prctl plus seccomp.)

If it turns out immediately that seccomp coverage was a terrible idea,
we can switch the default back to "prctl". And maybe in a few years
once we're happy with the state of software vulnerable to SSB, we can
do the same.


Kees Cook                                  

  reply	other threads:[~2018-05-03 23:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03  0:44 [MODERATED] [PATCH SSBv11 0/3] seccomp 1 Kees Cook
2018-05-01 22:07 ` [MODERATED] [PATCH SSBv11 3/3] seccomp 0 Kees Cook
2018-05-01 22:19 ` [MODERATED] [PATCH SSBv11 1/3] seccomp 2 Kees Cook
2018-05-01 22:31 ` [MODERATED] [PATCH SSBv11 2/3] seccomp 3 Kees Cook
2018-05-03  8:58 ` [MODERATED] Re: [PATCH SSBv11 3/3] seccomp 0 Peter Zijlstra
2018-05-03  9:21   ` Thomas Gleixner
2018-05-03 16:03     ` [MODERATED] " Kees Cook
2018-05-03 12:29 ` [MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1 Andi Kleen
2018-05-03 12:45   ` Thomas Gleixner
2018-05-03 14:09     ` [MODERATED] " Ingo Molnar
2018-05-03 14:57       ` Andi Kleen
2018-05-03 17:04       ` Kees Cook
2018-05-03 18:58         ` Andi Kleen
2018-05-03 23:17           ` Kees Cook [this message]
2018-05-03 14:47     ` Andi Kleen

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:

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

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.