Chen Jingpiao's GSoC status report - #2 of #13

[Chen Jingpiao]

Hello, strace community!

Last week, I focus on the following part of the project.

* We must trace the tracee's child process.

We must the trace tracee's child process because the tracee's child process also
set the seccomp filter. It seems a bad idea to use seccomp filter when we do not
use -f option. because trace the tracee's child process will make strace run
slow and the child process will fail when it call ptrace(PTRACE_TRACME), which
behavior different from current strace. About this problem, I look forward to
getting the feedback. Thank you.

A patch base on my previous code [1].

* How to initialize seccomp bpf?

Now I do not use libseccomp. I made a mistake in the previous discussion,
libseccomp can construct the BPF that support multiple architectures. Here is an
example [2]. But if we add a syscall number range, libseccomp cannot do that.
I will do more research.

* How to optimization of the BPF code?

Currently, we use following condition to test a syscall add to seccomp bpf or not.

	static bool
	trace_by_seccomp(unsigned int scno, unsigned int p)
	{
		return !sysent_vec[p][scno].sys_func
		       || sysent_vec[p][scno].sys_flags & TRACE_INDIRECT_SUBCALL
		       || strcmp("execve", sysent_vec[p][scno].sys_name) == 0
		       || is_number_in_set_array(scno, trace_set, p);
	}

On x86_64 environment, using command: strace -etrace=none PROG.
Generate more than 247 instructions. We should use the interval to replace the
single instruction. If libseccomp cannot do that, keeping current way of
construct the seccomp BPF is a good idea.

Next week, I will continue to focus on the above problem, and fix the code
according to the feedback. Thank you.

[1] https://paste.debian.net/1027056
[2] https://paste.debian.net/1027054
--
Chen Jingpiao