On Fri, Dec 20, 2019 at 11:27 AM John Andersen <john.s.andersen@xxxxxxxxx> 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.
