On Tue, 20 Nov 2018, Linus Torvalds wrote: > > Implements arch_update_spec_restriction() for x86. Use STIBP to > > restrict speculative execution when running a task set to non-dumpable, > > or clear the restriction if the task is set to dumpable. > > I don't think this necessarily makes sense. > > The new "auto" behavior is that we aim to restrict untrusted code (and > the loader of such code uses prctrl to set that flag), then this whole > "set STIBP for non-dumpable" makes little sense. > > A non-dumpable app by definition is *more* trusted, not less trusted. I understand your argument. I believe actually both ways of protection do make sense in some way (but it doesn't mean we should do it by default). Basically: - process marks itself "I am loading untrusted code" via that prctl() in order to avoid its untrusted code to be used as spectrev2 gadgets - process marks itself "I am loading untrusted code" via that prctl() in order to have its all threads/subprocesses marked the same way, so that one thread can't influence speculative code flow of the other in order to read its memory (the "javascript in one browser tab reads secrets from another tab") - non-dumpable tasks have the branch predictor flushed when context switching to them (IBPB) or when sibling is running untrusted code (STIBP) in order not guarantee that its speculative code flow can never be influenced by previous / sibling process mistraining branch predictor for it, and therefore do not allow reading its secrets from memory through gadgets that'd have to be in the process code itself But I agree there are many reasons why this shouldn't be done by default if we accept 'prctl' as the default mode. Namely: - the whole "proper gadgets need to be present in the process' .text" is dubious by itself - the unavoidable overhead it'd impose on network daemons that you can't really get rid of The distiled patchset that Thomas will be sending around today is not have the dumpability restriction in it. Thanks, -- Jiri Kosina SUSE Labs
