linux-kernel - Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption

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: <6abea873-52a2-f506-b21b-4b567bee1874@intel.com>
Date:   Fri, 6 May 2022 11:14:00 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Boris Petkov <bp@...en8.de>,
        Dan Williams <dan.j.williams@...el.com>
Cc:     Martin Fernandez <martin.fernandez@...ypsium.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux MM <linux-mm@...ck.org>,
        platform-driver-x86@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
        "Schofield, Alison" <alison.schofield@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Andy Shevchenko <andy@...radead.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Mike Rapoport <rppt@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ard Biesheuvel <ardb@...nel.org>, daniel.gutson@...ypsium.com,
        "H. Peter Anvin" <hpa@...or.com>, alex.bazhaniuk@...ypsium.com,
        hughsient@...il.com, Kees Cook <keescook@...omium.org>,
        Darren Hart <dvhart@...radead.org>,
        Ben Widawsky <ben.widawsky@...el.com>,
        "Huang, Kai" <kai.huang@...el.com>
Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do
 encryption

On 5/6/22 10:55, Boris Petkov wrote:
> So here's the deal: we can say in the kernel that memory encryption
> is enabled and active.  But then all those different devices and so
> on,  can or cannot support encryption. IO devices do not support
> encryption either, afaict.

At least on MKTME platforms, if a device does DMA to a physical address
with the KeyID bits set, it gets memory encryption.  That's because all
the encryption magic is done in the memory controller itself.  The CPU's
memory controller doesn't actually care if the access comes from a
device or a CPU as long as the right physical bits are set.

The reason we're talking about this in terms of CXL devices is that CXL
devices have their *OWN* memory controllers.  Those memory controllers
might or might not support encryption.

> But that is not the question - they don't wanna say in fwupd whether
> every transaction was encrypted or not - they wanna say that
> encryption is active. And that we can give them now.

The reason we went down this per-node thing instead of something
system-wide is EFI_MEMORY_CPU_CRYPTO.  It's in the standard because EFI
systems are not expected to have uniform crypto capabilities across the
entire memory map.  Some memory will be capable of CPU crypto and some not.

As an example, if I were to build a system today with TDX and NVDIMMs,
I'd probably mark the RAM as EFI_MEMORY_CPU_CRYPTO=1 and the NVDIMMs as
EFI_MEMORY_CPU_CRYPTO=0.

I think you're saying that current AMD SEV systems have no need for
EFI_MEMORY_CPU_CRYPTO since their encryption capabilities *ARE* uniform.
 I'm not challenging that at all.  This interface is total overkill for
systems with guaranteed uniform encryption capabilities.

But, this interface will *work* both for the uniform and non-uniform
systems alike.