* Payload of syscall_entry_execve @ 2020-07-09 11:19 Valentin Grigorev via lttng-dev 2020-07-09 11:19 ` [lttng-dev] " Valentin Grigorev via lttng-dev 2020-07-09 13:15 ` Mathieu Desnoyers via lttng-dev 0 siblings, 2 replies; 6+ messages in thread From: Valentin Grigorev via lttng-dev @ 2020-07-09 11:19 UTC (permalink / raw) To: lttng-dev [-- Attachment #1.1: Type: text/plain, Size: 1198 bytes --] Hello! 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. I'm using LTTng live session and Babeltrace 2 C API to analyze events in online mode. 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 *`, but provided by LTTng as simple unsigned integers (the corresponding fields in Babaltrace2 event payload have type BT_FIELD_CLASS_TYPE_UNSIGNED_INTEGER, 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 cases, events produced by LTTng are analyzed by another process and often even offline, so these pointers became completely unuseful. 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 information from LTTng. P.S. I consider getting this information from /proc/pid/cmdline, but it is not looking like a clean solution. Best regards. Valentin Grigorev [-- Attachment #1.2: Type: text/html, Size: 1556 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 6+ messages in thread
* [lttng-dev] Payload of syscall_entry_execve 2020-07-09 11:19 Payload of syscall_entry_execve Valentin Grigorev via lttng-dev @ 2020-07-09 11:19 ` Valentin Grigorev via lttng-dev 2020-07-09 13:15 ` Mathieu Desnoyers via lttng-dev 1 sibling, 0 replies; 6+ messages in thread From: Valentin Grigorev via lttng-dev @ 2020-07-09 11:19 UTC (permalink / raw) To: lttng-dev [-- Attachment #1.1: Type: text/plain, Size: 1198 bytes --] Hello! 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. I'm using LTTng live session and Babeltrace 2 C API to analyze events in online mode. 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 *`, but provided by LTTng as simple unsigned integers (the corresponding fields in Babaltrace2 event payload have type BT_FIELD_CLASS_TYPE_UNSIGNED_INTEGER, 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 cases, events produced by LTTng are analyzed by another process and often even offline, so these pointers became completely unuseful. 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 information from LTTng. P.S. I consider getting this information from /proc/pid/cmdline, but it is not looking like a clean solution. Best regards. Valentin Grigorev [-- Attachment #1.2: Type: text/html, Size: 1556 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Payload of syscall_entry_execve 2020-07-09 11:19 Payload of syscall_entry_execve Valentin Grigorev via lttng-dev 2020-07-09 11:19 ` [lttng-dev] " Valentin Grigorev via lttng-dev @ 2020-07-09 13:15 ` Mathieu Desnoyers via lttng-dev 2020-07-09 13:15 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev 2020-07-09 13:22 ` Valentin Grigorev via lttng-dev 1 sibling, 2 replies; 6+ messages in thread From: Mathieu Desnoyers via lttng-dev @ 2020-07-09 13:15 UTC (permalink / raw) To: Valentin Grigorev; +Cc: lttng-dev [-- Attachment #1.1: Type: text/plain, Size: 2782 bytes --] ----- On Jul 9, 2020, at 7:19 AM, lttng-dev <lttng-dev@lists.lttng.org> wrote: > Hello! > 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. > I'm using LTTng live session and Babeltrace 2 C API to analyze events in online > mode. > 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 *`, > but provided by LTTng as simple unsigned integers (the corresponding fields in > Babaltrace2 event payload have type BT_FIELD_CLASS_TYPE_UNSIGNED_INTEGER, > 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 > cases, events produced by LTTng are analyzed by another process and often even > offline, so these pointers became completely unuseful. > 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 > information from LTTng. > P.S. I consider getting this information from /proc/pid/cmdline, but it is not > looking like a clean solution. The main reason why we don't implement this kind of instrumentation is because it would then capture security-sensitive data into the trace. Likewise for payload of read() and write() system calls for instance. I am not against instrumenting this information, but it should be done by add-on modules which can be compiled-out, and would be runtime-disabled by default. Also, we would need to extend the tracepoint instrumentation to identify fields which are security-sensitive, so they could be specifically disabled at runtime. This would also require CTF2 (Common Trace Format 2) to happen, so we can tag specific fields as containing sensitive data. Users should really know that they are tracing sensitive information when they do so. So adding the instrumentation to the project is not the hard part. The hard part is making sure it is configurable, not captured by default, and clearly identified in the traces. There is a second technical issue that would need solving for capturing argv and envp: we would need to ensure tracepoints hooked on system calls can take page faults, which is not possible today. The odds of taking a page fault when reading through argv and envp in a newly forked process are probably quite high, which would cause incomplete data. This cannot be solved in lttng-modules alone, we need to improve the kernel tracepoint instrumentation subsystem to do so. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com [-- Attachment #1.2: Type: text/html, Size: 4139 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lttng-dev] Payload of syscall_entry_execve 2020-07-09 13:15 ` Mathieu Desnoyers via lttng-dev @ 2020-07-09 13:15 ` Mathieu Desnoyers via lttng-dev 2020-07-09 13:22 ` Valentin Grigorev via lttng-dev 1 sibling, 0 replies; 6+ messages in thread From: Mathieu Desnoyers via lttng-dev @ 2020-07-09 13:15 UTC (permalink / raw) To: Valentin Grigorev; +Cc: lttng-dev [-- Attachment #1.1: Type: text/plain, Size: 2782 bytes --] ----- On Jul 9, 2020, at 7:19 AM, lttng-dev <lttng-dev@lists.lttng.org> wrote: > Hello! > 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. > I'm using LTTng live session and Babeltrace 2 C API to analyze events in online > mode. > 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 *`, > but provided by LTTng as simple unsigned integers (the corresponding fields in > Babaltrace2 event payload have type BT_FIELD_CLASS_TYPE_UNSIGNED_INTEGER, > 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 > cases, events produced by LTTng are analyzed by another process and often even > offline, so these pointers became completely unuseful. > 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 > information from LTTng. > P.S. I consider getting this information from /proc/pid/cmdline, but it is not > looking like a clean solution. The main reason why we don't implement this kind of instrumentation is because it would then capture security-sensitive data into the trace. Likewise for payload of read() and write() system calls for instance. I am not against instrumenting this information, but it should be done by add-on modules which can be compiled-out, and would be runtime-disabled by default. Also, we would need to extend the tracepoint instrumentation to identify fields which are security-sensitive, so they could be specifically disabled at runtime. This would also require CTF2 (Common Trace Format 2) to happen, so we can tag specific fields as containing sensitive data. Users should really know that they are tracing sensitive information when they do so. So adding the instrumentation to the project is not the hard part. The hard part is making sure it is configurable, not captured by default, and clearly identified in the traces. There is a second technical issue that would need solving for capturing argv and envp: we would need to ensure tracepoints hooked on system calls can take page faults, which is not possible today. The odds of taking a page fault when reading through argv and envp in a newly forked process are probably quite high, which would cause incomplete data. This cannot be solved in lttng-modules alone, we need to improve the kernel tracepoint instrumentation subsystem to do so. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com [-- Attachment #1.2: Type: text/html, Size: 4139 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Payload of syscall_entry_execve 2020-07-09 13:15 ` Mathieu Desnoyers via lttng-dev 2020-07-09 13:15 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev @ 2020-07-09 13:22 ` Valentin Grigorev via lttng-dev 2020-07-09 13:22 ` [lttng-dev] " Valentin Grigorev via lttng-dev 1 sibling, 1 reply; 6+ messages in thread From: Valentin Grigorev via lttng-dev @ 2020-07-09 13:22 UTC (permalink / raw) To: Mathieu Desnoyers; +Cc: lttng-dev [-- Attachment #1.1: Type: text/plain, Size: 71 bytes --] Thanks for the information, Mathieu Best regard, > Valentin Grigorev [-- Attachment #1.2: Type: text/html, Size: 422 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lttng-dev] Payload of syscall_entry_execve 2020-07-09 13:22 ` Valentin Grigorev via lttng-dev @ 2020-07-09 13:22 ` Valentin Grigorev via lttng-dev 0 siblings, 0 replies; 6+ messages in thread From: Valentin Grigorev via lttng-dev @ 2020-07-09 13:22 UTC (permalink / raw) To: Mathieu Desnoyers; +Cc: lttng-dev [-- Attachment #1.1: Type: text/plain, Size: 71 bytes --] Thanks for the information, Mathieu Best regard, > Valentin Grigorev [-- Attachment #1.2: Type: text/html, Size: 422 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-07-09 13:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-09 11:19 Payload of syscall_entry_execve Valentin Grigorev via lttng-dev 2020-07-09 11:19 ` [lttng-dev] " Valentin Grigorev via lttng-dev 2020-07-09 13:15 ` Mathieu Desnoyers via lttng-dev 2020-07-09 13:15 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev 2020-07-09 13:22 ` Valentin Grigorev via lttng-dev 2020-07-09 13:22 ` [lttng-dev] " Valentin Grigorev via lttng-dev
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).