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. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
