Skip to content
This repository has been archived by the owner on Dec 30, 2021. It is now read-only.

Compare systrace against fsatrace, bigbro, traced-fs #38

Open
rrnewton opened this issue Apr 29, 2019 · 4 comments
Open

Compare systrace against fsatrace, bigbro, traced-fs #38

rrnewton opened this issue Apr 29, 2019 · 4 comments

Comments

@rrnewton
Copy link
Collaborator

I don't think we're close to a "release" (i.e. advertising systrace more widely) yet.

But with a future release in mind, it would be good to have a piece of documentation somewhere comparing against these other tracing methods.

@rrnewton
Copy link
Collaborator Author

With all these names that have "trace" as a suffix, I was wondering if there is something that characterizes what systrace does better than "sys". Alas it looks like "bintrace" is taken...

@wangbj
Copy link
Collaborator

wangbj commented Apr 29, 2019

It's hard to find a good naming, I chose it without too much thoughts, please suggest if you find any thing better :)

@wangbj
Copy link
Collaborator

wangbj commented Apr 29, 2019

traced-fs doesn't have any update for 3+ years, assume it was succeeded by fsatrace. fsatrace is based on LD_PRELOAD, it also only traces several filesystem related syscalls (interestingly, it also LD_PRELOAD fopen, which is libc function). So it has the limitations of LD_PRELOAD, such as:

  • not able to intercept syscalls inside library itself, such as syscalls inside libc.so.6;
  • not able to intercept static binaries

@wangbj
Copy link
Collaborator

wangbj commented Apr 29, 2019

bigbro seems use the similar approach as detTrace, by using seccomp and ptrace, Like fsatrace, it only traps filesystem related APIs, and patching is a non-goal as far as I can see.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants