summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/kernel
AgeCommit message (Collapse)Author
2020-12-11Merge release-20201208.0-32-g305a45655 (automated)gVisor bot
2020-12-11Merge release-20201208.0-31-g4cba3904f (automated)gVisor bot
2020-12-11Remove existing nogo exceptions.Adin Scannell
PiperOrigin-RevId: 347047550
2020-12-11Merge release-20201208.0-26-g73eccab91 (automated)gVisor bot
2020-12-11Make semctl IPC_INFO cmd return the index of highest used entry.Jing Chen
PiperOrigin-RevId: 346973338
2020-12-05Merge release-20201130.0-44-g8a45c8161 (automated)gVisor bot
2020-12-04Merge release-20201130.0-36-ga78cef0ed (automated)gVisor bot
2020-12-03Implement command IPC_INFO for semctl.Jing Chen
PiperOrigin-RevId: 345589628
2020-12-03Merge release-20201130.0-30-g6f60a2b0a (automated)gVisor bot
2020-12-03Implement `fcntl` options `F_GETSIG` and `F_SETSIG`.Etienne Perot
These options allow overriding the signal that gets sent to the process when I/O operations are available on the file descriptor, rather than the default `SIGIO` signal. Doing so also populates `siginfo` to contain extra information about which file descriptor caused the event (`si_fd`) and what events happened on it (`si_band`). The logic around which FD is populated within `si_fd` matches Linux's, which means it has some weird edge cases where that value may not actually refer to a file descriptor that is still valid. This CL also ports extra S/R logic regarding async handler in VFS2. Without this, async I/O handlers aren't properly re-registered after S/R. PiperOrigin-RevId: 345436598
2020-12-03Merge release-20201130.0-27-gf559db569 (automated)gVisor bot
2020-12-02Do not unconditionally allocate in kernel.FDTable.setAll().Jamie Liu
`slice := *(*[]unsafe.Pointer)(...)` makes a copy of the slice header, which then escapes because of the conditional `atomic.StorePointer(&f.slice, &slice)` from table expansion. This occurs even when the table doesn't expand, and when it can't (e.g. `close()` => `f.setAll(nil)`). Fix this by avoiding the copy until after table expansion. Before this CL: ``` TEXT pkg/sentry/kernel/kernel.(*FDTable).setAll(SB) pkg/sentry/kernel/fd_table_unsafe.go fd_table_unsafe.go:119 0x7f00005f50e0 64488b0c25f8ffffff MOVQ FS:0xfffffff8, CX fd_table_unsafe.go:119 0x7f00005f50e9 483b6110 CMPQ 0x10(CX), SP fd_table_unsafe.go:119 0x7f00005f50ed 0f864d040000 JBE 0x7f00005f5540 fd_table_unsafe.go:119 0x7f00005f50f3 4883c480 ADDQ $-0x80, SP fd_table_unsafe.go:119 0x7f00005f50f7 48896c2478 MOVQ BP, 0x78(SP) fd_table_unsafe.go:119 0x7f00005f50fc 488d6c2478 LEAQ 0x78(SP), BP fd_table_unsafe.go:120 0x7f00005f5101 488b8424a8000000 MOVQ 0xa8(SP), AX fd_table_unsafe.go:120 0x7f00005f5109 4885c0 TESTQ AX, AX fd_table_unsafe.go:120 0x7f00005f510c 7411 JE 0x7f00005f511f fd_table_unsafe.go:120 0x7f00005f510e 488b8c24b0000000 MOVQ 0xb0(SP), CX fd_table_unsafe.go:120 0x7f00005f5116 4885c9 TESTQ CX, CX fd_table_unsafe.go:120 0x7f00005f5119 0f8500040000 JNE 0x7f00005f551f fd_table_unsafe.go:124 0x7f00005f511f 488d05da115700 LEAQ 0x5711da(IP), AX fd_table_unsafe.go:124 0x7f00005f5126 48890424 MOVQ AX, 0(SP) fd_table_unsafe.go:124 0x7f00005f512a e8d19fa1ff CALL runtime.newobject(SB) fd_table_unsafe.go:124 0x7f00005f512f 488b7c2408 MOVQ 0x8(SP), DI fd_table_unsafe.go:124 0x7f00005f5134 488b842488000000 MOVQ 0x88(SP), AX fd_table_unsafe.go:124 0x7f00005f513c 488b4820 MOVQ 0x20(AX), CX fd_table_unsafe.go:124 0x7f00005f5140 488b5108 MOVQ 0x8(CX), DX fd_table_unsafe.go:124 0x7f00005f5144 488b19 MOVQ 0(CX), BX fd_table_unsafe.go:124 0x7f00005f5147 488b4910 MOVQ 0x10(CX), CX fd_table_unsafe.go:124 0x7f00005f514b 48895708 MOVQ DX, 0x8(DI) fd_table_unsafe.go:124 0x7f00005f514f 48894f10 MOVQ CX, 0x10(DI) fd_table_unsafe.go:124 0x7f00005f5153 833df6e1120100 CMPL $0x0, runtime.writeBarrier(SB) fd_table_unsafe.go:124 0x7f00005f515a 660f1f440000 NOPW 0(AX)(AX*1) fd_table_unsafe.go:124 0x7f00005f5160 0f8589030000 JNE 0x7f00005f54ef fd_table_unsafe.go:124 0x7f00005f5166 48891f MOVQ BX, 0(DI) fd_table_unsafe.go:124 0x7f00005f5169 48897c2470 MOVQ DI, 0x70(SP) fd_table_unsafe.go:127 0x7f00005f516e 8bb424a0000000 MOVL 0xa0(SP), SI fd_table_unsafe.go:127 0x7f00005f5175 39d6 CMPL DX, SI fd_table_unsafe.go:127 0x7f00005f5177 0f8c5f030000 JL 0x7f00005f54dc ... ``` After this CL: ``` TEXT pkg/sentry/kernel/kernel.(*FDTable).setAll(SB) pkg/sentry/kernel/fd_table_unsafe.go fd_table_unsafe.go:119 0x7f00005f50e0 64488b0c25f8ffffff MOVQ FS:0xfffffff8, CX fd_table_unsafe.go:119 0x7f00005f50e9 488d4424e8 LEAQ -0x18(SP), AX fd_table_unsafe.go:119 0x7f00005f50ee 483b4110 CMPQ 0x10(CX), AX fd_table_unsafe.go:119 0x7f00005f50f2 0f868e040000 JBE 0x7f00005f5586 fd_table_unsafe.go:119 0x7f00005f50f8 4881ec98000000 SUBQ $0x98, SP fd_table_unsafe.go:119 0x7f00005f50ff 4889ac2490000000 MOVQ BP, 0x90(SP) fd_table_unsafe.go:119 0x7f00005f5107 488dac2490000000 LEAQ 0x90(SP), BP fd_table_unsafe.go:120 0x7f00005f510f 488b9424c0000000 MOVQ 0xc0(SP), DX fd_table_unsafe.go:120 0x7f00005f5117 660f1f840000000000 NOPW 0(AX)(AX*1) fd_table_unsafe.go:120 0x7f00005f5120 4885d2 TESTQ DX, DX fd_table_unsafe.go:120 0x7f00005f5123 0f8406040000 JE 0x7f00005f552f fd_table_unsafe.go:120 0x7f00005f5129 488b9c24c8000000 MOVQ 0xc8(SP), BX fd_table_unsafe.go:120 0x7f00005f5131 4885db TESTQ BX, BX fd_table_unsafe.go:120 0x7f00005f5134 0f852b040000 JNE 0x7f00005f5565 fd_table_unsafe.go:124 0x7f00005f513a 488bb424a0000000 MOVQ 0xa0(SP), SI fd_table_unsafe.go:124 0x7f00005f5142 488b7e20 MOVQ 0x20(SI), DI fd_table_unsafe.go:127 0x7f00005f5146 4c8b4708 MOVQ 0x8(DI), R8 fd_table_unsafe.go:127 0x7f00005f514a 448b8c24b8000000 MOVL 0xb8(SP), R9 fd_table_unsafe.go:127 0x7f00005f5152 4539c1 CMPL R8, R9 fd_table_unsafe.go:127 0x7f00005f5155 0f8d4a020000 JGE 0x7f00005f53a5 ... ``` PiperOrigin-RevId: 345363242
2020-12-02Merge release-20201117.0-90-gb26dd6d9b (automated)gVisor bot
2020-12-02Add /proc/sys/kernel/sem.Jing Chen
PiperOrigin-RevId: 345178956
2020-11-18Merge release-20201109.0-72-gd6e788a8d (automated)gVisor bot
2020-11-18Add a few syslog messages.Etienne Perot
PiperOrigin-RevId: 343123278
2020-11-17Merge release-20201109.0-53-g267560d15 (automated)gVisor bot
2020-11-16Reset watchdog timer between sendfile() iterations.Jamie Liu
As part of this, change Task.interrupted() to not drain Task.interruptChan, and do so explicitly using new function Task.unsetInterrupted() instead. PiperOrigin-RevId: 342768365
2020-11-14Merge release-20201030.0-96-g182c12601 (automated)gVisor bot
2020-11-13Log task goroutine IDs in the sentry watchdog.Jamie Liu
PiperOrigin-RevId: 342373580
2020-11-13Merge release-20201030.0-94-ga1cb52447 (automated)gVisor bot
2020-11-13Check for misuse of kernel.Task as context.Context.Jamie Liu
Checks in Task.block() and Task.Value() are conditional on race detection being enabled, since these functions are relatively hot. Checks in Task.SleepStart() and Task.UninterruptibleSleepStart() are enabled unconditionally, since these functions are not thought to lie on any critical paths, and misuse of these functions is required for b/168241471 to manifest. PiperOrigin-RevId: 342342175
2020-11-13Merge release-20201030.0-79-g62db1fad2 (automated)gVisor bot
2020-11-12Fix misuses of kernel.Task as context.Context.Jamie Liu
kernel.Task can only be used as context.Context by that Task's task goroutine. This is violated in at least two places: - In any case where one thread accesses the /proc/[tid] of any other thread, passing the kernel.Task for [tid] as the context.Context is incorrect. - Task.rebuildTraceContext() may be called by Kernel.RebuildTraceContexts() outside the scope of any task goroutine. Fix these (as well as a data race on Task.traceContext discovered during the course of finding the latter). PiperOrigin-RevId: 342174404
2020-11-13Merge release-20201030.0-75-g468caff45 (automated)gVisor bot
2020-11-12Rename kernel.TaskContext to kernel.TaskImage.Jamie Liu
This reduces confusion with context.Context (which is also relevant to kernel.Tasks) and is consistent with existing function kernel.LoadTaskImage(). PiperOrigin-RevId: 342167298
2020-11-09Merge release-20201030.0-53-g0fb5353e4 (automated)gVisor bot
2020-11-09Initialize references with a value of 1.Dean Deng
This lets us avoid treating a value of 0 as one reference. All references using the refsvfs2 template must call InitRefs() before the reference is incremented/decremented, or else a panic will occur. Therefore, it should be pretty easy to identify missing InitRef calls during testing. Updates #1486. PiperOrigin-RevId: 341411151
2020-11-07Merge release-20201030.0-47-g3ac00fe9c (automated)gVisor bot
2020-11-06Implement command GETNCNT for semctl.Jing Chen
PiperOrigin-RevId: 341154192
2020-11-03Merge release-20201027.0-63-g1cfa8d58f (automated)gVisor bot
2020-11-03Fix more nogo testsTing-Yu Wang
PiperOrigin-RevId: 340536306
2020-11-03Merge release-20201027.0-61-g723464ec5 (automated)gVisor bot
2020-11-03Make pipe min/max sizes match linux.Nicolas Lacasse
The default pipe size already matched linux, and is unchanged. Furthermore `atomicIOBytes` is made a proper constant (as it is in Linux). We were plumbing usermem.PageSize everywhere, so this is no functional change. PiperOrigin-RevId: 340497006
2020-11-03Merge release-20201027.0-56-g1a3f417f4 (automated)gVisor bot
2020-11-02Implement command GETZCNT for semctl.Jing Chen
PiperOrigin-RevId: 340389884
2020-10-30Merge release-20201019.0-111-g9ad864628 (automated)gVisor bot
2020-10-30Separate kernel.Task.AsCopyContext() into CopyContext() and OwnCopyContext().Jamie Liu
kernel.copyContext{t} cannot be used outside of t's task goroutine, for three reasons: - t.CopyScratchBuffer() is task-goroutine-local. - Calling t.MemoryManager() without running on t's task goroutine or locking t.mu violates t.MemoryManager()'s preconditions. - kernel.copyContext passes t as context.Context to MM IO methods, which is illegal outside of t's task goroutine (cf. kernel.Task.Value()). Fix this by splitting AsCopyContext() into CopyContext() (which takes an explicit context.Context and is usable outside of the task goroutine) and OwnCopyContext() (which uses t as context.Context, but is only usable by t's task goroutine). PiperOrigin-RevId: 339933809
2020-10-29Merge release-20201019.0-95-g3b4674ffe (automated)gVisor bot
2020-10-27Merge release-20201019.0-65-gfacb2fb9c (automated)gVisor bot
2020-10-26Implement command IPC_STAT for semctl.Jing Chen
PiperOrigin-RevId: 339166854
2020-10-24Merge release-20201019.0-51-g9f87400f0 (automated)gVisor bot
2020-10-23Support VFS2 save/restore.Jamie Liu
Inode number consistency checks are now skipped in save/restore tests for reasons described in greatest detail in StatTest.StateDoesntChangeAfterRename. They pass in VFS1 due to the bug described in new test case SimpleStatTest.DifferentFilesHaveDifferentDeviceInodeNumberPairs. Fixes #1663 PiperOrigin-RevId: 338776148
2020-10-23Merge release-20201019.0-34-g9ca66ec59 (automated)gVisor bot
2020-10-23Rewrite reference leak checker without finalizers.Dean Deng
Our current reference leak checker uses finalizers to verify whether an object has reached zero references before it is garbage collected. There are multiple problems with this mechanism, so a rewrite is in order. With finalizers, there is no way to guarantee that a finalizer will run before the program exits. When an unreachable object with a finalizer is garbage collected, its finalizer will be added to a queue and run asynchronously. The best we can do is run garbage collection upon sandbox exit to make sure that all finalizers are enqueued. Furthermore, if there is a chain of finalized objects, e.g. A points to B points to C, garbage collection needs to run multiple times before all of the finalizers are enqueued. The first GC run will register the finalizer for A but not free it. It takes another GC run to free A, at which point B's finalizer can be registered. As a result, we need to run GC as many times as the length of the longest such chain to have a somewhat reliable leak checker. Finally, a cyclical chain of structs pointing to one another will never be garbage collected if a finalizer is set. This is a well-known issue with Go finalizers (https://github.com/golang/go/issues/7358). Using leak checking on filesystem objects that produce cycles will not work and even result in memory leaks. The new leak checker stores reference counted objects in a global map when leak check is enabled and removes them once they are destroyed. At sandbox exit, any remaining objects in the map are considered as leaked. This provides a deterministic way of detecting leaks without relying on the complexities of finalizers and garbage collection. This approach has several benefits over the former, including: - Always detects leaks of objects that should be destroyed very close to sandbox exit. The old checker very rarely detected these leaks, because it relied on garbage collection to be run in a short window of time. - Panics if we forgot to enable leak check on a ref-counted object (we will try to remove it from the map when it is destroyed, but it will never have been added). - Can store extra logging information in the map values without adding to the size of the ref count struct itself. With the size of just an int64, the ref count object remains compact, meaning frequent operations like IncRef/DecRef are more cache-efficient. - Can aggregate leak results in a single report after the sandbox exits. Instead of having warnings littered in the log, which were non-deterministically triggered by garbage collection, we can print all warning messages at once. Note that this could also be a limitation--the sandbox must exit properly for leaks to be detected. Some basic benchmarking indicates that this change does not significantly affect performance when leak checking is enabled, which is understandable since registering/unregistering is only done once for each filesystem object. Updates #1486. PiperOrigin-RevId: 338685972
2020-10-22Merge release-20201019.0-28-g4e389c785 (automated)gVisor bot
2020-10-21Check for nil in kernel.FSContext functions.Dean Deng
Reported-by: syzbot+c0e175d2b10708314eb3@syzkaller.appspotmail.com PiperOrigin-RevId: 338386575
2020-10-20Merge release-20201005.0-107-gdcc1b71f1 (automated)gVisor bot
2020-10-19Fix reference counting on kcov mappings.Dean Deng
Reported-by: syzbot+078580ce5dd6d607fcd8@syzkaller.appspotmail.com Reported-by: syzbot+2096681f6891e7bf8aed@syzkaller.appspotmail.com PiperOrigin-RevId: 337973519
2020-10-20Merge release-20201005.0-104-gcd86bd493 (automated)gVisor bot
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-16 22:31:42 +0000