linux-kernel - Re: [PATCH net-next] udp: Add tracepoints to monitor skbs going in and out of a UDP socket

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, 4 Oct 2018 19:03:18 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     David Howells <dhowells@...hat.com>
Cc:     David Ahern <dsahern@...il.com>, netdev@...r.kernel.org,
        linux-afs@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] udp: Add tracepoints to monitor skbs going in
 and out of a UDP socket

On Fri, Oct 05, 2018 at 12:24:42AM +0100, David Howells wrote:
> 
> As for kprobes: spots, plural.  Using kprobes involves installing breakpoint
> instructions and taking traps and would seem to require using printk for the
> output, which would affect the timings and potentially affect the situation,
> especially given the sheer amount of traces produced.  Note that one of these
> was in an interrupt handler, which is possibly not the best place to be taking
> an illegal instruction trap.
> 
> Using kprobes gets worse too.  In my case, the source code and the build tree
> aren't on the test machine, which I understand would be a requirement - and

there is quite a bit of misunderstanding in the above two paragraphs about kprobes.
Sounds like it influences odd design choices with tracepoints.

- kprobes at the top of the function don't use traps and they've been
optimized over the years to have very low overhead
- trace_printk is using the same mechanism as tracepoint prints
- both trace_printk and tracepoints can affect timing
- kprobes and trace_printk work well out of irq handler. They work out of NMI too
- build tree doesn't need to be present to use kprobes

perf, bcc and others tools have user friendly (arguable of course) interfaces
for kprobes.