All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: nVMX: properly pad struct kvm_vmx_nested_state_hdr
Date: Mon, 13 Jul 2020 17:54:52 +0200	[thread overview]
Message-ID: <878sfntnoz.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20200713151750.GA29901@linux.intel.com>

Sean Christopherson <sean.j.christopherson@intel.com> writes:

> On Mon, Jul 13, 2020 at 10:28:24AM +0200, Vitaly Kuznetsov wrote:
>> Holes in structs which are userspace ABI are undesireable.
>> 
>> Fixes: 83d31e5271ac ("KVM: nVMX: fixes for preemption timer migration")
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>>  Documentation/virt/kvm/api.rst  | 2 +-
>>  arch/x86/include/uapi/asm/kvm.h | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>> index 320788f81a05..7beccda11978 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -4345,7 +4345,7 @@ Errors:
>>  	struct {
>>  		__u16 flags;
>>  	} smm;
>> -
>> +	__u16 pad;
>
> I don't think this is sufficient.  Before 83d31e5271ac, the struct was:
>

Before 850448f35aaf. Thanks, I was too lazy to check that.

> 	struct kvm_vmx_nested_state_hdr {
> 		__u64 vmxon_pa;
> 		__u64 vmcs12_pa;
>
> 		struct {
> 			__u16 flags;
> 		} smm;
> 	};
>
> which most/all compilers will pad out to 24 bytes on a 64-bit system.  And
> although smm.flags is padded to 8 bytes, it's initialized as a 2 byte value.
>
> 714             struct kvm_vmx_nested_state_hdr boo;
> 715             u64 val;
> 716
> 717             BUILD_BUG_ON(sizeof(boo) != 3*8);
> 718             boo.smm.flags = 0;
>    0xffffffff810148a9 <+41>:    xor    %eax,%eax
>    0xffffffff810148ab <+43>:    mov    %ax,0x18(%rsp)
>
> 719
> 720             val = *((volatile u64 *)(&boo.smm.flags));
>    0xffffffff810148b0 <+48>:    mov    0x18(%rsp),%rax
>
>
> Which means that userspace built for the old kernel will potentially send in
> garbage for the new 'flags' field due to it being uninitialized stack data,
> even with the layout after this patch.
>
> 	struct kvm_vmx_nested_state_hdr {
> 		__u64 vmxon_pa;
> 		__u64 vmcs12_pa;
>
> 		struct {
> 			__u16 flags;
> 		} smm;
> 		__u16 pad;
> 		__u32 flags;
> 		__u64 preemption_timer_deadline;
> 	};
>
> So to be backwards compatible I believe we need to add a __u32 pad as well,
> and to not cause internal padding issues, either make the new 'flags' a
> __u64 or pad that as well (or add and check a reserved __32).  Making flags
> a __64 seems like the least wasteful approach, e.g.
>
> 	struct kvm_vmx_nested_state_hdr {
> 		__u64 vmxon_pa;
> 		__u64 vmcs12_pa;
>
> 		struct {
> 			__u16 flags;
> 		} smm;
> 		__u16 pad16;
> 		__u32 pad32;
> 		__u64 flags;
> 		__u64 preemption_timer_deadline;
> 	};

I see and I agree but the fix like that needs to get into 5.8 or an ABI
breakage is guaranteed. I'll send v2 immediately, hope Paolo will take a
look.

>
>
>>  	__u32 flags;
>>  	__u64 preemption_timer_deadline;
>>    };
>> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
>> index 0780f97c1850..aae3df1cbd01 100644
>> --- a/arch/x86/include/uapi/asm/kvm.h
>> +++ b/arch/x86/include/uapi/asm/kvm.h
>> @@ -414,7 +414,7 @@ struct kvm_vmx_nested_state_hdr {
>>  	struct {
>>  		__u16 flags;
>>  	} smm;
>> -
>> +	__u16 pad;
>>  	__u32 flags;
>>  	__u64 preemption_timer_deadline;
>>  };
>> -- 
>> 2.25.4
>> 
>

-- 
Vitaly


  reply	other threads:[~2020-07-13 15:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13  8:28 [PATCH] KVM: nVMX: properly pad struct kvm_vmx_nested_state_hdr Vitaly Kuznetsov
2020-07-13 15:17 ` Sean Christopherson
2020-07-13 15:54   ` Vitaly Kuznetsov [this message]
2020-07-27 11:43     ` Paolo Bonzini
2020-07-27 15:46       ` Sean Christopherson
2020-07-27 16:16         ` Paolo Bonzini
2020-07-28 15:59           ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878sfntnoz.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.