linux-kernel - Re: [PATCH 2/2] x86, mce: Add persistent MCE event

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: <20120324090030.GB15993@aftab>
Date:	Sat, 24 Mar 2012 10:00:30 +0100
From:	Borislav Petkov <bp@...64.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Borislav Petkov <bp@...64.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] x86, mce: Add persistent MCE event

On Sat, Mar 24, 2012 at 08:37:31AM +0100, Ingo Molnar wrote:
> I was mainly thinking of reducing this:
> 
>  arch/x86/kernel/cpu/mcheck/mce.c |   53 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> to almost nothing. There doesn't seem to be much MCE specific in 
> that code, right?

Yeah, this could be generalized even more, AFAICT.

> 
> > Btw, the more important question is are we going to need 
> > persistent events that much so that a generic approach is 
> > warranted? I guess maybe the black box events recording deal 
> > would be another user..
> 
> So, here's the big picture as I see it:
> 
> I think tracing could use persistent events: mark all the events 
> we want to trace as persistent from bootup, and recover the 
> bootup trace after the system has been booted up.

Right, but (more nasty questions):

Why would I do this, am I tracing the boot process? If so, then I need
another syntax which enables those events from the kernel command line
which gets parsed the moment ftrace and ring buffer get initialized.

IOW, I'd need userspace for perf otherwise but I don't have that before
booting...

Then, after having booted, do I stop the trace? If no, then I can see
the persistency in there so are you saying we want a low overhead, low
ressource utilization machinery which runs all the time and traces
the system? What are possible real life use cases for that? Scheduler
analysis probably, long-term tracing of some stuff people are interested
in how it behaves over long periods of time... MCE is one use case,
definitely...

> But other, runtime models of tracing could use it as well: 
> basically the main difference that ftrace has to perf based 
> tracing today is a system-wide persistent buffer with no 
> particular owning process. (The rest is mostly UI and analysis 
> features and scope of tracing differences, and of course a lot 
> more love and detail went into ftrace so far.)
> 
> So MCE will in the end be just a minor user of such a facility - 
> I think you should aim for enabling *any* set of events to have 
> persistent recording properties, and add the APIs to recover 
> that information sanely. It should also be possible for them to 
> record into a shared mmap page in essence - instead of having 
> per event persistent buffers.

Sounds like ftrace. But we have that already, we only need to get to
using it perf-side, no...? Especially if we could get the love and
detail that went in there for free :-) ...without stepping on Steve's
toes, of course :-).

..

Fun.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/