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