[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38282b0c-7eb5-6a91-df19-2f4cfa8549ce@intel.com>
Date: Mon, 22 Nov 2021 14:51:35 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Brijesh Singh <brijesh.singh@....com>,
Peter Gonda <pgonda@...gle.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-coco@...ts.linux.dev, linux-mm@...ck.org,
linux-crypto@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
Tom Lendacky <Thomas.Lendacky@....com>,
"H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Sergio Lopez <slp@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
David Rientjes <rientjes@...gle.com>,
Dov Murik <dovmurik@...ux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@....com>,
Borislav Petkov <bp@...en8.de>,
Michael Roth <michael.roth@....com>,
Vlastimil Babka <vbabka@...e.cz>,
"Kirill A . Shutemov" <kirill@...temov.name>,
Andi Kleen <ak@...ux.intel.com>, tony.luck@...el.com,
marcorr@...gle.com, sathyanarayanan.kuppuswamy@...ux.intel.com
Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP)
Hypervisor Support
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.
Powered by blists - more mailing lists