On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote: > And the "big hammer" approach to spectre would seem to > be to just make sure the BTB and RSB are flushed at vmexit time - and > even then you might decide that you really want to just move it to > vmenter time, and only do it if the VM has changed since last time > (per CPU). The IBPB which flushes the BTB is *expensive*; we really want to reduce the amount we do that. For VM guests it's not so bad — we do it only on VMPTRLD which is sufficient to ensure it's done between running one vCPU and the next. And if vCPUs are pinned to pCPUs that means we basically never do it. Even for userspace we've mostly settled on a heuristic where we only do the IBPB flush for non-dumpable processes, precisely because it's so expensive. > Why do you even _care_ about the guest, and how it acts wrt Skylake? > What you should care about is not so much the guests (which do their > own thing) but protect guests from each other, no? Well yes, that's the part we had to fix before anyone was allowed to sleep. But customers kind of care about security *within* their part too, and we care about customers. :) Sure, the cloud *enables* a model where a given VM guest is just a single-tenant standalone compute job, and the kernel is effectively just a library to provide services to the application. In some sense it's all about the app, and you might as well be using uCLinux from the security point of view. So *some* (perhaps even *many*) guests don't need to care. But there are still plenty who *do* need to care, for various reasons.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
