linux-hardening - RE: [PATCH] x86/hpet: Read HPET directly if panic in progress

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

Message-ID: <SJ1PR11MB60833ACD1E6C946F72C58736FCF92@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Wed, 5 Jun 2024 15:51:07 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Tony W Wang-oc <TonyWWang-oc@...oxin.com>, Borislav Petkov <bp@...en8.de>
CC: Thomas Gleixner <tglx@...utronix.de>, Linus Torvalds
	<torvalds@...ux-foundation.org>, "Hansen, Dave" <dave.hansen@...el.com>,
	"mingo@...hat.com" <mingo@...hat.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>, "keescook@...omium.org"
	<keescook@...omium.org>, "gpiccoli@...lia.com" <gpiccoli@...lia.com>,
	"mat.jonczyk@...pl" <mat.jonczyk@...pl>, "rdunlap@...radead.org"
	<rdunlap@...radead.org>, "alexandre.belloni@...tlin.com"
	<alexandre.belloni@...tlin.com>, "mario.limonciello@....com"
	<mario.limonciello@....com>, "yaolu@...inos.cn" <yaolu@...inos.cn>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>, "justinstitt@...gle.com"
	<justinstitt@...gle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-hardening@...r.kernel.org"
	<linux-hardening@...r.kernel.org>, "CobeChen@...oxin.com"
	<CobeChen@...oxin.com>, "TimGuo@...oxin.com" <TimGuo@...oxin.com>,
	"LeoLiu-oc@...oxin.com" <LeoLiu-oc@...oxin.com>
Subject: RE: [PATCH] x86/hpet: Read HPET directly if panic in progress

> > Which types exactly do you mean when you're looking at the severities[]
> > array in severity.c?
> >
> > And what scenario are you talking about?
> >
> > To get an #MC exception and detect only UCNA/SRAO errors? Can that even
> > happen on any hardware?
> >
>
> Yes, I mean an #MC exception happened and detect only like SRAO errors
> like below:
>
>          MCESEV(
>                  AO, "Action optional: memory scrubbing error",
>                  SER, MASK(MCI_UC_AR|MCACOD_SCRUBMSK,
> MCI_STATUS_UC|MCACOD_SCRUB)
>                  ),
>          MCESEV(
>                  AO, "Action optional: last level cache writeback error",
>                  SER, MASK(MCI_UC_AR|MCACOD, MCI_STATUS_UC|MCACOD_L3WB)
>                  ),
>
> I think these errors are actually encountered on some platforms that
> support these type of errors report to the #MC.

Intel servers from Nehalem through Cascade Lake reported memory controller
patrol scrub uncorrected error with #MC and SRAO signature.

Icelake and newer use CMCI with a UCNA signature.

-Tony