linux-kernel - Re: [RFC 02/16] x86/kvm: Introduce KVM memory protection feature

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: <87r1uwflkq.fsf@vitty.brq.redhat.com>
Date:   Wed, 03 Jun 2020 13:14:13 +0200
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     "Huang\, Kai" <kai.huang@...el.com>
Cc:     "kvm\@vger.kernel.org" <kvm@...r.kernel.org>,
        "wad\@chromium.org" <wad@...omium.org>,
        "Kleen\, Andi" <andi.kleen@...el.com>,
        "luto\@kernel.org" <luto@...nel.org>,
        "aarcange\@redhat.com" <aarcange@...hat.com>,
        "keescook\@chromium.org" <keescook@...omium.org>,
        "dave.hansen\@linux.intel.com" <dave.hansen@...ux.intel.com>,
        "wanpengli\@tencent.com" <wanpengli@...cent.com>,
        "kirill.shutemov\@linux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "pbonzini\@redhat.com" <pbonzini@...hat.com>,
        "linux-mm\@kvack.org" <linux-mm@...ck.org>,
        "joro\@8bytes.org" <joro@...tes.org>,
        "peterz\@infradead.org" <peterz@...radead.org>,
        "jmattson\@google.com" <jmattson@...gle.com>,
        "Edgecombe\, Rick P" <rick.p.edgecombe@...el.com>,
        "rientjes\@google.com" <rientjes@...gle.com>,
        "x86\@kernel.org" <x86@...nel.org>,
        "kirill\@shutemov.name" <kirill@...temov.name>,
        "Christopherson\, Sean J" <sean.j.christopherson@...el.com>
Subject: Re: [RFC 02/16] x86/kvm: Introduce KVM memory protection feature

"Huang, Kai" <kai.huang@...el.com> writes:

> On Wed, 2020-05-27 at 10:39 +0200, Vitaly Kuznetsov wrote:
>> Sean Christopherson <sean.j.christopherson@...el.com> writes:
>> 
>> > On Mon, May 25, 2020 at 06:15:25PM +0300, Kirill A. Shutemov wrote:
>> > > On Mon, May 25, 2020 at 04:58:51PM +0200, Vitaly Kuznetsov wrote:
>> > > > > @@ -727,6 +734,15 @@ static void __init kvm_init_platform(void)
>> > > > >  {
>> > > > >  	kvmclock_init();
>> > > > >  	x86_platform.apic_post_init = kvm_apic_init;
>> > > > > +
>> > > > > +	if (kvm_para_has_feature(KVM_FEATURE_MEM_PROTECTED)) {
>> > > > > +		if (kvm_hypercall0(KVM_HC_ENABLE_MEM_PROTECTED)) {
>> > > > > +			pr_err("Failed to enable KVM memory
>> > > > > protection\n");
>> > > > > +			return;
>> > > > > +		}
>> > > > > +
>> > > > > +		mem_protected = true;
>> > > > > +	}
>> > > > >  }
>> > > > 
>> > > > Personally, I'd prefer to do this via setting a bit in a KVM-specific
>> > > > MSR instead. The benefit is that the guest doesn't need to remember if
>> > > > it enabled the feature or not, it can always read the config msr. May
>> > > > come handy for e.g. kexec/kdump.
>> > > 
>> > > I think we would need to remember it anyway. Accessing MSR is somewhat
>> > > expensive. But, okay, I can rework it MSR if needed.
>> > 
>> > I think Vitaly is talking about the case where the kernel can't easily get
>> > at its cached state, e.g. after booting into a new kernel.  The kernel would
>> > still have an X86_FEATURE bit or whatever, providing a virtual MSR would be
>> > purely for rare slow paths.
>> > 
>> > That being said, a hypercall plus CPUID bit might be better, e.g. that'd
>> > allow the guest to query the state without risking a #GP.
>> 
>> We have rdmsr_safe() for that! :-) MSR (and hypercall to that matter)
>> should have an associated CPUID feature bit of course.
>> 
>> Yes, hypercall + CPUID would do but normally we treat CPUID data as
>> static and in this case we'll make it a dynamically flipping
>> bit. Especially if we introduce 'KVM_HC_DISABLE_MEM_PROTECTED' later.
>
> Not sure why is KVM_HC_DISABLE_MEM_PROTECTED needed?
>

I didn't put much thought in it but we may need it to support 'kexec'
case when no reboot is performed but we either need to pass  the data
about which regions are protected from old kernel to the new one or
'unprotect exerything'.

-- 
Vitaly