Messages in this thread | | | Date | Tue, 8 Mar 2022 01:33:53 +0300 | From | "Kirill A. Shutemov" <> | 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@google.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
| |