linux-kernel - RE: [PATCH v2 04/21] x86/virt/tdx: Add skeleton for detecting and initializing TDX on demand

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: <BN9PR11MB52761E8DE55DC8872EC093758C1D9@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Mon, 28 Mar 2022 11:47:42 +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>,
        "Gleixner, Thomas" <thomas.gleixner@...el.com>
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 04/21] x86/virt/tdx: Add skeleton for detecting and
 initializing TDX on demand

> From: Huang, Kai <kai.huang@...el.com>
> Sent: Monday, March 28, 2022 5:24 PM
> >
> > cpu_present_mask does not always represent BIOS-enabled CPUs due
> > to those boot options. Then why do we care whether CPUs in this mask
> > (if only representing a subset of BIOS-enabled CPUs) are at least brought
> > up once? It will fail at TDH.SYS.CONFIG anyway.
> 
> As I said, this is used to make sure SEAMRR has been detected on all cpus, so
> that any BIOS misconfiguration on SEAMRR has been detected.  Otherwise,
> seamrr_enabled() may not be reliable (theoretically).

*all cpus* is questionable. 

Say BIOS enabled 8 CPUs: [0 - 7]

cpu_present_map covers [0 - 5], due to nr_cpus=6

You compared cpus_booted_once_mask to cpu_present_mask so if maxcpus
is set to a number < nr_cpus SEAMRR is considered disabled because you
cannot verify CPUs between [max_cpus, nr_cpus). If following the same
rationale then you also need a proper way to detect the case where nr_cpus
< BIOS enabled number i.e. when you cannot verify SEAMRR on CPUs
between [nr_cpus, 7]. otherwise this check is just incomplete.

But the entire check is actually unnecessary. You just need to verify SEAMRR
and do TDX cpu init on online CPUs. Any gap between online ones and BIOS
enabled ones will be caught by the TDX module at TDH.SYS.CONFIG point.

> 
> Alternatively, I think we can also add check to disable TDX when 'maxcpus'
> has
> been specified, but I think the current way is better.
> 
> >
> > btw your comment said that 'maxcpus' is basically an invalid mode
> > due to MCE broadcase problem. I didn't find any code to block it when
> > MCE is enabled,
> 
> Please see below comment in cpu_smt_allowed():
> 
> static inline bool cpu_smt_allowed(unsigned int cpu)
> {
> 	...
>         /*
>          * On x86 it's required to boot all logical CPUs at least once so
>          * that the init code can get a chance to set CR4.MCE on each
>          * CPU. Otherwise, a broadcasted MCE observing CR4.MCE=0b on any
>          * core will shutdown the machine.
>          */
> 	 return !cpumask_test_cpu(cpu, &cpus_booted_once_mask);
> }

I saw that code. My point is more about your statement that maxcpus
is almost invalid due to above situation then why didn't we do anything
to document such restriction or throw out a warning when it's
misconfigured...

> 
> > thus wonder the rationale behind and whether that
> > rationale can be brought to this series (i.e. no check against those
> > conflicting boot options and just let SEAMCALL itself to detect and fail).
> >
> > @Thomas, any guidance here?
> >
> > Thanks
> > Kevin