Messages in this thread | | | Date | Fri, 06 May 2022 19:02:03 +0000 | From | Boris Petkov <> | Subject | Re: [PATCH v8 0/8] x86: Show in sysfs i f a memory node is able to do encryption |
| |
On May 6, 2022 6:43:39 PM UTC, Dave Hansen <dave.hansen@intel.com> wrote: >On 5/6/22 11:25, Boris Petkov wrote: >> On May 6, 2022 6:14:00 PM UTC, Dave Hansen <dave.hansen@intel.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.
| |