linux-kernel - Re: [PATCH v8 12/16] x86/virt/tdx: Designate the global KeyID and configure the TDX module

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: <c4e5eadae12c72e7b6d97c1802773694ee04ba86.camel@intel.com>
Date:   Tue, 10 Jan 2023 23:33:47 +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>,
        "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>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "Chatre, Reinette" <reinette.chatre@...el.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Shahar, Sagi" <sagis@...gle.com>,
        "imammedo@...hat.com" <imammedo@...hat.com>,
        "Gao, Chao" <chao.gao@...el.com>,
        "Brown, Len" <len.brown@...el.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "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 v8 12/16] x86/virt/tdx: Designate the global KeyID and
 configure the TDX module

On Tue, 2023-01-10 at 08:25 -0800, Dave Hansen wrote:
> On 1/10/23 02:48, Huang, Kai wrote:
> > > > 
> > > > +   /*
> > > > +    * Use the first private KeyID as the global KeyID, and pass
> > > > +    * it along with the TDMRs to the TDX module.
> > > > +    */
> > > > +   ret = config_tdx_module(&tdmr_list, tdx_keyid_start);
> > > > +   if (ret)
> > > > +           goto out_free_pamts;
> > > This is "consuming" tdx_keyid_start.  Does it need to get incremented
> > > since the first guest can't use this KeyID now?
> > 
> > It depends on how we treat 'tdx_keyid_start'.  If it means the first _usable_
> > KeyID for KVM, then we should increase it; but if it only used for the hardware-
> > enabled TDX KeyID range, then we don't need to increase it.
> > 
> > Currently it is marked as __ro_after_init so my intention is the latter (also in
> > the spirit of keeping this series minimal).
> > 
> > Eventually we will need to have functions to allocate/free TDX KeyIDs anyway for
> > KVM, but in that we can just treat 'tdx_keyid_start + 1' as the first usable
> > KeyID.
> 
> So, basically, you're going to depend on the KVM code (which isn't in
> this series) to magically know exactly what this series did?  Then,
> you're expecting that this code will never change in a way that breaks
> this random KVM code?
> 
> That's frankly awful.

Sorry I should have said this in my previous reply:  The two functions will be
implemented in here together with 'tdx_keyid_start' and 'nr_tdx_keyids'
variables, so they are not KVM code, although they will only be used by KVM for
now:

https://lore.kernel.org/lkml/Y19NzlQcwhV%2F2wl3@debian.me/T/#m0735de9e60138da8fa69828b755f1387e031d08d

Another benefit of putting here (not in KVM) is just in case in the future other
kernel components might need to allocate TDX KeyID too.

Btw this series itself is not enough for KVM to support TDX.  There will be some
minor x86 patches based on this series for that (exposing tdsysinfo_struct to
KVM, and this KeyID allocation, etc). 

(Or should I just include them in this series?)

> 
> Make the variable read/write.  Call it tdx_guest_keyid_start, and
> increment it when you make a keyid unavailable for guest use.
> 

Yes I can do if you prefer.

One minor thing is 'tdx_keyid_start' is introduced in the second patch in this
series ("x86/virt/tdx: Detect TDX during kernel boot").  IMHO it would be a
little weird to call it 'tdx_guest_keyid_start' in that patch.