lkml.org 
[lkml]   [2022]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-03-07 23:35    [W:0.080 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site