• Jue Wang's avatar
    x86/mce: Work around an erratum on fast string copy instructions · 8ca97812
    Jue Wang authored
    A rare kernel panic scenario can happen when the following conditions
    are met due to an erratum on fast string copy instructions:
    
    1) An uncorrected error.
    2) That error must be in first cache line of a page.
    3) Kernel must execute page_copy from the page immediately before that
    page.
    
    The fast string copy instructions ("REP; MOVS*") could consume an
    uncorrectable memory error in the cache line _right after_ the desired
    region to copy and raise an MCE.
    
    Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast string
    copy and will avoid such spurious machine checks. However, that is less
    preferable due to the permanent performance impact. Considering memory
    poison is rare, it's desirable to keep fast string copy enabled until an
    MCE is seen.
    
    Intel has confirmed the following:
    1. The CPU erratum of fast string copy only applies to Skylake,
    Cascade Lake and Cooper Lake generations.
    
    Directly return from the MCE handler:
    2. Will result in complete execution of the "REP; MOVS*" with no data
    loss or corruption.
    3. Will not result in another MCE firing on the next poisoned cache line
    due to "REP; MOVS*".
    4. Will resume execution from a correct point in code.
    5. Will result in the same instruction that triggered the MCE firing a
    second MCE immediately for any other software recoverable data fetch
    errors.
    6. Is not safe without disabling the fast string copy, as the next fast
    string copy of the same buffer on the same CPU would result in a PANIC
    MCE.
    
    This should mitigate the erratum completely with the only caveat that
    the fast string copy is disabled on the affected hyper thread thus
    performance degradation.
    
    This is still better than the OS crashing on MCEs raised on an
    irrelevant process due to "REP; MOVS*' accesses in a kernel context,
    e.g., copy_page.
    
    Tested:
    
    Injected errors on 1st cache line of 8 anonymous pages of process
    'proc1' and observed MCE consumption from 'proc2' with no panic
    (directly returned).
    
    Without the fix, the host panicked within a few minutes on a
    random 'proc2' process due to kernel access from copy_page.
    
      [ bp: Fix comment style + touch ups, zap an unlikely(), improve the
        quirk function's readability. ]
    Signed-off-by: default avatarJue Wang <juew@google.com>
    Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
    Reviewed-by: default avatarTony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20220218013209.2436006-1-juew@google.com
    8ca97812
core.c 68.5 KB