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: <CE52D65A-C9F4-408D-B18A-72D87495A433@alien8.de>
Date:   Fri, 06 May 2022 19:02:03 +0000
From:   Boris Petkov <bp@...en8.de>
To:     Dave Hansen <dave.hansen@...el.com>,
        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>,
        platform-driver-x86@...r.kernel.org, Linux MM <linux-mm@...ck.org>,
        "H. Peter Anvin" <hpa@...or.com>, daniel.gutson@...ypsium.com,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>, X86 ML <x86@...nel.org>,
        "Schofield, Alison" <alison.schofield@...el.com>,
        hughsient@...il.com, alex.bazhaniuk@...ypsium.com,
        Greg KH <gregkh@...uxfoundation.org>,
        Mike Rapoport <rppt@...nel.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 May 6, 2022 6:43:39 PM UTC, Dave Hansen <dave.hansen@...el.com> wrote:
>On 5/6/22 11:25, Boris Petkov wrote:
>> On May 6, 2022 6:14:00 PM UTC, Dave Hansen <dave.hansen@...el.com>
>> wrote:
>>> But, this interface will *work* both for the uniform and
>>> non-uniform systems alike.
>> And what would that additional information that some "node" -
>> whatever "node" means nowadays - is not encrypted give you?
>
>Tying it to the node ties it to the NUMA ABIs.  For instance, it lets
>you say: "allocate memory with encryption capabilities" with a
>set_mempolicy() to nodes that are enumerated as encryption-capable.

I was expecting something along those lines...

>Imagine that we have a non-uniform system: some memory supports TDX (or
>SEV-SNP) and some doesn't.  QEMU calls mmap() to allocate some guest
>memory and then its ioctl()s to get its addresses stuffed into EPT/NPT.
> The memory might be allocated from anywhere, CPU_CRYPTO-capable or not.
> VM creation will fail because the (hardware-enforced) security checks
>can't be satisfied on non-CPU_CRYPTO memory.
>
>Userspace has no recourse to fix this.  It's just stuck.  In that case,
> the *kernel* needs to be responsible for ensuring that the backing
>physical memory supports TDX (or SEV).
>
>This node attribute punts the problem back out to userspace.  It gives
>userspace the ability to steer allocations to compatible NUMA nodes.  If
>something goes wrong, they can use other NUMA ABIs to inspect the
>situation, like /proc/$pid/numa_maps.

That's all fine and dandy but I still don't see the *actual*, real-life use case of why something would request memory of particular encryption capabilities. Don't get me wrong  - I'm not saying there are not such use cases - I'm saying we should go all the way and fully define properly  *why* we're doing this whole hoopla.

Remember - this all started with "i wanna say that mem enc is active" and now we're so far deep down the rabbit hole...

-- 
Sent from a small device: formatting sux and brevity is inevitable.