summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/platform/ptrace
AgeCommit message (Collapse)Author
2019-07-03Avoid importing platforms from many source filesAndrei Vagin
PiperOrigin-RevId: 256494243
2019-06-28platform/ptrace: return more detailed errorsAndrei Vagin
Right now, if we can't create a stub process, we will see this error: panic: unable to activate mm: resource temporarily unavailable It would be better to know the root cause of this "resource temporarily unavailable". PiperOrigin-RevId: 255656831
2019-06-27Fix various spelling issues in the documentationMichael Pratt
Addresses obvious typos, in the documentation only. COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/443 from Pixep:fix/documentation-spelling 4d0688164eafaf0b3010e5f4824b35d1e7176d65 PiperOrigin-RevId: 255477779
2019-06-27gvisor/ptrace: grub initial thread registers only onceAndrei Vagin
PiperOrigin-RevId: 255465635
2019-06-24Add O_EXITKILL to ptrace options.Adin Scannell
This prevents a race before PDEATH_SIG can take effect during a sentry crash. Discovered and solution by avagin@. PiperOrigin-RevId: 254871534
2019-06-24platform/ptrace: specify PTRACE_O_TRACEEXIT for stub-processesAndrei Vagin
The tracee is stopped early during process exit, when registers are still available, allowing the tracer to see where the exit occurred, whereas the normal exit notifi? cation is done after the process is finished exiting. Without this option, dumpAndPanic fails to get registers. PiperOrigin-RevId: 254852917
2019-06-13Update canonical repository.Adin Scannell
This can be merged after: https://github.com/google/gvisor-website/pull/77 or https://github.com/google/gvisor-website/pull/78 PiperOrigin-RevId: 253132620
2019-06-12gvisor/ptrace: print guest registers if a stub stopped with unexpected codeAndrei Vagin
PiperOrigin-RevId: 252855280
2019-06-10Move //pkg/sentry/platform/procid to //pkg/procid.Jamie Liu
PiperOrigin-RevId: 252501653
2019-05-30Add build guard to files using go:linknameFabricio Voznika
Funcion signatures are not validated during compilation. Since they are not exported, they can change at any time. The guard ensures that they are verified at least on every version upgrade. PiperOrigin-RevId: 250733742
2019-04-29Change copyright notice to "The gVisor Authors"Michael Pratt
Based on the guidelines at https://opensource.google.com/docs/releasing/authors/. 1. $ rg -l "Google LLC" | xargs sed -i 's/Google LLC.*/The gVisor Authors./' 2. Manual fixup of "Google Inc" references. 3. Add AUTHORS file. Authors may request to be added to this file. 4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS. Fixes #209 PiperOrigin-RevId: 245823212 Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
2019-04-29Allow and document bug ids in gVisor codebase.Nicolas Lacasse
PiperOrigin-RevId: 245818639 Change-Id: I03703ef0fb9b6675955637b9fe2776204c545789
2019-03-14Decouple filemem from platform and move it to pgalloc.MemoryFile.Jamie Liu
This is in preparation for improved page cache reclaim, which requires greater integration between the page cache and page allocator. PiperOrigin-RevId: 238444706 Change-Id: Id24141b3678d96c7d7dc24baddd9be555bffafe4
2019-03-12Clarify the platform.File interface.Jamie Liu
- Redefine some memmap.Mappable, platform.File, and platform.Memory semantics in terms of File reference counts (no functional change). - Make AddressSpace.MapFile take a platform.File instead of a raw FD, and replace platform.File.MapInto with platform.File.FD. This allows kvm.AddressSpace.MapFile to always use platform.File.MapInternal instead of maintaining its own (redundant) cache of file mappings in the sentry address space. PiperOrigin-RevId: 238044504 Change-Id: Ib73a11e4275c0da0126d0194aa6c6017a9cef64f
2019-03-01ptrace: drop old FIXMEAdin Scannell
The globalPool uses a sync.Once mechanism for initialization, and no cleanup is strictly required. It's not really feasible to have the platform implement a full creation -> destruction cycle (due to the way filters are assumed to be installed), so drop the FIXME. PiperOrigin-RevId: 236385278 Change-Id: I98ac660ed58cc688d8a07147d16074a3e8181314
2019-01-31Remove license commentsMichael Pratt
Nothing reads them and they can simply get stale. Generated with: $ sed -i "s/licenses(\(.*\)).*/licenses(\1)/" **/BUILD PiperOrigin-RevId: 231818945 Change-Id: Ibc3f9838546b7e94f13f217060d31f4ada9d4bf0
2018-12-18Add BPFAction type with StringerFabricio Voznika
PiperOrigin-RevId: 226018694 Change-Id: I98965e26fe565f37e98e5df5f997363ab273c91b
2018-12-10Validate FS_BASE in Task.CloneMichael Pratt
arch_prctl already verified that the new FS_BASE was canonical, but Task.Clone did not. Centralize these checks in the arch packages. Failure to validate could cause an error in PTRACE_SET_REGS when we try to switch to the app. PiperOrigin-RevId: 224862398 Change-Id: Iefe63b3f9aa6c4810326b8936e501be3ec407f14
2018-12-04Remove initRegs arg from cloneMichael Pratt
It is always the same as t.initRegs. PiperOrigin-RevId: 224085550 Change-Id: I5cc4ddc3b481d4748c3c43f6f4bb50da1dbac694
2018-11-20Use RET_KILL_PROCESS if available in kernelFabricio Voznika
RET_KILL_THREAD doesn't work well for Go because it will kill only the offending thread and leave the process hanging. RET_TRAP can be masked out and it's not guaranteed to kill the process. RET_KILL_PROCESS is available since 4.14. For older kernel, continue to use RET_TRAP as this is the best option (likely to kill process, easy to debug). PiperOrigin-RevId: 222357867 Change-Id: Icc1d7d731274b16c2125b7a1ba4f7883fbdb2cbd
2018-10-24Use TRAP to simplify vsyscall emulation.Adin Scannell
PiperOrigin-RevId: 218592058 Change-Id: I373a2d813aa6cc362500dd5a894c0b214a1959d7
2018-10-24Run ptrace stubs in their own session and process group.Nicolas Lacasse
Pseudoterminal job control signals are meant to be received and handled by the sandbox process, but if the ptrace stubs are running in the same process group, they will receive the signals as well and inject then into the sentry kernel. This can result in duplicate signals being delivered (often to the wrong process), or a sentry panic if the ptrace stub is inactive. This CL makes the ptrace stub run in a new session. PiperOrigin-RevId: 218536851 Change-Id: Ie593c5687439bbfbf690ada3b2197ea71ed60a0e
2018-10-23Track paths and provide a rename hook.Adin Scannell
This change also adds extensive testing to the p9 package via mocks. The sanity checks and type checks are moved from the gofer into the core package, where they can be more easily validated. PiperOrigin-RevId: 218296768 Change-Id: I4fc3c326e7bf1e0e140a454cbacbcc6fd617ab55
2018-10-19Use correct company name in copyright headerIan Gudger
PiperOrigin-RevId: 217951017 Change-Id: Ie08bf6987f98467d07457bcf35b5f1ff6e43c035
2018-10-10Add seccomp filter configuration to ptrace stubs.Adin Scannell
This is a defense-in-depth measure. If the sentry is compromised, this prevents system call injection to the stubs. There is some complexity with respect to ptrace and seccomp interactions, so this protection is not really available for kernel versions < 4.8; this is detected dynamically. Note that this also solves the vsyscall emulation issue by adding in appropriate trapping for those system calls. It does mean that a compromised sentry could theoretically inject these into the stub (ignoring the trap and resume, thereby allowing execution), but they are harmless. PiperOrigin-RevId: 216647581 Change-Id: Id06c232cbac1f9489b1803ec97f83097fcba8eb8
2018-09-14Avoid reuse of pending SignalInfo objectsnewmanwang
runApp.execute -> Task.SendSignal -> sendSignalLocked -> sendSignalTimerLocked -> pendingSignals.enqueue assumes that it owns the arch.SignalInfo returned from platform.Context.Switch. On the other hand, ptrace.context.Switch assumes that it owns the returned SignalInfo and can safely reuse it on the next call to Switch. The KVM platform always returns a unique SignalInfo. This becomes a problem when the returned signal is not immediately delivered, allowing a future signal in Switch to change the previous pending SignalInfo. This is noticeable in #38 when external SIGINTs are delivered from the PTY slave FD. Note that the ptrace stubs are in the same process group as the sentry, so they are eligible to receive the PTY signals. This should probably change, but is not the only possible cause of this bug. Updates #38 Original change by newmanwang <wcs1011@gmail.com>, updated by Michael Pratt <mpratt@google.com>. Change-Id: I5383840272309df70a29f67b25e8221f933622cd PiperOrigin-RevId: 213071072
2018-07-27stateify: support explicit annotation mode; convert refs and stack packages.Zhaozhong Ni
We have been unnecessarily creating too many savable types implicitly. PiperOrigin-RevId: 206334201 Change-Id: Idc5a3a14bfb7ee125c4f2bb2b1c53164e46f29a8
2018-07-16Add CPUID faulting for ptrace and KVM.Adin Scannell
PiperOrigin-RevId: 204858314 Change-Id: I8252bf8de3232a7a27af51076139b585e73276d4
2018-06-26Change SIGCHLD to SIGKILL in ptrace stubs.Adin Scannell
If the child stubs are killed by any unmaskable signal (e.g. SIGKILL), then the parent process will similarly be killed, resulting in the death of all other stubs. The effect of this is that if the OOM killer selects and kills a stub, the effect is the same as though the OOM killer selected and killed the sentry. PiperOrigin-RevId: 202219984 Change-Id: I0b638ce7e59e0a0f4d5cde12a7d05242673049d7
2018-05-11Remove error return from AddressSpace.Release()Michael Pratt
PiperOrigin-RevId: 196291289 Change-Id: Ie3487be029850b0b410b82416750853a6c4a2b00
2018-04-28Check in gVisor.Googler
PiperOrigin-RevId: 194583126 Change-Id: Ica1d8821a90f74e7e745962d71801c598c652463
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-05 05:36:33 +0000