lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7b2e758-625a-aafd-d545-bfa6eae513bb@intel.com>
Date:   Tue, 16 May 2023 14:59:56 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Sean Christopherson <seanjc@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Joerg Roedel <jroedel@...e.de>,
        Andi Kleen <ak@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Tom Lendacky <thomas.lendacky@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        Dario Faggioli <dfaggioli@...e.com>,
        Mike Rapoport <rppt@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        marcelo.cerri@...onical.com, tim.gardner@...onical.com,
        khalid.elmously@...onical.com, philip.cox@...onical.com,
        aarcange@...hat.com, peterx@...hat.com, x86@...nel.org,
        linux-mm@...ck.org, linux-coco@...ts.linux.dev,
        linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCHv11 6/9] efi/unaccepted: Avoid load_unaligned_zeropad()
 stepping into unaccepted memory

On 5/16/23 14:52, Kirill A. Shutemov wrote:
> 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.

Not to be Debbie Downer too much here, but it's *totally* possible for
speculative execution to go read memory that causes you to machine
check.  We've had such bugs in Linux.

We just happen to be lucky in this case that the unaccepted memory
exceptions don't generate machine checks *AND* TDX hardware does not
machine check on speculative accesses that would _just_ violate TDX
security properties.

You're right for normal, sane exceptions, though.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ