seccomp 1

Review static inline void seccomp_assign_mode(struct task_struct *task, · line 260

Quoted 8 lines · speck for Kees Cook

(quoted diff) +3 -0

@@ -239,6 +254,9 @@ static inline void seccomp_assign_mode(struct task_struct *task,
 	 */
 	smp_mb__before_atomic();
 	set_tsk_thread_flag(task, TIF_SECCOMP);
+
+	/* Assume seccomp processes want speculation flaw mitigation. */
+	spec_mitigate(task, PR_SPEC_STORE_BYPASS);
 }

What about the ordering there? That function appears to explicitly set TIF_SECCOMP last, such that when that is observed, the complete environment is observed.

But now you add something after it. Does this not mean that if you set this on a remote task, this task can execute TIF_SECCOMP thing before it disables SSB.

Is that OK?

Quoted 14 lines · speck for Peter Zijlstra

Review static inline void seccomp_assign_mode(struct task_struct *task, · line 260

Quoted 8 lines · speck for Kees Cook

(quoted diff) +3 -0

@@ -239,6 +254,9 @@ static inline void seccomp_assign_mode(struct task_struct *task,
 	 */
 	smp_mb__before_atomic();
 	set_tsk_thread_flag(task, TIF_SECCOMP);
+
+	/* Assume seccomp processes want speculation flaw mitigation. */
+	spec_mitigate(task, PR_SPEC_STORE_BYPASS);
 }

What about the ordering there? That function appears to explicitly set TIF_SECCOMP last, such that when that is observed, the complete environment is observed.

Quoted 5 lines

But now you add something after it. Does this not mean that if you set this on a remote task, this task can execute TIF_SECCOMP thing before it disables SSB.

Is that OK?

It probably should be the other way round.

From: Kees Cook <[email protected]>
Subject: opt-in under seccomp

As seccomp use overlaps best (though not perfectly) with applications most likely to want speculation flaw mitigations enabled, seccomp will enable them when seccomp is enabled for a task. Also adds a line to /proc/$pid/status for examining the mitigation state of a task.

Quoted 7 lines · speck for Kees Cook

From: Kees Cook <[email protected]>
Subject: opt-in under seccomp

As seccomp use overlaps best (though not perfectly) with applications most likely to want speculation flaw mitigations enabled, seccomp will enable them when seccomp is enabled for a task. Also adds a line to /proc/$pid/status for examining the mitigation state of a task.

As I wrote earlier this isn't a good idea. We went through this earlier.

It originally seems like a good idea until you start looking at the details.

The big users of seccomp like the web browsers eventually don't want it once they use site isolation. And it would unnecessarily slow them down.

And other programs need to be maintained anyways (e.g. for spectre variant 1 fixes) so they can as well add it explicitely.

Separate enabling makes more sense. And that is already in the patchkit.

Quoted 14 lines · speck for Andi Kleen

Quoted 7 lines · speck for Kees Cook

From: Kees Cook <[email protected]>
Subject: opt-in under seccomp

As seccomp use overlaps best (though not perfectly) with applications most likely to want speculation flaw mitigations enabled, seccomp will enable them when seccomp is enabled for a task. Also adds a line to /proc/$pid/status for examining the mitigation state of a task.

As I wrote earlier this isn't a good idea. We went through this earlier.

It originally seems like a good idea until you start looking at the details.

Quoted 8 lines

The big users of seccomp like the web browsers eventually don't want it once they use site isolation. And it would unnecessarily slow them down.

And other programs need to be maintained anyways (e.g. for spectre variant 1 fixes) so they can as well add it explicitely.

Separate enabling makes more sense. And that is already in the patchkit.

You're just ignoring the fact that they are not having it today and it's about providing the best out of the box protection right now.

Telling people: "We have this shiny new prtcl and your browser will eventually use it but until then you're on your own." is just bullshit.

Kees certainly knows what he is talking about and being involved in chrome gives him definitely more weight than your 'eventually don't want' and 'have to be maintained anyways' advisories which have exactly zero technical content.

The other problem with 'site isolation' is that it doesn't necessarily solve or even mitigate the problem: if for example malicious Javascript is injected from an ad network, supposedly safely sandboxed, but it can still anomalously read site

local data via leaky speculation then that's still a dangerous violation of sandboxing constraints: it could read pointers to defeat ASLR,

it could read local keys or other data it's not supposed to read.

Once a browser specifically knows that it has fully mitigated against an attack it can turn off any default mitigation early in its init sequence via the prctl, when it still has full OS access and no seccomp isolation. All child tasks should inherit that.

Quoted 27 lines · speck for Thomas Gleixner

Quoted 14 lines · speck for Andi Kleen

Quoted 7 lines · speck for Kees Cook

From: Kees Cook <[email protected]>
Subject: opt-in under seccomp

As seccomp use overlaps best (though not perfectly) with applications most likely to want speculation flaw mitigations enabled, seccomp will enable them when seccomp is enabled for a task. Also adds a line to /proc/$pid/status for examining the mitigation state of a task.

As I wrote earlier this isn't a good idea. We went through this earlier.

It originally seems like a good idea until you start looking at the details.

Quoted 8 lines

The big users of seccomp like the web browsers eventually don't want it once they use site isolation. And it would unnecessarily slow them down.

And other programs need to be maintained anyways (e.g. for spectre variant 1 fixes) so they can as well add it explicitely.

Separate enabling makes more sense. And that is already in the patchkit.

You're just ignoring the fact that they are not having it today and it's about providing the best out of the box protection right now.

Quoted 7 lines

Telling people: "We have this shiny new prtcl and your browser will eventually use it but until then you're on your own." is just bullshit.

Kees certainly knows what he is talking about and being involved in chrome gives him definitely more weight than your 'eventually don't want' and 'have to be maintained anyways' advisories which have exactly zero technical content.

The other problem with 'site isolation' is that it doesn't necessarily solve or even mitigate the problem: if for example malicious Javascript is injected from an ad network, supposedly safely sandboxed, but it can still anomalously read site local data via leaky speculation then that's still a dangerous violation of sandboxing constraints: it could read pointers to defeat ASLR, it could read local keys or other data it's not supposed to read.

Once a browser specifically knows that it has fully mitigated against an attack it can turn off any default mitigation early in its init sequence via the prctl, when it still has full OS access and no seccomp isolation. All child tasks should inherit that.

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.

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.

Quoted 3 lines

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?

Quoted 7 lines

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.

Telling people: "We have this shiny new prtcl and your browser will eventually use it but until then you're on your own." is just bullshit.