From: Sean Christopherson <seanjc@google.com>
To: Michal Luczaj <mhal@rbox.co>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org, shuah@kernel.org
Subject: Re: [PATCH 1/2] KVM: x86: Fix KVM_CAP_SYNC_REGS's sync_regs() TOCTOU issues
Date: Wed, 2 Aug 2023 12:18:20 -0700 [thread overview]
Message-ID: <ZMqr/A1O4PPbKfFz@google.com> (raw)
In-Reply-To: <7e24e0b1-d265-2ac0-d411-4d6f4f0c1383@rbox.co>
On Tue, Aug 01, 2023, Michal Luczaj wrote:
> On 8/1/23 01:49, Sean Christopherson wrote:
> >> A note: when servicing kvm_run->kvm_dirty_regs, changes made by
> >> __set_sregs()/kvm_vcpu_ioctl_x86_set_vcpu_events() to on-stack copies of
> >> vcpu->run.s.regs will not be reflected back in vcpu->run.s.regs. Is this
> >> ok?
> >
> > I would be amazed if anyone cares. Given the justification and the author,
> >
> > This reduces ioctl overhead which is particularly important when userspace
> > is making synchronous guest state modifications (e.g. when emulating and/or
> > intercepting instructions).
> >
> > Signed-off-by: Ken Hofsass <hofsass@google.com>
> >
> > I am pretty sure this was added to optimize a now-abandoned Google effort to do
> > emulation in uesrspace. I bring that up because I was going to suggest that we
> > might be able to get away with a straight revert, as QEMU doesn't use the flag
> > and AFAICT neither does our VMM, but there are a non-zero number of hits in e.g.
> > github, so sadly I think we're stuck with the feature :-(
>
> All right, so assuming the revert is not happening and the API is not misused
> (i.e. unless vcpu->run->kvm_valid_regs is set, no one is expecting up to date
> values in vcpu->run->s.regs), is assignment copying
>
> struct kvm_vcpu_events events = vcpu->run->s.regs.events;
>
> the right approach or should it be a memcpy(), like in ioctl handlers?
Both approaches are fine, though I am gaining a preference for the copy-by-value
method. With gcc-12 and probably most compilers, the code generation is identical
for both as the compiler generates a call to memcpy() to handle the the struct
assignment.
The advantage of copy-by-value for structs, and why I think I now prefer it, is
that it provides type safety. E.g. this compiles without complaint
memcpy(&events, &vcpu->run->s.regs.sregs, sizeof(events));
whereas this
struct kvm_vcpu_events events = vcpu->run->s.regs.sregs;
yields
arch/x86/kvm/x86.c: In function ‘sync_regs’:
arch/x86/kvm/x86.c:11793:49: error: invalid initializer
11793 | struct kvm_vcpu_events events = vcpu->run->s.regs.sregs;
| ^~~~
The downside is that it's less obvious when reading the code that there is a
large-ish memcpy happening, but IMO it's worth gaining the type safety.
next prev parent reply other threads:[~2023-08-02 19:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 0:12 [PATCH 0/2] sync_regs() TOCTOU issues Michal Luczaj
2023-07-28 0:12 ` [PATCH 1/2] KVM: x86: Fix KVM_CAP_SYNC_REGS's " Michal Luczaj
2023-07-31 23:49 ` Sean Christopherson
2023-08-01 12:37 ` Michal Luczaj
2023-08-02 19:18 ` Sean Christopherson [this message]
2023-08-03 0:13 ` Michal Luczaj
2023-08-03 17:48 ` Paolo Bonzini
2023-08-03 21:15 ` Michal Luczaj
2023-08-04 9:53 ` Paolo Bonzini
2023-08-04 17:50 ` Michal Luczaj
2023-08-14 22:29 ` Michal Luczaj
2023-07-28 0:12 ` [PATCH 2/2] KVM: selftests: Extend x86's sync_regs_test to check for races Michal Luczaj
2023-08-02 21:07 ` Sean Christopherson
2023-08-03 0:44 ` Michal Luczaj
2023-08-03 16:41 ` Sean Christopherson
2023-08-03 21:14 ` Michal Luczaj
2023-08-08 23:11 ` Sean Christopherson
2023-08-02 21:11 ` [PATCH 0/2] sync_regs() TOCTOU issues Sean Christopherson
2023-08-15 0:48 ` Sean Christopherson
2023-08-15 7:37 ` Michal Luczaj
2023-08-15 15:40 ` Sean Christopherson
2023-08-15 17:49 ` Michal Luczaj
2023-08-15 18:15 ` Sean Christopherson
2023-08-15 18:38 ` Michal Luczaj
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=ZMqr/A1O4PPbKfFz@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=mhal@rbox.co \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
/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.