Re: [PATCH 1/2] KVM: SVM: Fix workaround for AMD Errata 1096

[Liran Alon <liran.alon@oracle.com>]

> On 16 Jul 2019, at 18:48, Singh, Brijesh <brijesh.singh@amd.com> wrote:
> 
> On 7/15/19 3:30 PM, Liran Alon wrote:
>> According to AMD Errata 1096:
>> "On a nested data page fault when CR4.SMAP = 1 and the guest data read generates a SMAP violation, the
>> GuestInstrBytes field of the VMCB on a VMEXIT will incorrectly return 0h instead the correct guest instruction
>> bytes."
>> 
>> As stated above, errata is encountered when guest read generates a SMAP violation. i.e. vCPU runs
>> with CPL<3 and CR4.SMAP=1. However, code have mistakenly checked if CPL==3 and CR4.SMAP==0.
>> 
> 
> The SMAP violation will occur from CPL3 so CPL==3 is a valid check.
> 
> See [1] for complete discussion
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_10808075_-2322479271&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=RAt8t8nBaCxUPy5OTDkO0n8BMQ5l9oSfLMiL0TLTu6c&s=Nkwe8rTJhygBCIPz27LXrylptjnWyMwB-nJaiowWpWc&e= 

I still don’t understand. SMAP is a mechanism which is meant to protect a CPU running in CPL<3 from mistakenly referencing data controllable by CPL==3.
Therefore, SMAP violation should be raised when CPL<3 and data referenced is mapped in page-tables with PTE with U/S bit set to 1. (i.e. User accessible).

Thus, we should check if CPL<3 and CR4.SMAP==1.

-Liran

> 
> However, code mistakenly checked CR4.SMAP==0, it should be CR4.SMAP==1
> 
>> To avoid future confusion and improve code readbility, comment errata details in code and not
>> just in commit message.
>> 
>> Fixes: 05d5a4863525 ("KVM: SVM: Workaround errata#1096 (insn_len maybe zero on SMAP violation)")
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Signed-off-by: Liran Alon <liran.alon@oracle.com>
>> ---
>>  arch/x86/kvm/svm.c | 17 +++++++++++++----
>>  1 file changed, 13 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>> index 735b8c01895e..79023a41f7a7 100644
>> --- a/arch/x86/kvm/svm.c
>> +++ b/arch/x86/kvm/svm.c
>> @@ -7123,10 +7123,19 @@ static bool svm_need_emulation_on_page_fault(struct kvm_vcpu *vcpu)
>>  	bool is_user, smap;
>> 
>>  	is_user = svm_get_cpl(vcpu) == 3;
>> -	smap = !kvm_read_cr4_bits(vcpu, X86_CR4_SMAP);
>> +	smap = kvm_read_cr4_bits(vcpu, X86_CR4_SMAP);
>> 
> 
> Ah good catch. thank
> 
> 
>>  	/*
>> -	 * Detect and workaround Errata 1096 Fam_17h_00_0Fh
>> +	 * Detect and workaround Errata 1096 Fam_17h_00_0Fh.
>> +	 *
>> +	 * Errata:
>> +	 * On a nested page fault when CR4.SMAP=1 and the guest data read generates
>> +	 * a SMAP violation, GuestIntrBytes field of the VMCB on a VMEXIT will
>> +	 * incorrectly return 0 instead the correct guest instruction bytes.
>> +	 *
>> +	 * Workaround:
>> +	 * To determine what instruction the guest was executing, the hypervisor
>> +	 * will have to decode the instruction at the instruction pointer.
>>  	 *
>>  	 * In non SEV guest, hypervisor will be able to read the guest
>>  	 * memory to decode the instruction pointer when insn_len is zero
>> @@ -7137,11 +7146,11 @@ static bool svm_need_emulation_on_page_fault(struct kvm_vcpu *vcpu)
>>  	 * instruction pointer so we will not able to workaround it. Lets
>>  	 * print the error and request to kill the guest.
>>  	 */
>> -	if (is_user && smap) {
>> +	if (!is_user && smap) {
>>  		if (!sev_guest(vcpu->kvm))
>>  			return true;
>> 
>> -		pr_err_ratelimited("KVM: Guest triggered AMD Erratum 1096\n");
>> +		pr_err_ratelimited("KVM: SEV Guest triggered AMD Erratum 1096\n");
>>  		kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
>>  	}
>> 
>>