linux-kernel - Re: x86, ptrace: support for branch trace store(BTS)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 10 Dec 2007 21:20:52 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Markus Metzger <markus.t.metzger@...el.com>
Cc:	ak@...e.de, hpa@...or.com, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, markut.t.metzger@...el.com,
	markus.t.metzger@...il.com, suresh.b.siddha@...el.com,
	roland@...hat.com, akpm@...ux-foundation.org,
	mtk.manpages@...il.com, Alan Stern <stern@...land.harvard.edu>
Subject: Re: x86, ptrace: support for branch trace store(BTS)

[ Cc:-ed Alan Stern a'ka kwatch fame - Alan might be interested in this 
  too. ]

hi Markus,

finally had time to take a closer look at the design of your 
Branch-Trace-Support-via-ptrace-on-x86 patchset. I think we'll need to 
work some more on general API issues.

here's the current proposed API:

+       case PTRACE_BTS_MAX_BUFFER_SIZE:
+       case PTRACE_BTS_ALLOCATE_BUFFER:
+       case PTRACE_BTS_GET_BUFFER_SIZE:
+       case PTRACE_BTS_READ_RECORD:
+       case PTRACE_BTS_CONFIG:
+       case PTRACE_BTS_STATUS:

i can see a couple of open questions:

1) PTRACE_BTS_MAX_BUFFER_SIZE

why is a trace buffer size limit visible to user-space? It's 4000 
entries right now:

     #define PTRACE_BTS_BUFFER_MAX 4000

it would be more flexible if user-space could offer arbitrary sized 
buffers, which the kernel would attempt to mlock(). Then those pages 
could be fed to the BTS MSR. I.e. there should be no hard limit in the 
API, other than a natural resource limit.

2) struct bts_struct

the structure of it is hardwired:

the basic unit is an array of bts_struct:

 +struct bts_struct {
 +       enum bts_qualifier qualifier;
 +       union {
 +               /* BTS_BRANCH */
 +               struct {
 +                       long from_ip;
 +                       long to_ip;
 +               } lbr;
 +               /* BTS_TASK_ARRIVES or
 +                  BTS_TASK_DEPARTS */
 +               unsigned long long timestamp;
 +       } variant;
 +};

while other CPUs (on other architectures, etc.) might have a different 
raw format for the trace entries. So it would be better to implement BTS 
support in kernel/ptrace.c with a general trace format, and to provide a 
cross-arch API (only implemented by arch/x86 in the beginning) to 
translate the 'raw' trace entries into the general format.

3)

it would certainly be useful for some applications to have a large 
"virtual" trace buffer and a small "real" trace buffer. The kernel would 
use BTS high-watermark interrupts to feed the real trace buffer into the 
larger "virtual" trace buffer. This way we wouldnt even have to use 
mlock() to pin down the trace buffer.

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