Re: [PATCH 4/4] x86/vvmx: Don't handle unknown nested vmexit reasons at L0

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 26/10/2018 10:05, Sergey Dyasli wrote:
>
> On 25/10/2018 16:39, Andrew Cooper wrote:
>> This is very dangerous from a security point of view, because a missing entry
>> will cause L2's action to be interpreted as L1's action.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Sergey Dyasli <sergey.dyasli@citrix.com>
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Jun Nakajima <jun.nakajima@intel.com>
>> CC: Kevin Tian <kevin.tian@intel.com>
>> ---
>>  xen/arch/x86/hvm/vmx/vvmx.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
>> index d1c8a41..817d85f 100644
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -2609,8 +2609,9 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
>>              nvcpu->nv_vmexit_pending = 1;
>>          break;
>>      default:
>> -        gprintk(XENLOG_ERR, "Unexpected nested vmexit: reason %u\n",
>> +        gprintk(XENLOG_ERR, "Unhandled nested vmexit: reason %u\n",
>>                  exit_reason);
>> +        domain_crash(v->domain);
>>      }
>>  
>>      return ( nvcpu->nv_vmexit_pending == 1 );
> Can you consider adding handling for the following?
>
> 	EXIT_REASON_INVD
> 	EXIT_REASON_RDTSCP
> 	EXIT_REASON_VMFUNC

Looks like these should be merged in with the INVVPID change, if your
happy with that?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel