From: Ard Biesheuvel <ardb@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
Sean Christopherson <seanjc@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Joerg Roedel <jroedel@suse.de>, Andi Kleen <ak@linux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Tom Lendacky <thomas.lendacky@amd.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Dario Faggioli <dfaggioli@suse.com>,
Mike Rapoport <rppt@kernel.org>,
David Hildenbrand <david@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>,
marcelo.cerri@canonical.com, tim.gardner@canonical.com,
khalid.elmously@canonical.com, philip.cox@canonical.com,
aarcange@redhat.com, peterx@redhat.com, x86@kernel.org,
linux-mm@kvack.org, linux-coco@lists.linux.dev,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCHv11 6/9] efi/unaccepted: Avoid load_unaligned_zeropad() stepping into unaccepted memory
Date: Tue, 16 May 2023 20:35:27 +0200 [thread overview]
Message-ID: <CAMj1kXHE7_PrW44Y073=4orY6yVST+CHEA7KCo_0z_uRLew6fQ@mail.gmail.com> (raw)
In-Reply-To: <6fe42f66-819c-f2c8-176b-759c1c5a9cf5@intel.com>
On Tue, 16 May 2023 at 20:27, Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 5/16/23 11:08, Ard Biesheuvel wrote:
> >> But, this approach does not work for unaccepted memory. For TDX, a load
> >> from unaccepted memory will not lead to a recoverable exception within
> >> the guest. The guest will exit to the VMM where the only recourse is to
> >> terminate the guest.
> >>
> > Does this mean that the kernel maps memory before accepting it? As
> > otherwise, I would assume that such an access would page fault inside
> > the guest before triggering an exception related to the unaccepted
> > state.
>
> Yes, the kernel maps memory before accepting it (modulo things like
> DEBUG_PAGEALLOC).
>
OK, and so the architecture stipulates that prefetching or other
speculative accesses must never deliver exceptions to the host
regarding such ranges?
If this all works as it should, then I'm ok with leaving this here,
but I imagine we may want to factor out some arch specific policy here
in the future, as I don't think this would work the same on ARM.
next prev parent reply other threads:[~2023-05-16 18:35 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-13 22:04 [PATCHv11 0/9] mm, x86/cc, efi: Implement support for " Kirill A. Shutemov
2023-05-13 22:04 ` [PATCHv11 1/9] mm: Add " Kirill A. Shutemov
2023-05-16 19:44 ` Tom Lendacky
2023-05-16 21:32 ` Kirill A. Shutemov
2023-05-13 22:04 ` [PATCHv11 2/9] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
2023-05-16 19:52 ` Tom Lendacky
2023-05-13 22:04 ` [PATCHv11 3/9] efi/libstub: Implement support for unaccepted memory Kirill A. Shutemov
2023-05-14 5:08 ` Mika Penttilä
2023-05-14 21:13 ` Kirill A. Shutemov
2023-05-16 18:01 ` Ard Biesheuvel
2023-05-16 18:06 ` Ard Biesheuvel
2023-05-13 22:04 ` [PATCHv11 4/9] x86/boot/compressed: Handle " Kirill A. Shutemov
2023-05-16 17:09 ` Liam Merwick
2023-05-17 15:52 ` Tom Lendacky
2023-05-13 22:04 ` [PATCHv11 5/9] efi: Provide helpers for " Kirill A. Shutemov
2023-05-16 12:06 ` [PATCHv11.1 5/9] efi: Add unaccepted memory support Kirill A. Shutemov
2023-05-16 17:25 ` Ard Biesheuvel
2023-05-17 15:58 ` Tom Lendacky
2023-05-13 22:04 ` [PATCHv11 6/9] efi/unaccepted: Avoid load_unaligned_zeropad() stepping into unaccepted memory Kirill A. Shutemov
2023-05-16 18:08 ` Ard Biesheuvel
2023-05-16 18:27 ` Dave Hansen
2023-05-16 18:35 ` Ard Biesheuvel [this message]
2023-05-16 19:15 ` Kirill A. Shutemov
2023-05-16 20:03 ` Dave Hansen
2023-05-16 21:52 ` Kirill A. Shutemov
2023-05-16 21:59 ` Dave Hansen
2023-05-16 22:15 ` Ard Biesheuvel
2023-05-16 18:33 ` Kirill A. Shutemov
2023-05-16 23:04 ` Dave Hansen
2023-05-17 16:07 ` Tom Lendacky
2023-05-13 22:04 ` [PATCHv11 7/9] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
2023-05-13 22:04 ` [PATCHv11 8/9] x86/tdx: Refactor try_accept_one() Kirill A. Shutemov
2023-05-13 22:04 ` [PATCHv11 9/9] x86/tdx: Add unaccepted memory support Kirill A. Shutemov
2023-05-16 22:41 ` [PATCHv11 0/9] mm, x86/cc, efi: Implement support for unaccepted memory Tom Lendacky
2023-05-16 23:22 ` Kirill A. Shutemov
2023-05-17 14:32 ` Tom Lendacky
2023-05-17 18:36 ` Kirill A. Shutemov
2023-05-17 18:50 ` Tom Lendacky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMj1kXHE7_PrW44Y073=4orY6yVST+CHEA7KCo_0z_uRLew6fQ@mail.gmail.com' \
--to=ardb@kernel.org \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dfaggioli@suse.com \
--cc=jroedel@suse.de \
--cc=khalid.elmously@canonical.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=marcelo.cerri@canonical.com \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=philip.cox@canonical.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tim.gardner@canonical.com \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox