linux-kernel - Re: [Patch -tip 3/3] Tracing/ftrace: Don't consume entries unhandled by mmiotrace

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:	Thu, 25 Sep 2008 18:36:08 +0300
From:	Pekka Paalanen <pq@....fi>
To:	"Frédéric Weisbecker" <fweisbec@...il.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [Patch -tip 3/3] Tracing/ftrace: Don't consume entries
 unhandled by mmiotrace

On Thu, 25 Sep 2008 16:44:08 +0200
"Frédéric Weisbecker" <fweisbec@...il.com> wrote:

> 2008/9/25 Pekka Paalanen <pq@....fi>:
> > NACK.
> >
> > mmiotrace's log output is stricly specified, the standard/default
> > printing functions may NOT be used. The output is supposed to be
> > machine readable in addition to human readable.
> >
> > The ftrace infrastructure assumes there is only one active tracer
> > at a time, therefore destroying unhandled entries is not a problem.
> 
> Hi Pekka.
> 
> It's up to you.
> I just guessed that one would trace IO and stack for example.
> Or why not IO and functions: This sounds to me very useful (who
> performed this io..?)

We can (must) return to this if/when multiple tracers are allowed
to be active simultaneously. But in the current situation, I do not
see a way to trace more than one thing, but I haven't really looked
into the other tracers.

OTOH, mmiotrace log format has a pid field, which is pretty much unused
currently. It could be used to record the current process, if one exists.
That can be added, should the need arise, but so far the field has been
reserved for tracing accesses done in user space - but those are not
caught yet.

I'm not sure what stack trace collects, but tracing functions is useless
or harmful in the usual use case of mmiotrace, i.e. tracing a binary-only
proprietary driver. The functions will be anonymous anyway, and we can't
disassemble the driver due to possible legal reasons. That's why mmiotrace
does not even collect instruction pointers by default, although it
supports them (or did, can't recall if it works now, since it hasn't been
needed). I assume the goal is to create a free open driver without any
legal issues by watching what the proprietary driver does.

Even if the log would be cluttered with MMIO from other, uninteresting
drivers, you can use the physical address to filter the entries by
device (and therefore driver) afterwards. This is one reason why
an mmiotrace log starts with the contents of /proc/bus/pci/devices.

Was there some other scenario you were thinking about?

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/