[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d673f082-9023-dafb-e42e-eab32a3ddd0c@intel.com>
Date: Mon, 22 Nov 2021 10:30:17 -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 7:23 AM, Brijesh Singh wrote:
> Thank you for starting the thread; based on the discussion, I am keeping
> the current implementation as-is and *not* going with the auto
> conversion from private to shared. To summarize what we are doing in the
> current SNP series:
>
> - If userspace accesses guest private memory, it gets SIGBUS.
> - If kernel accesses[*] guest private memory, it does panic.
There's a subtlety here, though. There are really three *different*
kinds of kernel accesses that matter:
1. Kernel bugs. Kernel goes off and touches some guest private memory
when it didn't mean to. Say, it runs off the end of a slab page and
runs into a guest page. panic() is expected here.
2. Kernel accesses guest private memory via a userspace mapping, in a
place where it is known to be accessing userspace and is prepared to
fault. copy_to_user() is the most straightforward example. Kernel
must *not* panic(). Returning an error to the syscall is a good
way to handle these (if in a syscall).
3. Kernel accesses guest private memory via a kernel mapping. This one
is tricky. These probably *do* result in a panic() today, but
ideally shouldn't.
Could you explicitly clarify what the current behavior is?
Powered by blists - more mailing lists