----- jmattson@xxxxxxxxxx wrote:
> From: Andrew Honig <ahonig@xxxxxxxxxx>
>
> This adds a memory barrier when performing a lookup into
> the vmcs_field_to_offset_table. This is related to
> CVE-2017-5753.
>
> Signed-off-by: Andrew Honig <ahonig@xxxxxxxxxx>
> Reviewed-by: Jim Mattson <jmattson@xxxxxxxxxx>
> ---
> arch/x86/kvm/vmx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index cef1882e5d57..f304ebb20229 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1084,6 +1084,7 @@ static inline struct vmcs_field_info
> *to_vmcs_field_info(unsigned long field)
> if (field >= ARRAY_SIZE(vmcs_field_to_offset_table))
> return NULL;
>
> + asm("lfence"); // Change to gmb() when it's available.
> f = &vmcs_field_to_offset_table[field];
> if (f->offset == 0)
> return NULL;
> --
> 2.16.0.rc1.238.g530d649a79-goog
Can you elaborate on why this specific place was chosen to have a "speculation barrier"?
What is the attack scenario that you had in mind?
Is it because when L1 executes VMREAD/VMWRITE with a general-purpose-register,
it will be read by handle_vmread()/handle_vmwrite() from VMCS and used as an index to vmcs_field_to_offset_table[] which could be used speculatively out-of-bound?
Regards,
-Liran
