gvisor

History

Jamie Liu 9ea248489b Cap initial usermem.CopyStringIn buffer size. Almost (?) all uses of CopyStringIn are via linux.copyInPath(), which passes maxlen = linux.PATH_MAX = 4096. Pre-allocating a buffer of this size is measurably inefficient in most cases: most paths will not be this long, 4 KB is a lot of bytes to zero, and as of this writing the Go runtime allocator maps only two 4 KB objects to each 8 KB span, necessitating a call to runtime.mcache.refill() on ~every other call. Limit the initial buffer size to 256 B instead, and geometrically reallocate if necessary. PiperOrigin-RevId: 251960441		2019-06-06 17:22:00 -07:00
..
BUILD	Convert []byte to string without copying in usermem.CopyStringIn.	2019-03-27 10:46:28 -07:00
README.md	Format documentation	2018-07-12 10:37:21 -07:00
access_type.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00
addr.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00
addr_range_seq_test.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00
addr_range_seq_unsafe.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00
bytes_io.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00
bytes_io_unsafe.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00
usermem.go	Cap initial usermem.CopyStringIn buffer size.	2019-06-06 17:22:00 -07:00
usermem_arm64.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00
usermem_test.go	Cap initial usermem.CopyStringIn buffer size.	2019-06-06 17:22:00 -07:00
usermem_unsafe.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00
usermem_x86.go	Change copyright notice to "The gVisor Authors"	2019-04-29 14:26:23 -07:00

README.md

This package defines primitives for sentry access to application memory.

Major types:

The IO interface represents a virtual address space and provides I/O methods on that address space. IO is the lowest-level primitive. The primary implementation of the IO interface is mm.MemoryManager.
IOSequence represents a collection of individually-contiguous address ranges in a IO that is operated on sequentially, analogous to Linux's struct iov_iter.

Major usage patterns:

Access to a task's virtual memory, subject to the application's memory protections and while running on that task's goroutine, from a context that is at or above the level of the kernel package (e.g. most syscall implementations in syscalls/linux); use the kernel.Task.Copy* wrappers defined in kernel/task_usermem.go.
Access to a task's virtual memory, from a context that is at or above the level of the kernel package, but where any of the above constraints does not hold (e.g. PTRACE_POKEDATA, which ignores application memory protections); obtain the task's mm.MemoryManager by calling kernel.Task.MemoryManager, and call its IO methods directly.
Access to a task's virtual memory, from a context that is below the level of the kernel package (e.g. filesystem I/O); clients must pass I/O arguments from higher layers, usually in the form of an IOSequence. The kernel.Task.SingleIOSequence and kernel.Task.IovecsIOSequence functions in kernel/task_usermem.go are convenience functions for doing so.