linux-kernel - Re: [RFC v2 28/32] x86/tdx: Make pages shared in ioremap()

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:   Thu, 20 May 2021 13:12:58 -0700
From:   "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>
To:     Borislav Petkov <bp@...en8.de>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Raj Ashok <ashok.raj@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 28/32] x86/tdx: Make pages shared in ioremap()



On 5/11/21 2:35 AM, Borislav Petkov wrote:
> Preach brother!:)
> 
> /me goes and greps mailboxes...
> 
> ah, do you mean this, per chance:
> 
> https://lore.kernel.org/kvm/20210421144402.GB5004@zn.tnic/
> 
> ?
> 
> And yes, this has "sev" in the name and dhansen makes sense to me in
> wishing to unify all the protected guest feature queries under a common
> name. And then depending on the vendor, that common name will call the
> respective vendor's helper to answer the protected guest aspect asked
> about.
> 
> This way, generic code will call
> 
> 	protected_guest_has()
> 
> or so and be nicely abstracted away from the underlying implementation.
> 
> Hohumm, yap, sounds nice to me.
> 
> Thx.

I see many variants of SEV/SME related checks in the common code path
between TDX and SEV/SME. Can a generic call like
protected_guest_has(MEMORY_ENCRYPTION) or is_protected_guest()
replace all these variants?

We will not be able to test AMD related features. So I need to confirm
it with AMD code maintainers/developers before making this change.

arch/x86/include/asm/io.h:313:	if (sev_key_active() || is_tdx_guest()) {			\
arch/x86/include/asm/io.h:329:	if (sev_key_active() || is_tdx_guest()) {			\
arch/x86/kernel/pci-swiotlb.c:52:	if (sme_active() || is_tdx_guest())
arch/x86/mm/ioremap.c:96:	if (!sev_active() && !is_tdx_guest())
arch/x86/mm/pat/set_memory.c:1984:	if (!mem_encrypt_active() && !is_tdx_guest())

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer