linux-kernel - Re: [RESEND RFC 2/2] X86: Use KVM CR pin MSRs

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: <19f3a3f98d259accf67a6c22c112bfa8f11513d4.camel@intel.com>
Date:   Tue, 24 Dec 2019 21:18:27 +0000
From:   "Andersen, John S" <john.s.andersen@...el.com>
To:     "luto@...nel.org" <luto@...nel.org>
CC:     "jmattson@...gle.com" <jmattson@...gle.com>,
        "joro@...tes.org" <joro@...tes.org>, "bp@...en8.de" <bp@...en8.de>,
        "x86@...nel.org" <x86@...nel.org>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        "wanpengli@...cent.com" <wanpengli@...cent.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND RFC 2/2] X86: Use KVM CR pin MSRs

On Sun, 2019-12-22 at 23:39 -0800, Andy Lutomirski wrote:
> On Fri, Dec 20, 2019 at 11:27 AM John Andersen
> <john.s.andersen@...el.com> wrote:
> > Strengthen existing control register pinning when running
> > paravirtualized under KVM. Check which bits KVM supports pinning
> > for
> > each control register and only pin supported bits which are already
> > pinned via the existing native protection. Write to KVM CR0 and CR4
> > pinned MSRs to enable pinning.
> > 
> > Initiate KVM assisted pinning directly following the setup of
> > native
> > pinning on boot CPU. For non-boot CPUs initiate paravirtualized
> > pinning
> > on CPU identification.
> > 
> > Identification of non-boot CPUs takes place after the boot CPU has
> > setup
> > native CR pinning. Therefore, non-boot CPUs access pinned bits
> > setup by
> > the boot CPU and request that those be pinned. All CPUs request
> > paravirtualized pinning of the same bits which are already pinned
> > natively.
> > 
> > Guests using the kexec system call currently do not support
> > paravirtualized control register pinning. This is due to early boot
> > code writing known good values to control registers, these values
> > do
> > not contain the protected bits. This is due to CPU feature
> > identification being done at a later time, when the kernel properly
> > checks if it can enable protections.
> 
> Is hibernation supported?  How about suspend-to-RAM?
> 

Something is writing to CR4 during resume which is breaking
hibernation. Unfortunately I hadn't been able to get my hibernation
test working before sending this out. I will investigate.

> FWIW, I think that handling these details through Kconfig is the
> wrong
> choice.  Distribution kernels should enable this, and they're not
> going to turn off kexec.  Arguably kexec should be made to work --
> there is no fundamental reason that kexec should need to fiddle with
> CR0.WP, for example.  But a boot option could also work as a
> short-term option.

Given the situation with hibernation. I think I'll implement the kexec
discovery Liran suggested, and then investigate the hibernate situation
further.

Thanks,
John