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]

Date:   Sun, 22 Dec 2019 23:39:19 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     John Andersen <john.s.andersen@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        X86 ML <x86@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kvm list <kvm@...r.kernel.org>
Subject: Re: [RESEND RFC 2/2] X86: Use KVM CR pin MSRs

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?

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.