linux-kernel - Re: [PATCHv4 09/30] x86/tdx: Add MSR support for TDX guests

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: <20220226213528.tt5uchvmvo67w4tb@black.fi.intel.com>
Date:   Sun, 27 Feb 2022 00:35:28 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        luto@...nel.org, peterz@...radead.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
Subject: Re: [PATCHv4 09/30] x86/tdx: Add MSR support for TDX guests

On Thu, Feb 24, 2022 at 10:52:23AM -0800, Dave Hansen wrote:
> On 2/24/22 07:56, Kirill A. Shutemov wrote:
> > Use hypercall to emulate MSR read/write for the TDX platform.
> > 
> > There are two viable approaches for doing MSRs in a TD guest:
> > 
> > 1. Execute the RDMSR/WRMSR instructions like most VMs and bare metal
> >    do. Some will succeed, others will cause a #VE. All of those that
> >    cause a #VE will be handled with a TDCALL.
> > 2. Use paravirt infrastructure.  The paravirt hook has to keep a list
> >    of which MSRs would cause a #VE and use a TDCALL.  All other MSRs
> >    execute RDMSR/WRMSR instructions directly.
> > 
> > The second option can be ruled out because the list of MSRs was
> > challenging to maintain. That leaves option #1 as the only viable
> > solution for the minimal TDX support.
> > 
> > For performance-critical MSR writes (like TSC_DEADLINE), future patches
> > will replace the WRMSR/#VE sequence with the direct TDCALL.
> 
> This will still leave us with a list of non-#VE-inducing MSRs.  That's
> not great.

Em. No. TSC_DEADLINE is #VE-inducing MSR. So we will only maintain a list
of performance-critical MSR writes that do trigger #VE.

Here's how we do it now:

https://github.com/intel/tdx/commit/2cea8becaa5a287c93266c01fc7f2a4ed53c509d

The idea is if MSR is in the list, go for direct TDVMCALL. Otherwise go for
native WRMSR that may or may not trigger #VE.

> But, if we miss an MSR in the performance-critical list, the
> result is a slow WRMSR->#VE.  If we miss an MSR in the paravirt
> approach, we induce a fatal #VE.
> 
> Please add something to that effect if you revise this patch.

I'm not sure explaining mechanism of a future patch is a good idea.
It may change before it gets implemented.

-- 
 Kirill A. Shutemov