linux-kernel - RE: [PATCH v2 01/21] x86/virt/tdx: Detect SEAM

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: <BN9PR11MB52765EE37C00F0FFA01447968C1D9@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Mon, 28 Mar 2022 08:10:47 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     "Huang, Kai" <kai.huang@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC:     "Hansen, Dave" <dave.hansen@...el.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "Luck, Tony" <tony.luck@...el.com>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>
Subject: RE: [PATCH v2 01/21] x86/virt/tdx: Detect SEAM

> From: Huang, Kai <kai.huang@...el.com>
> Sent: Monday, March 28, 2022 11:55 AM
> 
> On Wed, 2022-03-23 at 16:21 +1300, Tian, Kevin wrote:
> > > From: Kai Huang <kai.huang@...el.com>
> > > Sent: Sunday, March 13, 2022 6:50 PM
> > >
> > > @@ -715,6 +716,8 @@ static void init_intel(struct cpuinfo_x86 *c)
> > >       if (cpu_has(c, X86_FEATURE_TME))
> > >               detect_tme(c);
> > >
> > > +     tdx_detect_cpu(c);
> > > +
> >
> > TDX is not reported as a x86 feature. and the majority of detection
> > and initialization have been conducted on demand in this series
> > (as explained in patch04). Why is SEAM (and latter keyid) so different
> > to be detected at early boot phase?
> >
> > Thanks
> > Kevin
> 
> Hi Kevin,
> 
> Sorry for late reply.  I was out last week.
> 
> SEAMRR and TDX KeyIDs are configured by BIOS and they are static during
> machine's runtime.  On the other hand, TDX module can be updated and
> reinitialized at runtime (not supported in this series but will be supported in
> the future).  Theoretically, even P-SEAMLDR can be updated at runtime
> (although
> I think unlikely to be supported in Linux).  Therefore I think detecting
> SEAMRR
> and TDX KeyIDs at boot fits better.

If those info are static it's perfectly fine to detect them until they are
required... and following are not solid cases (e.g. just exposing SEAM
alone doesn't tell the availability of TDX) but let's also hear the opinions
from others.

> 
> It is also more flexible from some other perspectives I think: 1) There was a
> request to add X86_FEATURE_SEAM bit and expose it to /proc/cpuinfo. I
> didn't add
> it because I didn't think the use case was solid.  But in case someone has
> some
> use case in the future we can add it, and detecting SEAMRR during boot fits
> this
> more. 2) There was a request to expose TDX KeyID info via sysfs so userspace
> can
> know how many TDs can be created.  It's not done in this series but it will be
> done at some time in the future. Detecting KeyIDs at boot allows this info
> being
> able to be exposed via sysfs at early stage, providing more flexibility to
> userspace.
> 
> At last, currently in this series the patch to handle kexec checks whether
> SEAMRR and TDX KeyIDs are enabled and then flush cache (of course this is
> open
> to discussion).  Detecting them at boot fits better I think.
> 
> --
> Thanks,
> -Kai
>