On May 6, 2022 6:43:39 PM UTC, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >On 5/6/22 11:25, Boris Petkov wrote: >> On May 6, 2022 6:14:00 PM UTC, Dave Hansen <dave.hansen@xxxxxxxxx> >> 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.
