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: <20200213170820.GN31799@zn.tnic>
Date:   Thu, 13 Feb 2020 18:08:20 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Tony Luck <tony.luck@...el.com>
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 Wed, Feb 12, 2020 at 12:46:52PM -0800, Tony Luck wrote:
> Instead of keeping count of how many handlers are registered on the
> mce chain and printing if we are below some magic value. Look at the
> mce->handled to see if anyone claims to have handled/logged this error.
> 
> [debug to always print in this version]
> 
> Signed-off-by: Tony Luck <tony.luck@...el.com>
> ---
>  arch/x86/kernel/cpu/mce/core.c | 20 ++++----------------
>  1 file changed, 4 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index ce7a78872f8f..5b73df383300 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -156,29 +156,17 @@ void mce_log(struct mce *m)
>  }
>  EXPORT_SYMBOL_GPL(mce_log);
>  
> -/*
> - * We run the default notifier if we have only the UC, the first and the
> - * default notifier registered. I.e., the mandatory NUM_DEFAULT_NOTIFIERS
> - * notifiers registered on the chain.
> - */
> -#define NUM_DEFAULT_NOTIFIERS	3
> -static atomic_t num_notifiers;
> -

I definitely like where this is going.

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.

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.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette