linux-kernel - Re: [PATCHv5 23/30] x86/boot: Avoid #VE during boot for TDX platforms

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: <20220307223353.f7cqzqispfeltvb2@black.fi.intel.com>
Date:   Tue, 8 Mar 2022 01:33:53 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To:     Xiaoyao Li <xiaoyao.li@...el.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...el.com, luto@...nel.org, peterz@...radead.org,
        sathyanarayanan.kuppuswamy@...ux.intel.com, aarcange@...hat.com,
        ak@...ux.intel.com, dan.j.williams@...el.com, david@...hat.com,
        hpa@...or.com, jgross@...e.com, jmattson@...gle.com,
        joro@...tes.org, jpoimboe@...hat.com, knsathya@...nel.org,
        pbonzini@...hat.com, sdeep@...are.com, seanjc@...gle.com,
        tony.luck@...el.com, vkuznets@...hat.com, wanpengli@...cent.com,
        thomas.lendacky@....com, brijesh.singh@....com, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCHv5 23/30] x86/boot: Avoid #VE during boot for TDX platforms

On Mon, Mar 07, 2022 at 05:29:27PM +0800, Xiaoyao Li wrote:
> On 3/2/2022 10:27 PM, Kirill A. Shutemov wrote:
> > From: Sean Christopherson <seanjc@...gle.com>
> > 
> > There are a few MSRs and control register bits that the kernel
> > normally needs to modify during boot. But, TDX disallows
> > modification of these registers to help provide consistent security
> > guarantees. Fortunately, TDX ensures that these are all in the correct
> > state before the kernel loads, which means the kernel does not need to
> > modify them.
> > 
> > The conditions to avoid are:
> > 
> >   * Any writes to the EFER MSR
> >   * Clearing CR3.MCE
> 
> typo. CR4.MCE

Thanks, will send updated patch.

> BTW, I remember there was a patch to clear X86_FEATURE_MCE for TDX guest.
> Why does that get dropped?

It is not dropped. It is just not part of the initial submission. It will
come later.

> Even though CPUID reports MCE is supported, all the access to MCE related
> MSRs causes #VE. If they are accessed via mce_rdmsrl(), the #VE will be
> fixed up and goes to ex_handler_msr_mce(). Finally lead to panic().

It is not panic, but warning. Like this:

	unchecked MSR access error: RDMSR from 0x179 at rIP: 0xffffffff810df1e9 (__mcheck_cpu_cap_init+0x9/0x130)
	Call Trace:
	 <TASK>
	 mcheck_cpu_init+0x3d/0x2c0
	 identify_cpu+0x85a/0x910
	 identify_boot_cpu+0xc/0x98
	 check_bugs+0x6/0xa7
	 start_kernel+0x363/0x3d1
	 secondary_startup_64_no_verify+0xe5/0xeb
	 </TASK>

It is annoying, but not fatal. The patchset is big enough as it is.
I tried to keep patch number under control.

-- 
 Kirill A. Shutemov