linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: "Andersen, John" <john.s.andersen@intel.com>
Cc: corbet@lwn.net, pbonzini@redhat.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
	shuah@kernel.org, sean.j.christopherson@intel.com,
	liran.alon@oracle.com, drjones@redhat.com,
	rick.p.edgecombe@intel.com, kristen@linux.intel.com,
	vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com,
	joro@8bytes.org, mchehab+huawei@kernel.org,
	gregkh@linuxfoundation.org, paulmck@kernel.org,
	pawan.kumar.gupta@linux.intel.com, jgross@suse.com,
	mike.kravetz@oracle.com, oneukum@suse.com, luto@kernel.org,
	peterz@infradead.org, fenghua.yu@intel.com,
	reinette.chatre@intel.com, vineela.tummalapalli@intel.com,
	dave.hansen@linux.intel.com, arjan@linux.intel.com,
	caoj.fnst@cn.fujitsu.com, bhe@redhat.com, nivedita@alum.mit.edu,
	keescook@chromium.org, dan.j.williams@intel.com,
	eric.auger@redhat.com, aaronlewis@google.com, peterx@redhat.com,
	makarandsonare@google.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 4/4] X86: Use KVM CR pin MSRs
Date: Thu, 18 Jun 2020 08:38:06 -0700	[thread overview]
Message-ID: <5706af0c-e426-91bc-4c38-d1203cf1b3b7@intel.com> (raw)
In-Reply-To: <20200618152649.GC23@258ff54ff3c0>

On 6/18/20 8:26 AM, Andersen, John wrote:
> On Thu, Jun 18, 2020 at 07:41:04AM -0700, Dave Hansen wrote:
>> Let's say kexec is config'd off.  This feature is enabled by default and
>> crashes the kernel in early boot.  I have no way to disable this fancy
>> new feature.  Is that what we want?
>>
>> I also think that instead of having to *enable* this explicitly when
>> kexec is present, maybe we should have a "disable_kexec" parameter.  If
>> kexec is configured out or disabled on the command-line, then you can
>> turn CR pinning on.
>>
>> If someone fails to kexec() because of this feature, there's no way in
>> hell they'll ever track down "pv_cr_pin" on the command-line as the
>> cause.  The might have a chance of finding disable_kexec, though.
>>
>> Wouldn't it also be nice to add a single printk() the first time a kexec
>> fails because of this feature being present?
> 
> That sounds like a good plan. I'll change pv_cr_pin to disable_kexec, and add a
> disable_pv_cr_pin option in case it's being on by default via the compile time
> option breaks a users workflow at runtime.
> 
> In this case, I'm assuming we can do away with the kconfig option then.
> 
> Just have it enabled by default. If kexec is present, it's disabled by default,
> unless kexec is disabled, in which case, pinning is enabled unless
> disable_pv_cr_pin is set.

Yes, that sounds good to me.

...
>>> +config PARAVIRT_CR_PIN
>>> +       bool "Paravirtual bit pinning for CR0 and CR4"
>>> +       depends on KVM_GUEST
>>> +       help
>>> +         Select this option to have the virtualised guest request that the
>>> +         hypervisor disallow it from disabling protections set in control
>>> +         registers. The hypervisor will prevent exploits from disabling
>>> +         features such as SMEP, SMAP, UMIP, and WP.
>>
>> I'm confused.  Does this add support for ""Paravirtual bit pinning", or
>> actually tell the guest to request pinning by default?
>>
>> It says "Select this option to have the virtualised guest request...",
>> which makes it sound like it affects the default rather than the
>> availability of the option.
> 
> How about this
> 
> Select this option to request protection of SMEP, SMAP, UMIP, and WP
> control register bits when running paravirtualized under KVM. Protection will
> be active provided the feature is available host side and kexec is disabled via
> kconfig or the command line for the guest requesting protection.

It still isn't very clear to me.

Let's pull the config option out of this patch.  Enable the feature by
default and do the command-line processing in this patch.

If you still think a Kconfig option is helpful, add it in a separate
patch calling out the deficiencies with the boot-time options.

  reply	other threads:[~2020-06-18 15:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-17 19:07 [PATCH 0/4] Paravirtualized Control Register pinning John Andersen
2020-06-17 19:07 ` [PATCH 1/4] X86: Update mmu_cr4_features during feature identification John Andersen
2020-06-18 14:09   ` Dave Hansen
2020-06-17 19:07 ` [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning John Andersen
2020-06-18 14:18   ` Dave Hansen
2020-06-18 14:43     ` Andersen, John
2020-06-18 14:51       ` Dave Hansen
2020-07-07 21:12         ` Sean Christopherson
2020-07-07 21:48           ` Dave Hansen
2020-07-07 21:51             ` Paolo Bonzini
2020-07-09 15:44               ` Andersen, John
2020-07-09 15:56                 ` Dave Hansen
     [not found]                   ` <CALCETrWxt0CHUoonWX1fgbM46ydJPQZhj8Q=G+45EG4wW3wZqQ@mail.gmail.com>
2020-07-09 16:22                     ` Dave Hansen
2020-07-09 23:37                       ` Kees Cook
     [not found]                       ` <CALCETrUHcpqjDfAM9SbrZUM7xcS2wkVm=r1Nb1JmxV7A-KAeUQ@mail.gmail.com>
2020-07-14  5:36                         ` Andersen, John, Arvind Sankar
2020-07-14  5:39                         ` Andersen, John
2020-07-15  4:41                           ` Sean Christopherson
2020-07-15 19:58                             ` Andersen, John
2020-06-17 19:07 ` [PATCH 3/4] selftests: kvm: add test for CR pinning with SMM John Andersen
2020-06-17 19:07 ` [PATCH 4/4] X86: Use KVM CR pin MSRs John Andersen
2020-06-18 14:41   ` Dave Hansen
2020-06-18 15:26     ` Andersen, John
2020-06-18 15:38       ` Dave Hansen [this message]
2020-06-18 15:49         ` Andersen, John
2020-06-20  5:13   ` Andy Lutomirski
2020-06-23 20:03     ` Andersen, John
2020-07-03 21:48       ` Andersen, John
2020-07-04 15:11         ` Arvind Sankar

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=5706af0c-e426-91bc-4c38-d1203cf1b3b7@intel.com \
    --to=dave.hansen@intel.com \
    --cc=aaronlewis@google.com \
    --cc=arjan@linux.intel.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=drjones@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=fenghua.yu@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=jmattson@google.com \
    --cc=john.s.andersen@intel.com \
    --cc=joro@8bytes.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kristen@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --cc=luto@kernel.org \
    --cc=makarandsonare@google.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=nivedita@alum.mit.edu \
    --cc=oneukum@suse.com \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=reinette.chatre@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vineela.tummalapalli@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).