linux-kernel - Re: [PATCH v1 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <89236DB3-7B03-4B11-9F5B-5D820289C544@amacapital.net>
Date:   Fri, 26 Mar 2021 19:40:33 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Raj Ashok <ashok.raj@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD



> On Mar 26, 2021, at 5:18 PM, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com> wrote:
> 
> In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
> are not supported. So handle #VE due to these instructions as no ops.

These should at least be WARN.

Does TDX send #UD if these instructions have the wrong CPL?  If the #VE came from user mode, we should send an appropriate signal instead.

> 
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
> Reviewed-by: Andi Kleen <ak@...ux.intel.com>
> ---
> 
> Changes since previous series:
> * Suppressed MWAIT feature as per Andi's comment.
> * Added warning debug log for MWAIT #VE exception.
> 
> arch/x86/kernel/tdx.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> 
> diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
> index e936b2f88bf6..fb7d22b846fc 100644
> --- a/arch/x86/kernel/tdx.c
> +++ b/arch/x86/kernel/tdx.c
> @@ -308,6 +308,9 @@ void __init tdx_early_init(void)
> 
>    setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
> 
> +    /* MWAIT is not supported in TDX platform, so suppress it */
> +    setup_clear_cpu_cap(X86_FEATURE_MWAIT);
> +
>    tdg_get_info();
> 
>    pv_ops.irq.safe_halt = tdg_safe_halt;
> @@ -362,6 +365,26 @@ int tdg_handle_virtualization_exception(struct pt_regs *regs,
>    case EXIT_REASON_EPT_VIOLATION:
>        ve->instr_len = tdg_handle_mmio(regs, ve);
>        break;
> +    /*
> +     * Per Guest-Host-Communication Interface (GHCI) for Intel Trust
> +     * Domain Extensions (Intel TDX) specification, sec 2.4,
> +     * some instructions that unconditionally cause #VE (such as WBINVD,
> +     * MONITOR, MWAIT) do not have corresponding TDCALL
> +     * [TDG.VP.VMCALL <Instruction>] leaves, since the TD has been designed
> +     * with no deterministic way to confirm the result of those operations
> +     * performed by the host VMM.  In those cases, the goal is for the TD
> +     * #VE handler to increment the RIP appropriately based on the VE
> +     * information provided via TDCALL.
> +     */
> +    case EXIT_REASON_WBINVD:
> +        pr_warn_once("WBINVD #VE Exception\n");
> +    case EXIT_REASON_MONITOR_INSTRUCTION:
> +        /* Handle as nops. */
> +        break;
> +    case EXIT_REASON_MWAIT_INSTRUCTION:
> +        /* MWAIT is supressed, not supposed to reach here. */
> +        pr_warn("MWAIT unexpected #VE Exception\n");
> +        return -EFAULT;
>    default:
>        pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
>        return -EFAULT;
> -- 
> 2.25.1
>