Skip to content
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

Jump to bottom

runtime/pprof: add ReadMaps preloading API #30609

Open
fvoznika opened this issue Mar 5, 2019 · 2 comments
Open

runtime/pprof: add ReadMaps preloading API #30609

fvoznika opened this issue Mar 5, 2019 · 2 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. help wanted NeedsFix The path to resolution is known, but the work has not been done. Proposal Proposal-Accepted
Milestone
Unplanned

Comments

@fvoznika
Copy link

fvoznika commented Mar 5, 2019

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/maps and then read when needed by the profiler.
@ianlancetaylor ianlancetaylor changed the title Profile sandboxes with seccomp filters that prohibit open/openat proposal: support preloading profiling information to permit seccomp filters Mar 5, 2019
@gopherbot gopherbot added this to the Proposal milestone Mar 5, 2019
@rsc rsc changed the title proposal: support preloading profiling information to permit seccomp filters proposal: runtime/pprof: add ReadMaps preloading API Mar 6, 2019
@rsc
Copy link
Contributor

rsc commented Mar 6, 2019

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
Copy link
Member

Accepting per @rsc's last comment.

@andybons andybons changed the title proposal: runtime/pprof: add ReadMaps preloading API runtime/pprof: add ReadMaps preloading API Mar 27, 2019
@ianlancetaylor ianlancetaylor added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels Mar 27, 2019
@ianlancetaylor ianlancetaylor modified the milestones: Proposal, Unplanned Mar 27, 2019
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. help wanted NeedsFix The path to resolution is known, but the work has not been done. Proposal Proposal-Accepted
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@rsc @andybons @ianlancetaylor @fvoznika @gopherbot