linux-kernel - Re: [PATCH 5/5] x86/mce: Change default mce logger to check mce->handled

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: <20200213222750.GC21107@agluck-desk2.amr.corp.intel.com>
Date:   Thu, 13 Feb 2020 14:27:50 -0800
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] x86/mce: Change default mce logger to check
 mce->handled

On Thu, Feb 13, 2020 at 06:08:20PM +0100, Borislav Petkov wrote:
> I definitely like where this is going.

Thanks.

> Another thing: what do we do if we have to deviate from that sequantial
> path through the notifiers? What if notifier A gets to look at an error,
> then another notifier B needs to look at it and then the information
> obtained from the second notifier B, is needed by the first notifier A
> again to inspect the error a *second* time.

That's pretty hard with a chain.  I think folks will have a conniptions
if we invent an error return from a notifier chain function that means
"Go back and start over". Though if we did it would make the "handled"
field useful for functions that didn't want to redo ... they'd just
check if "their" bit in handled was already set.

Still, seems like a terrible idea.

> I don't think there's a case like that now but I'm just playing the
> devil's advocate here. Because a use case like that would break our
> simplistic, sequential assembly line of MCE decoding.

If some driver really wants multiple bites at an error on the
chain it could register more than one handler with different
priorities.  In which case we should have "enum" names for the
highest and lowest priorities so such a driver can go "first"
or "last" (though such a thing would be dependent on whether
some other driver was attempting to add a "first" or "last"
entry on the chain).

-Tony