[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31eb5b00-9e2a-aa10-0f20-4abc3cd35112@redhat.com>
Date: Tue, 7 Jul 2020 23:51:54 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Dave Hansen <dave.hansen@...el.com>,
Sean Christopherson <sean.j.christopherson@...el.com>
Cc: "Andersen, John" <john.s.andersen@...el.com>, corbet@....net,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
hpa@...or.com, shuah@...nel.org, liran.alon@...cle.com, drjones@...hat.com,
rick.p.edgecombe@...el.com, kristen@...ux.intel.com, vkuznets@...hat.com,
wanpengli@...cent.com, jmattson@...gle.com, joro@...tes.org,
mchehab+huawei@...nel.org, gregkh@...uxfoundation.org, paulmck@...nel.org,
pawan.kumar.gupta@...ux.intel.com, jgross@...e.com, mike.kravetz@...cle.com,
oneukum@...e.com, luto@...nel.org, peterz@...radead.org,
fenghua.yu@...el.com, reinette.chatre@...el.com,
vineela.tummalapalli@...el.com, dave.hansen@...ux.intel.com,
arjan@...ux.intel.com, caoj.fnst@...fujitsu.com, bhe@...hat.com,
nivedita@...m.mit.edu, keescook@...omium.org, dan.j.williams@...el.com,
eric.auger@...hat.com, aaronlewis@...gle.com, peterx@...hat.com,
makarandsonare@...gle.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-kselftest@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning
On 07/07/20 23:48, Dave Hansen wrote:
> On 7/7/20 2:12 PM, Sean Christopherson wrote:
>>>>> Let's say Intel loses its marbles and adds a CR4 bit that lets userspace
>>>>> write to kernel memory. Linux won't set it, but an attacker would go
>>>>> after it, first thing.
>> That's an orthogonal to pinning. KVM never lets the guest set CR4 bits that
>> are unknown to KVM. Supporting CR4.NO_MARBLES would require an explicit KVM
>> change to allow it to be set by the guest, and would also require a userspace
>> VMM to expose NO_MARBLES to the guest.
>>
>> That being said, this series should supporting pinning as much as possible,
>> i.e. if the bit can be exposed to the guest and doesn't require special
>> handling in KVM, allow it to be pinned. E.g. TS is a special case because
>> pinning would require additional emulator support and IMO isn't interesting
>> enough to justify the extra complexity. At a glance, I don't see anything
>> that would prevent pinning FSGSBASE.
>
> Thanks for filling in the KVM picture.
>
> If we're supporting as much pinning as possible, can we also add
> something to make it inconvenient for someone to both make a CR4 bit
> known to KVM *and* ignore the pinning aspects?
>
> We should really make folks think about it. Something like:
>
> #define KVM_CR4_KNOWN 0xff
> #define KVM_CR4_PIN_ALLOWED 0xf0
> #define KVM_CR4_PIN_NOT_ALLOWED 0x0f
>
> BUILD_BUG_ON(KVM_CR4_KNOWN !=
> (KVM_CR4_PIN_ALLOWED|KVM_CR4_PIN_NOT_ALLOWED));
>
> So someone *MUST* make an active declaration about new bits being pinned
> or not?
I would just make all unknown bits pinnable (or perhaps all CR4 bits in
general).
Paolo
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
