linux-kernel - Re: [RFCv2 06/13] x86/realmode: Share trampoline area if KVM memory protection enabled

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:   Mon, 19 Apr 2021 09:49:16 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Sean Christopherson <seanjc@...gle.com>,
        Jim Mattson <jmattson@...gle.com>
Cc:     David Rientjes <rientjes@...gle.com>,
        "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "Kleen, Andi" <andi.kleen@...el.com>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        Erdem Aktas <erdemaktas@...gle.com>,
        Steve Rutherford <srutherford@...gle.com>,
        Peter Gonda <pgonda@...gle.com>,
        David Hildenbrand <david@...hat.com>, x86@...nel.org,
        kvm@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFCv2 06/13] x86/realmode: Share trampoline area if KVM memory
 protection enabled

On 4/16/21 8:40 AM, Kirill A. Shutemov wrote:
>  	/*
> -	 * If SME is active, the trampoline area will need to be in
> -	 * decrypted memory in order to bring up other processors
> +	 * If SME or KVM memory protection is active, the trampoline area will
> +	 * need to be in decrypted memory in order to bring up other processors
>  	 * successfully. This is not needed for SEV.
>  	 */
> -	if (sme_active())
> +	if (sme_active() || kvm_mem_protected())
>  		set_memory_decrypted((unsigned long)base, size >> PAGE_SHIFT);

Could you take a look at all the places you've added these:

	if (foo() || kvm_mem_protected())
		bar();

spots and see if some refactoring is in order?

I suspect that some thought about what the high-level commonalities are,
plus some thoughtful helper function names would go a long way to making
this whole thing understandable.


set_memory_decrypted() as a name needs to go.  It almost needs to be
something like:

	set_memory_sharing()

or something.  The "sharing" would be between the kernel and devices
(for SME), or the guest kernel and host kernel for protected memory.