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: <20200910185434.GM8357@zn.tnic>
Date:   Thu, 10 Sep 2020 20:54:34 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] x86/mce: Make mce_rdmsrl() do a plain RDMSR only

On Thu, Sep 10, 2020 at 11:42:06AM -0700, Luck, Tony wrote:
> With only one call site the rIP isn't super helpful at the moment. But
> once you start selling those "MSR or die" T-shirts everyone will want
> to use this :-)

:-)))

> Do we need the stack trace twice? Once from your fixup
> function, second from panic()?

The second panic comes from:

        if (lmce) {
                if (no_way_out)
                        mce_panic("Fatal local machine check", &m, msg);


in do_machine_check() and we panic earlier in mce_no_way_out() where I
stuck

	mce_rdmsrl(0x1234);

because that one does reads MCi_STATUS. mce_gather_info() could cause it
too because it gathers all the other MSRs.

Now, if we want to avoid the second panic(), we'd have to tell that site
above that we have panicked already but that would require some flag
variable or even more uglification.

Considering how this situation is supposed to almost never happen and
how we're actually interested in the first line of the whole splat I
pasted, how much output comes after it, doesn't really matter. All it
matters is that the machine stops any further progress (as much as we
can do that with a panic, ofc).

Or do you see a more important issue with a second panic to warrant such
not-really-needed change?

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