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