6a4d17a31d
The comments in the ticket indicate that this behavior is fine and that the ticket should be closed, so we shouldn't need pointers to the ticket. PiperOrigin-RevId: 306266071 |
||
---|---|---|
.. | ||
BUILD | ||
README.md | ||
access_type.go | ||
addr.go | ||
addr_range_seq_test.go | ||
addr_range_seq_unsafe.go | ||
bytes_io.go | ||
bytes_io_unsafe.go | ||
usermem.go | ||
usermem_arm64.go | ||
usermem_test.go | ||
usermem_x86.go |
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 theIO
interface ismm.MemoryManager
. -
IOSequence
represents a collection of individually-contiguous address ranges in aIO
that is operated on sequentially, analogous to Linux'sstruct 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 insyscalls/linux
); use thekernel.Task.Copy*
wrappers defined inkernel/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'smm.MemoryManager
by callingkernel.Task.MemoryManager
, and call itsIO
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 anIOSequence
. Thekernel.Task.SingleIOSequence
andkernel.Task.IovecsIOSequence
functions inkernel/task_usermem.go
are convenience functions for doing so.