On 07/07/20 23:48, Dave Hansen wrote: > On 7/7/20 2:12 PM, Sean Christopherson wrote: >>>>> Let's say Intel loses its marbles and adds a CR4 bit that lets userspace >>>>> write to kernel memory. Linux won't set it, but an attacker would go >>>>> after it, first thing. >> That's an orthogonal to pinning. KVM never lets the guest set CR4 bits that >> are unknown to KVM. Supporting CR4.NO_MARBLES would require an explicit KVM >> change to allow it to be set by the guest, and would also require a userspace >> VMM to expose NO_MARBLES to the guest. >> >> That being said, this series should supporting pinning as much as possible, >> i.e. if the bit can be exposed to the guest and doesn't require special >> handling in KVM, allow it to be pinned. E.g. TS is a special case because >> pinning would require additional emulator support and IMO isn't interesting >> enough to justify the extra complexity. At a glance, I don't see anything >> that would prevent pinning FSGSBASE. > > Thanks for filling in the KVM picture. > > If we're supporting as much pinning as possible, can we also add > something to make it inconvenient for someone to both make a CR4 bit > known to KVM *and* ignore the pinning aspects? > > We should really make folks think about it. Something like: > > #define KVM_CR4_KNOWN 0xff > #define KVM_CR4_PIN_ALLOWED 0xf0 > #define KVM_CR4_PIN_NOT_ALLOWED 0x0f > > BUILD_BUG_ON(KVM_CR4_KNOWN != > (KVM_CR4_PIN_ALLOWED|KVM_CR4_PIN_NOT_ALLOWED)); > > So someone *MUST* make an active declaration about new bits being pinned > or not? I would just make all unknown bits pinnable (or perhaps all CR4 bits in general). Paolo
