nh2 / hatrace Goto Github PK

Tests in #76 uncovered that if an exception gets thrown in a hatrace conduit child processes don't get cleaned up correctly. Quoting @nh2 from discord:

...currently an exception being thrown and not caught from inside the Conduit will leak the tracee child process. That is because

genericSourceTraceForkExecvFullPathWithSink args getDetails sink = runInBoundThread $ do
  childPid <- liftIO $ forkExecvWithPtrace args

does not use any form of bracket.
What this needs is the same form of bracket that the sourceProcessWithStreams (https://hackage.haskell.org/package/conduit-extra-1.3.5/docs/Data-Conduit-Process.html#v:sourceProcessWithStreams) does:

If an exception is raised by any of the streams, the process is terminated.

It is not implemented because I haven't figured out exactly yet how to "just kill" a traced process. Maybe it's easy, but I am not sure.
We should certainly have an issue about it (currently we don't have yet).

execvp work by checking for a slash in the path; if there is a slash, it assumes it is a path (absolute or relative), if there is no slash, it looks it up in PATH.

Therefore the current behaviour of procToArgv can be unexpected in that if you run echo while having a file called echo in current directory, it will run your file, while execvp will resolve it through PATH.

Open question: will execv accept a relative path? If it will, the fix is easy, if it will not, we’ll also have to resolve relative paths.

Currently the build on macOS fails due to:

1. SIGPOLL does not exist
2. TRACEME is a little different on Darwin

I got it to build, but still not quite sure whether it works well. Hopefully, I'll figure something out, just opened the issue to let y'all know that I'll see what I can do.

To make that we need to find any char * arguments and use them for filtering

I run tests on

$ uname -a
Linux qdesktop 4.14.65-gentoo #1 SMP Sat Sep 22 15:19:49 MSK 2018 x86_64 Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz GenuineIntel GNU/Linux

and I get the following reproducible failures

Failures:

  test/HatraceSpec.hs:68:7: 
  1) Hatrace.traceCreateProcess does not hang when the traced program segfaults
       expected: ExitFailure 139
        but got: ExitFailure 11

  To rerun use: --match "/Hatrace/traceCreateProcess/does not hang when the traced program segfaults/"

  test/HatraceSpec.hs:84:7: 
  2) Hatrace.sourceTraceForkExecvFullPathWithSink allows obtaining all syscalls as a list for hello.asm
       expected: [KnownSyscall Syscall_execve,KnownSyscall Syscall_write,KnownSyscall Syscall_exit]
        but got: [KnownSyscall Syscall_rt_sigprocmask,KnownSyscall Syscall_execve,KnownSyscall Syscall_write,KnownSyscall Syscall_exit]

  To rerun use: --match "/Hatrace/sourceTraceForkExecvFullPathWithSink/allows obtaining all syscalls as a list for hello.asm/"

  test/HatraceSpec.hs:122:9: 
  3) Hatrace.sourceTraceForkExecvFullPathWithSink, subprocess tracing, can trace 'bash -c ./hello'
       expected: [Syscall_clone,Syscall_write]
        but got: [Syscall_write]

  To rerun use: --match "/Hatrace/sourceTraceForkExecvFullPathWithSink/subprocess tracing/can trace 'bash -c ./hello'/"

Randomized with seed 1551383026

I'll try to dig what could be wrong here but maybe @nh2 you could give some hints what I should check first?

When I try to run hatrace for ln -s file1 file2, then I get:

$ hatrace ln -s file1 file2
Invalid option `-s'

Usage: hatrace PROGRAM [PROGRAM_ARG] [--find-nonatomic-writes]
  scriptable strace - trace system calls, signals and more

There is a workaround for this:

hatrace -- ln -s file1 file2

But it would be better to, at least, make it clear in the docs.

I need some help getting correct packages together. Version of ptrace on my side seems to have missing peekNullTerminatedBytes, and peekNullWordTerminatedWords, and package waitpid have missing FullStatus(..) and waitpidFullStatus

Where should i get this packages from?

Full error:

cabal build
Preprocessing library for hatrace-0.1.0.0..
Building library for hatrace-0.1.0.0..
[5 of 6] Compiling System.Hatrace   ( src/System/Hatrace.hs, dist/build/System/Hatrace.o )

src/System/Hatrace.hs:115:69: error:
	Module
	‘System.Linux.Ptrace’
	does not export
	‘peekNullTerminatedBytes’
	|
115 | import           System.Linux.Ptrace (TracedProcess(..), peekBytes, peekNullTerminatedBytes, peekNullWordTerminatedWords, detach)
	|                                                                     ^^^^^^^^^^^^^^^^^^^^^^^

src/System/Hatrace.hs:115:94: error:
	Module
	‘System.Linux.Ptrace’
	does not export
	‘peekNullWordTerminatedWords’
	|
115 | import           System.Linux.Ptrace (TracedProcess(..), peekBytes, peekNullTerminatedBytes, peekNullWordTerminatedWords, detach)
	|                                                                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/System/Hatrace.hs:127:49: error:
	Module ‘System.Posix.Waitpid’ does not export ‘waitpidFullStatus’
	|
127 | import           System.Posix.Waitpid (waitpid, waitpidFullStatus, Status(..), FullStatus(..), Flag(..))
	|                                                 ^^^^^^^^^^^^^^^^^

src/System/Hatrace.hs:127:80: error:
	Module ‘System.Posix.Waitpid’ does not export ‘FullStatus(..)’
	|
127 | import           System.Posix.Waitpid (waitpid, waitpidFullStatus, Status(..), FullStatus(..), Flag(..))
	|  

A bit similar to #18 but should print paths to executables instead of integer pids.

See e.g. description at https://pchaigno.github.io/strace/2019/10/02/introducing-strace-seccomp-bpf.html#fnref:seccomp-ebpf

@nh2 's comment in #76

In the future I think it would be nice to observe invalid accesses in more detail over the API, e.g. to be able to write the let testProgram = "example-programs-build/bad-read-pointer" test such that you can assert that it does exactly 1 bad read() syscall.
Then people could use hatrace to test their programs like "this program shouldn't try to make any syscalls working on invalid data, and if it does, tell me which ones and what they do".

Similar to strace -c it should (quoting strace manpage):

Count time, calls, and errors for each system call and report a summary on program exit

(From README) Don't die on peekBytes returning EIO when the tracee passes invalid memory to the kernel; instead, peek only what's possible and print some info. That makes it possible to correctly trace processes that rely on e.g. SIGSEGV handlers.

Does this work on Windows? An immediate question for someone coming to the project, and I couldn't tell. My guess is no, as it has an unconditional dependency on unix? Does it work on mac?

It is similar to strace -y. We need a special type for file descriptors and use a special mode to change its output from integer values to mapping them to the target file paths

• Pick one of tasks from our general TODO list in the README (some of them have corresponding issues already, in such a case please assign the one you take to yourself)
• Implement any syscall you like
• Implement one of the syscalls that we have pre-selected and rated by difficulty in the gist. Check out our guide for the details how to do this.
• Solve some real-world issues with hatrace and write about them
• Last year, zappy made a PR (#38) that code-generates many useful things, but GHC gets extremely slow on it. Simplifiy it into a single, standalone file not depending on hatrace to turn it into a GHC upstream bug report about this slowness.