[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Jun 2020 07:51:10 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Andersen, John" <john.s.andersen@...el.com>
Cc: corbet@....net, pbonzini@...hat.com, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com,
shuah@...nel.org, sean.j.christopherson@...el.com, 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 6/18/20 7:43 AM, Andersen, John wrote:
> On Thu, Jun 18, 2020 at 07:18:09AM -0700, Dave Hansen wrote:
>> On 6/17/20 12:07 PM, John Andersen wrote:
>>> +#define KVM_CR0_PIN_ALLOWED (X86_CR0_WP)
>>> +#define KVM_CR4_PIN_ALLOWED (X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP)
>>
>> Why *is* there an allowed set? Why don't we just allow everything?
>>
>> Shouldn't we also pin any unknown bits? The CR4.FSGSBASE bit is an
>> example of something that showed up CPUs without Linux knowing about it.
>> If set, it causes problems. This set couldn't have helped FSGSBASE
>> because it is not in the allowed set.
>>
>> 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.
>
> The allowed set came about because there were comments from internal review
> where it was said that allowing the guest to pin TS and MP adds unnecessary
> complexity.
That would have been a great design point to include in the changelog.
Could you make sure it shows up in future versions.
> Also because KVM always intercepts these bits via the CR0/4_GUEST_HOST_MASK. If
> we allow setting of any bits, then we have to add some infrastructure for
> modifying the mask when pinned bits are updated. I have a patch for that if we
> want to go that route, but it doesn't account for the added complexity
> mentioned above.
Well, we have a current, known issue (FSGSBASE) which shows how dealing
with guest-unknown bits is required. To me, that overrules complexity
arguments to a large degree.
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.
