Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

[Andrea Arcangeli]

Hello everyone,

On Mon, Nov 19, 2018 at 02:49:36PM +0100, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> 
> > > On Sat, 17 Nov 2018, Jiri Kosina wrote:
> > 
> > > Subject: [PATCH] x86/speculation: enforce STIBP for SECCOMP tasks in lite mode
> > > 
> > > If 'lite' mode of app2app protection from spectre_v2 is selected on
> > > kernel command-line, we are currently applying STIBP protection to
> > > non-dumpable tasks, and tasks that have explicitly requested such
> > > protection via
> > > 
> > > 	prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_ENABLE, 0, 0);
> > > 
> > > Let's extend this to cover also SECCOMP tasks (analogically to how we
> > > apply SSBD protection).
> > 
> > Right. And SSBD does not fiddle with dumpable.
> > 
> > Willy had concerns about the (ab)use of dumpable so I'm holding off on that
> > bit for now.
> 
> Yeah. IBPB implementation used to check the dumpability of tasks during 
> rescheduling, but that went away later.
> 
> I still think that ideally that 'app2app' setting would toggle how IBPB is 
> being used as well, something along the lines:
> 
> lite:
> 	- STIBP for the ones marked via prctl() and SECCOMP with the TIF_ 
> 	  flag

Note: STIBP is not SSBD: STIBP enabled inside the SECCOMP jail only
makes the code inside SECCOMP immune from attack from processes
outside the SECCOMP jail.

The specs don't say if by making it immune from BTB mistraining, it
also could prevent to mistrain the BTB in order to attack what's
outside the SECCOMP jail. Probably it won't and I doubt we can rely on
it even if some implementation could do that.

Generally speaking the untrusted code that would try to use spectrev2
to attack the other processes is more likely to run inside SECCOMP
jail than outside, so if SECCOMP should be used as a best effort
heuristic to decide when to enable STIBP, it would make more sense to
enable STIBP outside SECCOMP, and not inside. I.e. the exact opposite
of what you're proposing above.

Code running under SECCOMP is not necessarily less performance
critical so if we don't protect what's outside, I doubt we should
protect what's inside.

In short I doubt we can make an association between SECCOMP and STIBP
here and we should leave SECCOMP alone this time.

The prctl is a nice to have feature, but it is more for specialized
apps like gpg that aren't performance critical anyway.

The system wide default is more a decision the admin should do without
having to add prctl wrappers to all apps or change config
files. Clearly the prctl won't hurt especially if it can be overridden
(and forced off) with the global tweak like with the ssbd options. The
only thing I don't understand is why one has to reboot to change the
global defaults for ssbd and now STIBP (unless you're already planning
to make the global tweak runtime tunable) despite there's no runtime
benefit by forcing these decision at boot time only. Would be nice to
add runtime tweak options for at least STIBP and SSBD that aren't
confined to the prctl.

Thanks,
Andrea