linux-kernel - Re: [PATCH v6 18/21] x86/virt/tdx: Configure global KeyID on all packages

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: <7e551933cf1b41d39f772f4f06a6912d77eb64b1.camel@intel.com>
Date:   Fri, 28 Oct 2022 01:07:59 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>
CC:     "Hansen, Dave" <dave.hansen@...el.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "bagasdotme@...il.com" <bagasdotme@...il.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>,
        "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>,
        "Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v6 18/21] x86/virt/tdx: Configure global KeyID on all
 packages

Thanks for the review!

> >   
> > +/*
> > + * Call one SEAMCALL on one (any) cpu for each physical package in
> > + * serialized way.  Return immediately in case of any error if
> > + * SEAMCALL fails on any cpu.
> 
> 
> It's not clear what are you serializing against (against itself or other 
> calls of this functions)
> 
> I assume its because the TDX module errors out for parallel calls 
> instead of waiting.

Yes.

> 
> The code seems to only do itself, so where is the check against others? 
> I assume in the callers but that would need to be explained. 
> 

Yes in the callers.  In short there's no need, or it doesn't make sense to check
against others as SEAMCALLs involved during the module initialization are not
supposed can be made in random.

> Also could 
> it need serialization against other kinds of seam calls?

The TDX module initialization is essentially a state machine -- it involves a
couple of steps to finish the process and each step moves the TDX module's
current state to a later state.

Each step involves a different SEAMCALL, but this SEAMCALL may be only called
one (any) cpu, or needs to be called for all cpus, or one (any) cpu for each
package.

The TDX module initialization code do the whole process step by step, so the
caller guarantees no random SEAMCALLs will be made when it is doing one step of
the initialization.

> 
> Perhaps it might be more efficient to just broad cast and handle a retry 
> with some synchronization in the low level code.
> 
> That likely would cause less review thrash than just reimplementing a 
> common function like this here.

As mentioned above the whole initialization process is just a machine state, so
not all SEAMCALLs are subject to the logic of retry.  To me the retry only makes
sense for one particular SEAMCALL which must be done on multiple cpus but
requires some serialization.

Does all above make sense?