All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Mattson <jmattson@google.com>
To: Alexander Graf <graf@amazon.com>
Cc: Aaron Lewis <aaronlewis@google.com>,
	Peter Shier <pshier@google.com>, Oliver Upton <oupton@google.com>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [PATCH v3 05/12] KVM: x86: Add support for exiting to userspace on rdmsr or wrmsr
Date: Fri, 21 Aug 2020 10:58:32 -0700	[thread overview]
Message-ID: <CALMp9eTUV9Z7hL_qtdKYvqYmm8wT1_oGaRLp55i3ttg1qLyecQ@mail.gmail.com> (raw)
In-Reply-To: <CALMp9eSXS+b62C-kXjwPBeYF36ajYeGg2kBmsubz9s5V6C-83A@mail.gmail.com>

On Thu, Aug 20, 2020 at 3:55 PM Jim Mattson <jmattson@google.com> wrote:
>
> On Thu, Aug 20, 2020 at 2:59 PM Alexander Graf <graf@amazon.com> wrote:
>
> > Do we really need to do all of this dance of differentiating in kernel
> > space between an exit that's there because user space asked for the exit
> > and an MSR access that would just generate a #GP?
> >
> > At the end of the day, user space *knows* which MSRs it asked to
> > receive. It can filter for them super easily.
>
> If no one else has an opinion, I can let this go. :-)
>
> However, to make the right decision in kvm_emulate_{rdmsr,wrmsr}
> (without the unfortunate before and after checks that Aaron added),
> kvm_{get,set}_msr should at least distinguish between "permission
> denied" and "raise #GP," so I can provide a deny list without asking
> for userspace exits on #GP.

Actually, I think this whole discussion is moot. You no longer need
the first ioctl (ask for a userspace exit on #GP). The allow/deny list
is sufficient. Moreover, the allow/deny list checks can be in
kvm_emulate_{rdmsr,wrmsr} before the call to kvm_{get,set}_msr, so we
needn't be concerned with distinguishable error values either.

  reply	other threads:[~2020-08-21 17:58 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18 21:15 [PATCH v3 00/12] Allow userspace to manage MSRs Aaron Lewis
2020-08-18 21:15 ` [PATCH v3 01/12] KVM: x86: Deflect unknown MSR accesses to user space Aaron Lewis
2020-08-19  8:42   ` Alexander Graf
2020-08-18 21:15 ` [PATCH v3 02/12] KVM: x86: Introduce allow list for MSR emulation Aaron Lewis
2020-08-19  8:53   ` Alexander Graf
2020-08-31 10:39   ` Dan Carpenter
2020-08-31 10:39     ` Dan Carpenter
2020-08-31 10:39     ` Dan Carpenter
2020-09-01 19:13     ` Alexander Graf
2020-09-02  7:31       ` Dan Carpenter
2020-09-02  7:31         ` Dan Carpenter
2020-09-02  7:31         ` Dan Carpenter
2020-08-18 21:15 ` [PATCH v3 03/12] KVM: selftests: Add test for user space MSR handling Aaron Lewis
2020-08-18 21:15 ` [PATCH v3 04/12] KVM: x86: Add ioctl for accepting a userspace provided MSR list Aaron Lewis
2020-08-19  9:00   ` Alexander Graf
2020-08-20 17:30     ` Jim Mattson
2020-08-20 21:49       ` Alexander Graf
2020-08-20 22:28         ` Jim Mattson
2020-08-18 21:15 ` [PATCH v3 05/12] KVM: x86: Add support for exiting to userspace on rdmsr or wrmsr Aaron Lewis
2020-08-19 10:25   ` Alexander Graf
2020-08-20 18:17   ` Jim Mattson
2020-08-20 21:59     ` Alexander Graf
2020-08-20 22:55       ` Jim Mattson
2020-08-21 17:58         ` Jim Mattson [this message]
2020-08-24  1:35           ` Alexander Graf
2020-08-24 17:23             ` Jim Mattson
2020-08-24 18:09               ` Alexander Graf
2020-08-24 18:34                 ` Jim Mattson
2020-08-18 21:15 ` [PATCH v3 06/12] KVM: x86: Prepare MSR bitmaps for userspace tracked MSRs Aaron Lewis
2020-08-18 21:15 ` [PATCH v3 07/12] KVM: x86: Ensure the MSR bitmap never clears " Aaron Lewis
2020-08-19  1:12   ` kernel test robot
2020-08-19  1:12     ` kernel test robot
2020-08-19  1:12   ` [RFC PATCH] KVM: x86: vmx_set_user_msr_intercept() can be static kernel test robot
2020-08-19  1:12     ` kernel test robot
2020-08-19 15:26   ` [PATCH v3 07/12] KVM: x86: Ensure the MSR bitmap never clears userspace tracked MSRs Alexander Graf
2020-08-20  0:18     ` Aaron Lewis
2020-08-20 22:04       ` Alexander Graf
2020-08-20 22:35         ` Jim Mattson
2020-08-21 14:27           ` Aaron Lewis
2020-08-21 16:07             ` Alexander Graf
2020-08-21 16:43               ` Aaron Lewis
2020-08-26 15:48   ` kernel test robot
2020-08-26 15:48     ` kernel test robot
2020-08-18 21:15 ` [PATCH v3 08/12] selftests: kvm: Fix the segment descriptor layout to match the actual layout Aaron Lewis
2020-08-18 21:15 ` [PATCH v3 09/12] selftests: kvm: Clear uc so UCALL_NONE is being properly reported Aaron Lewis
2020-08-19  9:13   ` Andrew Jones
2020-08-18 21:15 ` [PATCH v3 10/12] selftests: kvm: Add exception handling to selftests Aaron Lewis
2020-08-18 21:15 ` [PATCH v3 11/12] selftests: kvm: Add a test to exercise the userspace MSR list Aaron Lewis
2020-08-18 21:15 ` [PATCH v3 12/12] selftests: kvm: Add emulated rdmsr, wrmsr tests Aaron Lewis

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=CALMp9eTUV9Z7hL_qtdKYvqYmm8wT1_oGaRLp55i3ttg1qLyecQ@mail.gmail.com \
    --to=jmattson@google.com \
    --cc=aaronlewis@google.com \
    --cc=graf@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=oupton@google.com \
    --cc=pshier@google.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.