go
/
gvisor
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
gvisor/pkg/usermem
History
Michael Pratt 129018ab3d Consistent precondition formatting 
Our "Preconditions:" blocks are very useful to determine the input invariants,
but they are bit inconsistent throughout the codebase, which makes them harder
to read (particularly cases with 5+ conditions in a single paragraph).

I've reformatted all of the cases to fit in simple rules:

1. Cases with a single condition are placed on a single line.
2. Cases with multiple conditions are placed in a bulleted list.

This format has been added to the style guide.

I've also mentioned "Postconditions:", though those are much less frequently
used, and all uses already match this style.

PiperOrigin-RevId: 327687465
 		2020-08-20 13:32:24 -07:00
..
BUILD Port most syscalls to VFS2. 2020-02-25 13:37:34 -08:00
README.md Update package locations. 2020-01-27 15:31:32 -08:00
access_type.go Update package locations. 2020-01-27 15:31:32 -08:00
addr.go Implement mmap for host fs in vfs2. 2020-05-19 13:46:42 -07:00
addr_range_seq_test.go Update package locations. 2020-01-27 15:31:32 -08:00
addr_range_seq_unsafe.go Consistent precondition formatting 2020-08-20 13:32:24 -07:00
bytes_io.go Update package locations. 2020-01-27 15:31:32 -08:00
bytes_io_unsafe.go Update package locations. 2020-01-27 15:31:32 -08:00
usermem.go Consistent precondition formatting 2020-08-20 13:32:24 -07:00
usermem_arm64.go Update package locations. 2020-01-27 15:31:32 -08:00
usermem_test.go Update package locations. 2020-01-27 15:31:32 -08:00
usermem_x86.go Fix 386 build tags 2020-04-01 10:00:03 -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.