-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: add a list of syscalls required for normal go operation #31
Comments
Add to that list |
Yes, my list is for a tiny program that doesn't do much. I'm not sure if |
I'm fairly certain Go uses it internally in the runtime for scheduling Goroutines, so while you can probably get away without it for trivial programs, I wouldn't recommend leaving it out. (I'm also quite certain blacklisting it does block it - I used it extensively as a testcase while developing the bindings. Very easy to call fork off a |
I have recently built a tool that goes through the execution path of go applications and extract all syscalls it finds. On this source code: package main
import "fmt"
func main() {
fmt.Println("test")
} this is what it extracts:
here's how to use it: go install https://github.com/pjbgf/gosystract
gosystract --template='{{- range . }}{{printf "\"%s\",\n" .Name}}{{- end}}' application-path |
A default list would certainly be useful since to come up with one isn't trivial. Just running the program under strace and collecting the observed syscalls isn't sufficient. In my experience, even running the program with the same input several times in a row gives a different sets of syscalls, e.g. And then there are non-regular circumstances that lead to syscalls you don't see usually such as In can confirm that On the other hand, I haven't seen Ideally one would have a look at the Go runtime code and grep the syscalls out of it. Since Go statically links everything (unless you import a module with C bindings), the syscalls in the resulting binary should contain all the syscalls the program and the Go runtime does. And not much else since one should expect that Go eliminates dead runtime code. I've done this for a medium size Go program of mine (gonzofilter, cf. its whitelist) which does a bit file IO, uses Go routines and does a lot of lexing and parsing: Get syscall table:
Get all direct syscalls:
Get all indirect syscalls (i.e. via
Combined I get this list:
When I link against a module with C bindings (such as this libseccomp module), of course, there are some additional syscall originating from the shared libraries (e.g. libc+libpthread+libseccomp). |
This is a moving target, meaning any new golang releases and/or Linux kernel releases can add more system calls. |
I agree with @kolyshkin, trying to maintain a default list of syscalls is going to be extremely difficult. Maybe someday we could revisit this idea, but at this point in time I think this needs to be a WONTFIX. |
Go runtime requires some syscalls for normal operation (like
mmap
for memory allocation).It seems like it's better to provide a list from the library rather than make developers guess.
At least the following are required:
The text was updated successfully, but these errors were encountered: