[MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1

[Kees Cook <kees@outflux.net>]

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

-- 
Kees Cook                                            @outflux.net