From: Andi Kleen <ak@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1
Date: Thu, 3 May 2018 11:58:14 -0700 [thread overview]
Message-ID: <20180503185814.GY75137@tassilo.jf.intel.com> (raw)
In-Reply-To: <20180503170439.GD6017@outflux.net>
> 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?
>
> 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.
-Andi
next prev parent reply other threads:[~2018-05-03 18:58 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 [this message]
2018-05-03 23:17 ` Kees Cook
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:
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=20180503185814.GY75137@tassilo.jf.intel.com \
--to=ak@linux.intel.com \
--cc=speck@linutronix.de \
/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
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.