linux-kernel - Re: [PATCH] x86/mce: Initialize "bank" when we find a fatal error in mce_no_way

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:   Sat, 2 Feb 2019 16:33:18 +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] x86/mce: Initialize "bank" when we find a fatal error in
 mce_no_way_out()

On Fri, Feb 01, 2019 at 10:36:17AM -0800, Luck, Tony wrote:
> > so it'll be more robust if we moved it there.
> 
> It would be redundant to move it there for both
> existing uses.

Maybe. But if the bank write happens there, it won't be "forgotten"
again.

I don't care what the functions are called. If they need to do something
more, like *fully* populating struct mce so that a proper record gets
logged further down the line, then we need to make them do so. That's
the point I'm trying to make.

Sure, the stable fix should be simple for easier backporting but in
order to avoid this thing happening again in the future, we should
probably look at unifying and making those paths easier to use.

Right now we have

1. mce_setup() - initial population of struct mce, called from
mce_gather_info(), a.o.
2. mce_gather_info() collects global regs
3. mce_read_aux() reading aux regs

and at the very end, we hand it into mce_log().

And in-between we poke (or don't poke) in some fields.

IOW, if the struct mce finishing population is concentrated in a single
function, it will be much harder to forget setting such fields in the
future.

In this case, the devil is in the detail so I'll have a look at this
when more time.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.