linux-kernel - Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform

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:	Sun, 22 Apr 2012 22:18:27 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Borislav Petkov <bp@...64.org>
Cc:	"Liu, Jinsong" <jinsong.liu@...el.com>, tony.luck@...el.com,
	x86@...nel.org, linux-edac@...r.kernel.org,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform

> > > This patch gets error information from xen hypervisor and convert
> > > xen format error into linux format mcelog. This logic is basically
> > > self-contained, not much touching other kernel components.
> 
> I have a problem with that statement above. This thing uses struct mce
> and mce_log(), which are internal to x86, and whenever we want to change
> anything there, we won't be able to because xen uses it too.

Huh? You mean this:

       m.misc = mc_bank->mc_misc;
       m.status = mc_bank->mc_status;
       m.addr = mc_bank->mc_addr;
       m.tsc = mc_bank->mc_tsc;
       m.bank = mc_bank->mc_bank;
       m.finished = 1;
       /*log this record*/
       mce_log(&m);

?

This driver is not that much different from the APEI bridge to MCE code -
it just that instead of reading APEI blob data it reads it from an hypercall.

Taking this a step forward, If you change the 'mce_log' or the 'struct mce'
won't you have a problem with the APEI one b/c it uses it too?

The fix seems quite easy - you change the 'struct mce' and 'mce_log()'
along with the drivers that use it.

If you are worried about breaking something, then you can just send
the change to me or Liu to test it out before committing API changes
in the MCE code.


> 
> And this has happened already with the whole microcode loading debacle.

My recollection is that the existing microcode API had major issues that
could not fixed. The only fix was to make it be very early in the bootup
processes and that is what hpa would like developers to focus on.

> 
> So, my suggestion is to copy the pieces you need and create your own xen
> version of /dev/mcelog and add it to dom0 so that there's no hooking
> into baremetal code and whenever a dom0 kernel is running, you can
> reroute the mcelog userspace tool to read /dev/xen_mcelog or whatever
> and not hook into the x86 versions.
> 
> Because, if you'd hooked into it, just imagine one fine day, when we
> remove mcelog support, what screaming the xen people will be doing when
> mcelog doesn't work anymore.

You would have more screaming from the distro camp about removing
/dev/mcelog. But if that is your choice, I would send you an email
asking how I need to retool this driver to work with the new MCE gen2
code that you had in mind.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/