On 6/18/20 7:43 AM, Andersen, John wrote: > On Thu, Jun 18, 2020 at 07:18:09AM -0700, Dave Hansen wrote: >> On 6/17/20 12:07 PM, John Andersen wrote: >>> +#define KVM_CR0_PIN_ALLOWED (X86_CR0_WP) >>> +#define KVM_CR4_PIN_ALLOWED (X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP) >> >> Why *is* there an allowed set? Why don't we just allow everything? >> >> Shouldn't we also pin any unknown bits? The CR4.FSGSBASE bit is an >> example of something that showed up CPUs without Linux knowing about it. >> If set, it causes problems. This set couldn't have helped FSGSBASE >> because it is not in the allowed set. >> >> 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. > > The allowed set came about because there were comments from internal review > where it was said that allowing the guest to pin TS and MP adds unnecessary > complexity. That would have been a great design point to include in the changelog. Could you make sure it shows up in future versions. > Also because KVM always intercepts these bits via the CR0/4_GUEST_HOST_MASK. If > we allow setting of any bits, then we have to add some infrastructure for > modifying the mask when pinned bits are updated. I have a patch for that if we > want to go that route, but it doesn't account for the added complexity > mentioned above. Well, we have a current, known issue (FSGSBASE) which shows how dealing with guest-unknown bits is required. To me, that overrules complexity arguments to a large degree.
