On Wed, 2023-04-26 at 11:05 +0800, Gao, Chao wrote: > On Wed, Apr 26, 2023 at 06:48:21AM +0800, Huang, Kai wrote: > > ... when EPT is on, as you mentioned guest can update CR3 w/o causing VMEXIT to > > KVM. > > > > Is there any global enabling bit in any of CR to turn on/off LAM globally? It > > seems there isn't because AFAICT the bits in CR4 are used to control super mode > > linear address but not LAM in global? > > Right. > > > > > So if it is true, then it appears hardware depends on CPUID purely to decide > > whether to perform LAM or not. > > > > Which means, IIRC, when EPT is on, if we don't expose LAM to the guest on the > > hardware that supports LAM, I think guest can still enable LAM in CR3 w/o > > causing any trouble (because the hardware actually supports this feature)? > > Yes. But I think it is a non-issue ... > > > > > If it's true, it seems we should trap CR3 (at least loading) when hardware > > supports LAM but it's not exposed to the guest, so that KVM can correctly reject > > any LAM control bits when guest illegally does so? > > > > Other features which need no explicit enablement (like AVX and other > new instructions) have the same problem. OK. > > The impact is some guests can use features which they are not supposed > to use. Then they might be broken after migration or kvm's instruction > emulation. But they put themselves at stake, KVM shouldn't be blamed. > > The downside of intercepting CR3 is the performance impact on existing > VMs (all with old CPU models and thus all have no LAM). If they are > migrated to LAM-capable parts in the future, they will suffer > performance drop even though they are good tenents (i.e., won't try to > use LAM). > > IMO, the value of preventing some guests from setting LAM_U48/U57 in CR3 > when EPT=on cannot outweigh the performance impact. So, I vote to > document in changelog or comments that: > A guest can enable LAM for userspace pointers when EPT=on even if LAM > isn't exposed to it. KVM doens't prevent this out of performance > consideration Yeah performance impact is the concern. I agree we can just call out this in changelog and/or comments. Just want to make sure this is mentioned/discussed. My main concern is, as (any) VMEXIT saves guest's CR3 to VMCS's GUEST_CR3, KVM may see GUEST_CR3 containing invalid control bits (because KVM believes the guest doesn't support those feature bits), and if KVM code carelessly uses WARN() around those code, a malicious guest may be able to attack host, which means we need to pay more attention to code review around GUEST_CR3 in the future. Anyway not intercepting CR3 is fine to me, and will leave this to others.
