On 4/26/2023 4:43 PM, Huang, Kai wrote:
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.
How about do guest CR3 LAM bits check based on the capability of
physical processor instead of vCPU?
That is KVM doesn't prevent guest from setting CR3 LAM bits if the
processor supports LAM.
Anyway not intercepting CR3 is fine to me, and will leave this to others.
