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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ