
<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><span id="zwchr" data-marker="__DIVIDER__">----- On Jul 9, 2020, at 7:19 AM, lttng-dev <lttng-dev@lists.lttng.org> wrote:<br></span></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hello!</div><br><div>Currently, I'm developing a process monitor on the base of LTTng, and I face the challenge of accessing command-line arguments passed to execve syscall. </div><div>I'm using LTTng live session and Babeltrace 2 C API to analyze events in online mode.</div><br><div>syscall_entry_execve event has 3 payload fields: filename, argv, and envp. The first one is a normal C-string, the second and the third semantically are `char *const *`, </div><div>but provided by LTTng as simple unsigned integers (the corresponding fields in Babaltrace2 event payload have type BT_FIELD_CLASS_TYPE_UNSIGNED_INTEGER,</div><div>while I expect BT_FIELD_CLASS_TYPE_DYNAMIC_ARRAY). As far as I understand, these integers are argv and envp pointers casted to uint64_t. But in the majority of</div><div>cases, events produced by LTTng are analyzed by another process and often even offline, so these pointers became completely unuseful.</div><br><div>Could you say, if there are some configuration parameters that enable to pass argv and envp content in syscall_entry_execve payload? Or some other ways to get this</div><div>information from LTTng.</div><br><div>P.S. I consider getting this information from /proc/pid/cmdline, but it is not looking like a clean solution.</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>The main reason why we don't implement this kind of instrumentation is because it would then</div><div>capture security-sensitive data into the trace. Likewise for payload of read() and write() system</div><div>calls for instance.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I am not against instrumenting this information, but it should be done by add-on modules which<br data-mce-bogus="1"></div><div>can be compiled-out, and would be runtime-disabled by default. Also, we would need to extend the</div><div>tracepoint instrumentation to identify fields which are security-sensitive, so they could be specifically</div><div>disabled at runtime. This would also require CTF2 (Common Trace Format 2) to happen, so we can</div><div>tag specific fields as containing sensitive data. Users should really know that they are tracing sensitive</div><div>information when they do so.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>So adding the instrumentation to the project is not the hard part. The hard part is making sure it is<br data-mce-bogus="1"></div><div>configurable, not captured by default, and clearly identified in the traces.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>There is a second technical issue that would need solving for capturing argv and envp: we would need<br data-mce-bogus="1"></div><div>to ensure tracepoints hooked on system calls can take page faults, which is not possible today. The<br data-mce-bogus="1"></div><div>odds of taking a page fault when reading through argv and envp in a newly forked process are probably</div><div>quite high, which would cause incomplete data. This cannot be solved in lttng-modules alone, we need<br data-mce-bogus="1"></div><div>to improve the kernel tracepoint instrumentation subsystem to do so.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Mathieu<br data-mce-bogus="1"></div></div><div><br></div><div data-marker="__SIG_POST__">-- <br></div><div>Mathieu Desnoyers<br>EfficiOS Inc.<br>http://www.efficios.com</div></div></body></html>