linux-kernel - Re: [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <124a59a3-a603-701b-e3bb-61e83d70b20d@intel.com>
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.