linux-kernel - Re: [PATCH v3 27/34] KVM: selftests: Sync 'struct hv_enlightened

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 May 2022 15:17:23 +0300
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Michael Kelley <mikelley@...rosoft.com>,
        Siddharth Chandrasekaran <sidcha@...zon.de>,
        linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 27/34] KVM: selftests: Sync 'struct
 hv_enlightened_vmcs' definition with hyperv-tlfs.h

On Thu, 2022-04-14 at 15:20 +0200, Vitaly Kuznetsov wrote:
> 'struct hv_enlightened_vmcs' definition in selftests is not '__packed'
> and so we rely on the compiler doing the right padding. This is not
> obvious so it seems beneficial to use the same definition as in kernel.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
> ---
>  tools/testing/selftests/kvm/include/x86_64/evmcs.h | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/testing/selftests/kvm/include/x86_64/evmcs.h b/tools/testing/selftests/kvm/include/x86_64/evmcs.h
> index cc5d14a45702..b6067b555110 100644
> --- a/tools/testing/selftests/kvm/include/x86_64/evmcs.h
> +++ b/tools/testing/selftests/kvm/include/x86_64/evmcs.h
> @@ -41,6 +41,8 @@ struct hv_enlightened_vmcs {
>  	u16 host_gs_selector;
>  	u16 host_tr_selector;
>  
> +	u16 padding16_1;
> +
>  	u64 host_ia32_pat;
>  	u64 host_ia32_efer;
>  
> @@ -159,7 +161,7 @@ struct hv_enlightened_vmcs {
>  	u64 ept_pointer;
>  
>  	u16 virtual_processor_id;
> -	u16 padding16[3];
> +	u16 padding16_2[3];
>  
>  	u64 padding64_2[5];
>  	u64 guest_physical_address;
> @@ -195,15 +197,15 @@ struct hv_enlightened_vmcs {
>  	u64 guest_rip;
>  
>  	u32 hv_clean_fields;
> -	u32 hv_padding_32;
> +	u32 padding32_1;
>  	u32 hv_synthetic_controls;
>  	struct {
>  		u32 nested_flush_hypercall:1;
>  		u32 msr_bitmap:1;
>  		u32 reserved:30;
> -	} hv_enlightenments_control;
> +	}  __packed hv_enlightenments_control;
>  	u32 hv_vp_id;
> -
> +	u32 padding32_2;
>  	u64 hv_vm_id;
>  	u64 partition_assist_page;
>  	u64 padding64_4[4];
> @@ -211,7 +213,7 @@ struct hv_enlightened_vmcs {
>  	u64 padding64_5[7];
>  	u64 xss_exit_bitmap;
>  	u64 padding64_6[7];
> -};
> +} __packed;
>  
>  #define HV_VMX_ENLIGHTENED_CLEAN_FIELD_NONE                     0
>  #define HV_VMX_ENLIGHTENED_CLEAN_FIELD_IO_BITMAP                BIT(0)

Makes sense.

Reviewed-by: Maxim Levitsky <mlevitsk@...hat.com>

Best regards,
	Maxim Levitsky