lttng-dev Archive on lore.kernel.org
 help / color / Atom feed
* 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, back to index

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

lttng-dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lttng-dev/0 lttng-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lttng-dev lttng-dev/ https://lore.kernel.org/lttng-dev \
		lttng-dev@lists.lttng.org
	public-inbox-index lttng-dev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.lttng.lists.lttng-dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git