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

My biggest beefs are page table manipulation, all the extra ugliness in kernel entry and exit, and lack of clear initialization semantics.  Additionally, any pvop which has unclear semantics - especially anything which is a nop on native and has zero documentation.

Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:

>On Mon, Apr 23, 2012 at 09:17:28AM -0700, H. Peter Anvin wrote:
>> On 04/23/2012 08:27 AM, Luck, Tony wrote:
>> >> 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.
>> > 
>> > Agreed. Even before we get to deleting mcelog, "struct mce" can
>change (new
>> > fields could be added) ... and you don't want to have your
>hypervisor to
>> > have to know which version of Linux it is talking to.
>> 
>> This is a great example on the fundamental problem with Xen, or
>rather
>> the approach that Xen has taken of grabbing random kernel internals
>and
>> claiming them as APIs (or, in some cases even as ABIs.)  A lot of
>these
>
>I am _not_ claiming that. If I left you with that impression from my
>responses - my fault for not getting my point across (the sleep
>deprevation
>is probably not helping either).
>
>I am _not_ stating that the usage of 'mce_log' or 'struct mce' MUST
>remain the same from now on. No. I am saying that the driver will be
>changed lock-step as Tony and Boris see fit in changing the functions.
>
>And currently the way the existing MCE drivers do this - is by using
>mce_log. This driver does is too - since the in-tree drivers do it this
>way.
>When they change to use a different mechanism - this driver will as
>well.
>
>> have had problems that are now very nearly unfixable, and that has
>> seriously stalled out the ability of evolve the Linux kernel in some
>> areas.  Note that the cost of this is borne by the development
>> community, not by the Xen maintainers.
>
>The ones I know that you are unhappy about are the MMU paravirt
>interfaces
>and I did mention to you that once some prototype work is done and
>it showed success, I will work on removing said support.
>
>Why don't you send me your unhappy list so that is on my radar as well
>please?
>
>> 
>> 	-hpa
>> 
>> -- 
>> H. Peter Anvin, Intel Open Source Technology Center
>> I work for Intel.  I don't speak on their behalf.
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@...ts.xen.org
>> http://lists.xen.org/xen-devel

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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/