2018-01-23 15:21+0100, Christian Borntraeger: > Paolo, Radim, > > this patch not only allows to isolate a userspace process, it also allows us > to add a new interface for KVM that would allow us to isolate a KVM guest CPU > to no longer being able to inject branches in any host or other guests. > (while > at the same time QEMU and host kernel can run with full power). > We just have to set the TIF bit TIF_ISOLATE_BP_GUEST for the thread that runs > a > given CPU. This would certainly be an addon patch on top of this patch at a > later > point in time.
I think that the default should be secure, so userspace will be breaking the isolation instead of setting it up and having just one place to screw up would be better -- the prctl could decide which isolation mode to pick. Maybe we can change the conditions and break logical connection between TIF_ISOLATE_BP and TIF_ISOLATE_BP_GUEST, to make a separate KVM interface useful. > Do you think something similar would be useful for other architectures as > well? It goes against my idea of virtualization, but there probably are users that don't care about isolation and still use virtual machines ... I expect most architectures to have a fairly similar resolution of branch prediction leaks, so the idea should be easily abstractable on all levels. (At least x86 is.) > In that case we should try to come up with a cross-architecture interface to > enable > that. Makes me think of a generic VM control "prefer performance over security", which would also take care of future problems and let arches decide what is worth the code. A main drawback is that this will introduce dynamic branches to the code, which are going to slow down the common case to speed up a niche.
