On 11/18/2018 02:17 PM, Jiri Kosina wrote: > On Sun, 18 Nov 2018, Linus Torvalds wrote: > >>> So, I think it's as theoretical as any other spectrev2 (only with the >>> extra "HT" condition added on top). >> >> What? No. >> >> It's *way* more theoretical than something like meltdown, which could >> be trivially used to get data from another protection domain. > > Oh yeah, I absolutely agree that spectrev2 and Meltdown and completely > different beasts. > >> Have you seen any actual realistic attacks for normal human users? >> Things where the *kernel* should actually care? >> >> The javascript thing is for the browser to fix up, > > It's probably not just browsers, but anything running JITed sandboxed > code. So the most straightforward way might be the prctl() aproach, where > userspace would claim "I do care about this, please fix it up for me". So > prctl() + perhaps SECCOMP. > > Which gets us back to Tim's fixup patch. Do you still prefer the revert, > given the existence of that? I think that if Tim's fixup makes it through > (it's currently missing SECCOMP handling, but that is trivial to add on > top), it might be the best compromise. We'd also have have to make IBPB > obey it to be consistent (and get even a few more % of performance back), > but that's easy as well. > > Thanks, > I think if Thomas can merge my patchset along with Jiri's, the default option will become opt in for tasks that want the extra security and we won't lose performance. Tasks that want extra security will enable that via prctl interface or making themselves non-dumpable. Admin that want security for all tasks will enable the strict option on boot to enable STIBP for all tasks. So my patchset and Jiri's patchset should probably be merged together, so the users have a choice of the behavior. Tim
