rsc
commented
5 years ago Based on investigation of internal Google patch, it looks like what you need is a function pprof.ReadMaps that can be called before the process enters "restricted" mode. That function would read and save whatever is needed for the maps (/proc/self/maps, anything from libraries listed there, etc) and then future profiles would reuse that. Only programs that need to run in this kind of restricted mode would need ReadMaps. (It's not something we need to ask everyone to use.)
Also, the implementation should not cache maps from profile to profile when ReadMaps has not been called. A profile taken before loading a plugin should not make a profile taken after loading the plugin have an incomplete maps list.
Given that understanding, this proposal seems quite unobtrusive and fine to add.
Will leave open for any additional discussion but we can probably accept it at our next review.
andybons
What version of Go are you using (
go version)?1.12
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?Linux Debian 4.19.16-1 x86_64 GNU/Linux
What did you do?
Certain processes run with tight seccomp filters to restrict the access to the host OS. Namely the gVisor sandbox process is prohibited from calling open(2) and openat(2) to reduce the blast radius in case the gVisor kernel gets compromised. However, when using runtime.pprof, it tries to open
/proc/self/maps(here) and executable/libs here. Those calls trip over the seccomp filters and kill the process.If it would be possible to make a call to pprof to preload this information, applications could call it before seccomp filters are installed, and thus allow the process to be profiled while remaining secure. Another option is to pre-open
/proc/self/mapsand then read when needed by the profiler.