linux-kernel - RE: [Xen-devel] [PATCH 1/3] xen/mce: Add mcelog support for Xen platform (v2)

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, 25 May 2012 19:55:08 +0000
From:	"Liu, Jinsong" <jinsong.liu@...el.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Borislav Petkov <bp@...64.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Luck, Tony" <tony.luck@...el.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: RE: [Xen-devel] [PATCH 1/3] xen/mce: Add mcelog support for Xen
 platform (v2)

Konrad Rzeszutek Wilk wrote:
> On Fri, May 25, 2012 at 06:01:04PM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>>>>> The reason is, if we do so, it would be covered by native
>>>>>> misc_register(&mce_chrdev_device) later when native kernel init
>>>>>> (xen init first and then start native kernel).
>>>>>> Under such case, if linux running under xen platform, /dev/mcelog
>>>>>> point to vcpu, that's pointless since it cannot get any mcelog
>>>>>> from physical cpu (which owned by xen).
>>>>>> 
>>>>>> Yes, we can use another misc device like /dev/xen-mcelog, w/
>>>>>> another device minor like 226, but that's not good for userspace
>>>>>> mcelog tools. As far as I know, Novell mcelog use unified
>>>>>> /dev/mcelog interface for linux running under either bare metal
>>>>>> or xen platform.
>>>>> 
>>>>> Maybe create a symlink in /dev/mcelog pointing to /dev/xen-mcelog?
>>>>> 
>>>>> That should solve it.
>>>> 
>>>> Kernel has created a file /dev/mcelog no matter running at native
>>>> or xen platform. If xen try to mask kernel creating /dev/mcelog,
>>>> that would be harmful to native kernel.
>>> 
>>> Huh? The Xen code won't run under native kernel so how will it mask
>>> it?
>> 
>> Hmm, I mean 'xen related code' of linux kernel, e.g. drivers/xen/...
> 
> OK? I am still not getting what you are saying. Could you please
> rephrase it?

What I mean is,
If mcelog.c create /dev/xen-mcelog (say, minor=226), native mce.c would create /dev/mcelog (minor=227).
Under such case, may we create a symlink in /dev/mcelog pointing to /dev/xen-mcelog, without touching native mce code? and how?

> 
> Why would disabling the generic "/dev/mcelog" and use your version
> of "/dev/mcelog" be harmful? I think this is what Boris was hinting
> as the proper way of doing it.

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