Messages in this thread | | | Date | Tue, 23 Nov 2021 09:55:07 +0100 | Subject | Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support | From | Vlastimil Babka <> |
| |
On 11/22/21 23:51, Dave Hansen wrote: > On 11/22/21 12:33 PM, Brijesh Singh wrote: >>> How do we, for example, prevent ptrace() from inducing a panic()? >> >> In the current approach, this access will induce a panic(). > > That needs to get fixed before SEV-SNP is merged, IMNHO. This behavior > would effectively mean that any userspace given access to create SNP > guests would panic the kernel. > >> In general, supporting the ptrace() for the encrypted VM region is >> going to be difficult. > > By "supporting", do you mean doing something functional? I don't really > care if ptrace() to guest private memory returns -EINVAL or whatever. > The most important thing is not crashing the host. > > Also, as Sean mentioned, this isn't really about ptrace() itself. It's > really about ensuring that no kernel or devices accesses to guest > private memory can induce bad behavior.
Then we need gup to block any changes from shared to guest private? I assume there will be the usual issues of recognizing temporary elevated refcount vs long-term gup, etc.
>> The upcoming TDX work to unmap the guest memory region from the >> current process page table can easily extend for the SNP to cover the >> current limitations.
By "current process page table" you mean userspace page tables?
> My preference would be that we never have SEV-SNP code in the kernel > that can panic() the host from guest userspace. If that means waiting > until there's common guest unmapping infrastructure around, then I think > we should wait. >
| |