Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: ie3994620:Fastmail
Date:   Wed, 17 May 2023 00:52:10 +0300
From:   "Kirill A. Shutemov" <kirill@shutemov.name>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        "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
Message-ID: <20230516215210.pviqojbr5o4hd6bb@box.shutemov.name>
References: <20230513220418.19357-1-kirill.shutemov@linux.intel.com>
 <20230513220418.19357-7-kirill.shutemov@linux.intel.com>
 <CAMj1kXG488uW=dpvbfvdN1fMZVJ3kCZQoW3UVQJW1F2VEXyxHg@mail.gmail.com>
 <6fe42f66-819c-f2c8-176b-759c1c5a9cf5@intel.com>
 <CAMj1kXHE7_PrW44Y073=4orY6yVST+CHEA7KCo_0z_uRLew6fQ@mail.gmail.com>
 <a7550521-65bf-f9af-ddb0-118602a6340c@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a7550521-65bf-f9af-ddb0-118602a6340c@intel.com>
Precedence: bulk

On Tue, May 16, 2023 at 01:03:32PM -0700, Dave Hansen wrote:
> On 5/16/23 11:35, Ard Biesheuvel wrote:
> >>> 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?
> 
> I don't know of anywhere that this is explicitly written.  It's probably
> implicit _somewhere_ in the reams of VMX/TDX and base SDM docs, but heck
> if I know where it is. :)

It is not specific to TDX: on x86 (and all architectures with precise
exceptions) exception handling is delayed until instruction retirement and
will not happen if speculation turned out to be wrong. And prefetching
never generates exceptions.

But I failed to find right away in 5000+ pages of Intel Software
Developer’s Manual. :/

-- 
  Kiryl Shutsemau / Kirill A. Shutemov