On Tue, 23 Jan 2018 21:32:24 +0100 Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: > 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. The prctl is one direction only. Once a task is "secured" there is no way back. If we start with a default of secure then *all* tasks will run with limited branch prediction. > 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. The thinking here is that you use TIF_ISOLATE_BP to make use space secure, but you need to close the loophole that you can use a KVM guest to get out of the secured mode. That is why you need to run the guest with isolated BP if TIF_ISOLATE_BP is set. But if you want to run qemu as always and only the KVM guest with isolataed BP you need a second bit, thus TIF_ISOLATE_GUEST_BP. > > 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.) Yes. > > 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. VM as in virtual machine or VM as in virtual memory? > 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. Where would you place these additional branches? I don't quite get the idea. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- 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
