linux-kernel - Re: [PATCH 3/5] x86/mce: Add new "handled" field to "struct mce"

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: <20200214085028.GC13395@zn.tnic>
Date:   Fri, 14 Feb 2020 09:50:28 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] x86/mce: Add new "handled" field to "struct mce"

On Thu, Feb 13, 2020 at 02:09:53PM -0800, Luck, Tony wrote:
> 1) It is useful to user mode. The mcelog(8) daemon (or other consumer
>    of "struct mce") gets a record of where to look for logs from this
>    record.  This could reduce the anxiety about logging the same item
>    multiple times.  Its a bit weird though because each entity logging
>    only sees who came before them, not who came after.

Err, doesn't mcelog get the error shoved down through /dev/mcelog? IOW,
why would it even have to look?

Ditto for other consumers which read the tracepoint...

> 2) Not useful
> 	2a) Keep it in the structure, but clear it in copies shown to user

Yah, also ok.

> 	2b) Make a *private to point to such things (but that really
> 	    complicates allocation of struct mce ... right now we just
> 	    have local copies on kernel stack)

Yeah..

> 	2c) Make a wrapper structure:
> 		struct kernel_mce {
> 			struct mce mce;
> 			u32 handled;
> 			... other hidden stuff ...
> 		};

That too.

2a) sounds really simple to me and I like simple. And if we ever end up
needing more fields, we'll just add another one and keep clearing it on
copy to user.

And just to make our lives easier, we can do

	u64 kflags;

and put the handled stuff there but still have a 64-bit value for future
flags.

Thx.

-- 
Regards/Gruss,
    Boris.

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