linux-kernel - Re: [PATCHv6 07/30] x86/traps: Add #VE support for TDX guest

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]

Date:   Thu, 17 Mar 2022 13:32:07 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>, mingo@...hat.com,
        bp@...en8.de, luto@...nel.org,
        sathyanarayanan.kuppuswamy@...ux.intel.com, aarcange@...hat.com,
        ak@...ux.intel.com, dan.j.williams@...el.com, david@...hat.com,
        hpa@...or.com, jgross@...e.com, jmattson@...gle.com,
        joro@...tes.org, jpoimboe@...hat.com, knsathya@...nel.org,
        pbonzini@...hat.com, sdeep@...are.com, seanjc@...gle.com,
        tony.luck@...el.com, vkuznets@...hat.com, wanpengli@...cent.com,
        thomas.lendacky@....com, brijesh.singh@....com, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCHv6 07/30] x86/traps: Add #VE support for TDX guest

On 3/17/22 13:21, Peter Zijlstra wrote:
> From vague memories #VE can be raised on any memop, loading the stack
> address in the syscall-gap is a memop. What makes that special? Can we
> get a comment _there_ to explain how this is safe such that we can keep
> it so?

#GP and #PF can be raised from any memop too.  But, we know that if we
only touch normal, valid kernel mappings, we don't have to worry about them.

The memop rules to avoid #VE are basically the same, except they also
include "TD-shared" memory.  But, "normal" kernel memory isn't ever
shared because it's under the control of the untrusted hypervisor.  The
kernel trusts shared memory like it trusts userspace-mapped memory.

The kernel would be insane to, for instance, put its stack in
userspace-writable memory.  The same goes for TD-shared memory.

In the end, I'm asserting that we don't really have to be any more
careful to avoid a #VE on a memory access than we are to avoid #GP and #PF.

The TDX rules are *much* nicer than SEV.  They're also a lot nicer on
TDX _now_ than they used to be.  There are a few stubborn people at
Intel who managed to add some drops of sanity to the architecture.