On Thu, 29 Mar 2018 14:35:16 -0400 (EDT)
Mathieu Desnoyers [off-list ref] wrote:

----- On Mar 29, 2018, at 2:07 PM, rostedt rostedt@goodmis.org wrote:

quoted

On Thu, 29 Mar 2018 14:02:33 -0400 (EDT)
Mathieu Desnoyers [off-list ref] wrote:
  

quoted

Currently, anyone using ptrace on a process has pretty much given up all
hopes of performance. Processes will use rseq to gain performance, not the
opposite, so this deterioration will be unwelcome.  

The ptrace path has nothing to do with ptrace anymore, and probably be
hard to notice the performance hit. You simply set a TIF flag, and on
exit of the syscall it jumps to a path that checks special cases
(tracing system calls being one of them). It's called the ptrace path
because ptrace was the first one to use it (I'm guessing, I haven't
actually looked at the history).  

Last time I checked, it's not only a jump, it's actually saving/restoring
tons of registers. Did this change recently ?

I use it for LTTng syscall tracing too. My experience so far is that it's really
terribly slow. I've been waiting on Andy Lutomirski to complete his changes in that
area to look into making this faster for syscall tracepoints.

This gives us more incentive to help Andy make it faster ;-)

-- Steve

quoted

This is used to add any system call checks that are not done during
normal operation. And this certainly falls under that category.  

I know it's used for stuff like seccomp too. My guess has always been that security
people care much more about robustness than performance.

Thanks,

Mathieu