On 11/22/21 12:33 PM, Brijesh Singh wrote:

quoted

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.