linux-kernel - Re: [PATCH v9 05/18] x86/virt/tdx: Add SEAMCALL infrastructure

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: <e06853c48d7dcb6aa44ce88a23fbe650f01ae8c0.camel@intel.com>
Date:   Tue, 14 Feb 2023 22:17:46 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "Luck, Tony" <tony.luck@...el.com>,
        "david@...hat.com" <david@...hat.com>,
        "bagasdotme@...il.com" <bagasdotme@...il.com>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "Chatre, Reinette" <reinette.chatre@...el.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "Shahar, Sagi" <sagis@...gle.com>,
        "imammedo@...hat.com" <imammedo@...hat.com>,
        "Gao, Chao" <chao.gao@...el.com>,
        "Brown, Len" <len.brown@...el.com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v9 05/18] x86/virt/tdx: Add SEAMCALL infrastructure

On Tue, 2023-02-14 at 09:27 -0800, Dave Hansen wrote:
> On 2/14/23 00:57, Huang, Kai wrote:
> > Consider this case:
> > 
> >         1) KVM does VMXON for all online cpus (a VM created)
> >         2) Another kernel component is calling tdx_enable()
> >         3) KVM does VMXOFF for all online cpus (last VM is destroyed)
> 
> Doctor, it hurts when I...
> 
> Then let's just call tdx_enable() from other kernel components.
> 
> Kai, I'm worried that this is, again, making things more complicated
> than they have to be.

The handling of #UD/#GP itself only takes ~10 LoC.  All those complicated logic
comes from we depend on caller of TDX to ensure VMXON has been done.

AFAICT we have below options:

1) Don't support VMXON in the core-kernel, then  
  1.a Handle #UD/#GP in assembly as shown in this patch; Or
  1.b Disable interrupt from CR4.VMXE check until SEAMCALL is done in 
      seamcall().

2) Let's support VMXON in the core-kernel (by moving VMXON from KVM to the core-
x86), then we get rid of all above.  We explicitly do VMXON (if haven't done)
inside tdx_enable() to make  sure SEAMCALL doesn't cause #UD.  No #UD/#GP
handling is needed in assembly.  No interrupt disable in seamcall().

(well #GP can theoretically still happen if BIOS is buggy, we can keep assembly
code change if it's better -- just ~10 LoC). 

Supporting VMXON in the core-kernel also has other advantages:

1) We can get rid of the logic to always try to do LP.INIT for all online cpus.
LP.INIT can just be done: a) during module initialization; b) in TDX CPU hotplug
callback.

2) The TDX CPU hotplug callback can just do VMXON and LP.INIT.  No CR4.VMXE
check is needed.  And it can be put before KVM (all TDX users)' hotplug
callback.

The downside of supporting VMXON to the core-kernel:

1) Need patch(es) to change KVM, so those patches need to be reviewed by KVM
maintainers.
2) No other cons.

Logically, supporting VMXON in the core-kernel makes things simple.  And long-
termly, I _think_ we will need it to support future TDX features.

The effort to support VMXON in the core-kernel would be ~300 LOC.  I can already
utilize some old patches, but need to polish those patches and do some test.

What's your thinking?