Per the comment for vfs.GenericProxyDeviceConfigureMMap(), this ensures that if
invalid arguments are provided to application mmap() for a proxy device file,
then an error is returned immediately (from host mmap()) rather than when
demand paging causes host mmap() to be invoked.
PiperOrigin-RevId: 680733678
memmap.Mappable.Translate() is passed a hostarch.AccessType indicating what
permissions are *immediately* required; it returns permissions in
memmap.Translation.Perms that are granted *to MM* until invalidation. MM
ensures that the permissions granted to the application are the intersection of
those granted by Translate, and those granted by VMA permissions; see
determination of pma.effectivePerms in
mm.MemoryManager.getPMAsInternalLocked(). This mechanism is used to avoid
marking pages dirty in the sentry's page cache for gofer-backed files until
PROT_WRITE pages are actually written to; see gofer.dentry.Translate(). In most
other cases, granting all supported permissions (to MM) up-front avoids a
redundant page fault for pages that are touched first for reading, and later
for writing.
Also:
- Prevent PROT_WRITE mappings of erofs files at mmap()/mprotect() time, rather
than raising SIGBUS when writing to such mappings.
- Map nvproxy.frontendFD with PlatformEffectPopulate. This is the original goal
of this CL; however, before this rest of this CL, MM.MMap() =>
MM.populateVMAAndUnlock() => MM.getPMAsLocked(at=hostarch.NoAccess) =>
MM.getPMAsInternalLocked(at=hostarch.NoAccess) =>
nvproxy.frontendFD.Translate(at=hostarch.NoAccess) returns Translations with
no permissions, causing MM.mapASLocked() to no-op.
PiperOrigin-RevId: 679360594
These support the relatively common use case of removing all segments in a
given range (unconditionally) but doing something with them before they're
removed. This is always more compact, and may be slightly faster in some cases
(every replaced loop calls Isolate per iteration, while RemoveRangeWith avoids
redundant split checks between segments), at the cost of a direct function
call.
Also slightly optimize Set.LowerBoundSegmentSplitBefore() and
Set.UpperBoundSegmentSplitAfter() by inlining LowerBoundSegment and
UpperBoundSegment respectively; in the cases where Find() returns a
GapIterator, the segment that is returned doesn't need to be split since it
doesn't contain min/max respectively.
PiperOrigin-RevId: 675824581
Ubuntu TPU images do not have the vfio-dev directories that COS images do,
so we need a more robust way of setting up the sandbox chroot to handle this
case. This change implements a way to get devices and minor numbers into the
sandbox with minimal support from the host filesystem and cleans up a few
methods to reflect their current usage.
Addresses #10795
PiperOrigin-RevId: 674363342
V5 support was broken in a few different ways:
- tpu device files (/dev/vfio/X) were created with incorrect minor device nums.
- PCI paths on bus' other than 0000:00 were not supported.
- VFIO unmap was broken and not properly added to the seccomp allowlist.
- The VFIO main device file (/dev/vfio/vfio) did not account for overlapping
device address ranges that correspond to different VFIO container groups.
Previously TPU support was tested on machines with single TPUs, which masked
most of these issues.
All these issues should be fixed by this change. Tested manually on GKE.
PiperOrigin-RevId: 656037853
MapInternal() returns a coherent memory mapping of the host file descriptor
represented by a memmap.File, in the sentry's address space. This is
principally used when the sentry needs to access the contents of application
memory (for e.g. syscall arguments passed by pointer, or the source/destination
of a write()/read() syscall); it usually looks up the memmap.Files backing
application addresses and obtains mappings via MapInternal().
/dev/nvidia-uvm cannot generally be mapped into the sentry's address space, for
reasons described by
https://github.com/google/gvisor/blob/master/g3doc/proposals/nvidia_driver_proxy.md#unified-virtual-memory-uvm
(in short, nvidia-uvm requires that a given page at file offset X can only be
mapped at address X). To allow the sentry to access the contents of such
mappings, make it possible for memmap.File.MapInternal() to indicate that a
fallback to buffered I/O is required, add interface methods
memmap.File.Buffer{Read,Write}At() to perform this buffered I/O, and implement
this fallback in the MM I/O path.
This CL does not use the new buffered I/O fallback anywhere; a following CL
adds it to nvproxy's nvidia-uvm.
Updates #10331
PiperOrigin-RevId: 629830825
Lucas ManningandgVisor bot
Jamie LiuandgVisor bot
Andrei Vagin
Jing ChenandgVisor bot