linux-kernel - [PATCH 0/1] x86/microcode: Revert cache flush on Intel microcode loading

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-next>] [day] [month] [year] [list]

Message-Id: <20240701212012.21499-1-chang.seok.bae@intel.com>
Date: Mon,  1 Jul 2024 14:20:11 -0700
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: linux-kernel@...r.kernel.org
Cc: x86@...nel.org,
	tglx@...utronix.de,
	mingo@...hat.com,
	bp@...en8.de,
	dave.hansen@...ux.intel.com,
	tony.luck@...el.com,
	ashok.raj@...el.com,
	chang.seok.bae@...el.com
Subject: [PATCH 0/1] x86/microcode: Revert cache flush on Intel microcode loading

Hi All,

During the process of aligning our internal code with the upstream code,
Yan reported significantly increased late loading times. William
identified the cause as the cache writeback and invalidation in the
microcode update path. This patch [1] appears to have been around our
platform-specific branches before.

The changelog [2] explains that the flush can guarantee a successful
microcode update and mentions Broadwell parts as an example, without
specifying any erratum. After discussing with some related folks, the
erratum [3] was clarified as the reason for the flush.

However, the affected revisions on the relevant Broadwell models have
already been blacklisted, making this flush obsolete. Initially, I was
quite confused that the two approaches ([4,5,6] and [7]) were dealing
with the same issue. Unfortunately, that is the case, as I double-checked
with the author.

This cache flush does not come without a cost. In older parts like
Broadwell and Skylake systems, for example, it takes about 3.5x more time
than WRMSR for the microcode update.

I’d like to ensure the patch description is clear enough to describe the
whole story for the record, as I am posting this revert.

Thanks,
Chang

[1] “Drop wbinvd() from microcode loading”:
    https://lore.kernel.org/lkml/20230130213955.6046-9-ashok.raj@intel.com/
[2] Commit 91df9fdf5149 (“x86/microcode/intel: Writeback and invalidate
    caches before updating microcode”)
[3] BDX90 - Loading Microcode Updates or Executing an Authenticated Code
    Module May Result in a System Hang. Details can be found in Intel
    Xeon E7-8800/4800 v4 Processor Product Family, Specification Update,
    August 2020:
    https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e7-v4-spec-update.pdf
[4] Commit 723f2828a98c (“x86/microcode/intel: Disable late loading on
    model 79”)
[5] Commit b94b73733171 (“x86/microcode/intel: Extend BDW late-loading
    with a revision check”)
[6] Commit 7e702d17ed13 (“x86/microcode/intel: Extend BDW late-loading
    further with LLC size check”)
[7] Commit 91df9fdf5149 (“x86/microcode/intel: Writeback and invalidate
    caches before updating microcode”)

Chang S. Bae (1):
  arch/x86/microcode/intel: Remove unnecessary cache writeback and
    invalidation

 arch/x86/kernel/cpu/microcode/intel.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

-- 
2.34.1