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. >
