summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/hostcpu
diff options
context:
space:
mode:
authorJamie Liu <jamieliu@google.com>2019-03-25 12:41:36 -0700
committerShentubot <shentubot@google.com>2019-03-25 12:42:43 -0700
commitf3723f805989d0c5956fbb6aa88b1cd9ac20753c (patch)
treef8992ae20287a20ab4325a0fa8f5da213283470f /pkg/sentry/hostcpu
parentddc05e3053e387be9c81aa98c621b6fc92b01000 (diff)
Call memmap.Mappable.Translate with more conservative usermem.AccessType.
MM.insertPMAsLocked() passes vma.maxPerms to memmap.Mappable.Translate (although it unsets AccessType.Write if the vma is private). This somewhat simplifies handling of pmas, since it means only COW-break needs to replace existing pmas. However, it also means that a MAP_SHARED mapping of a file opened O_RDWR dirties the file, regardless of the mapping's permissions and whether or not the mapping is ever actually written to with I/O that ignores permissions (e.g. ptrace(PTRACE_POKEDATA)). To fix this: - Change the pma-getting path to request only the permissions that are required for the calling access. - Change memmap.Mappable.Translate to take requested permissions, and return allowed permissions. This preserves the existing behavior in the common cases where the memmap.Mappable isn't fsutil.CachingInodeOperations and doesn't care if the translated platform.File pages are written to. - Change the MM.getPMAsLocked path to support permission upgrading of pmas outside of copy-on-write. PiperOrigin-RevId: 240196979 Change-Id: Ie0147c62c1fbc409467a6fa16269a413f3d7d571
Diffstat (limited to 'pkg/sentry/hostcpu')
0 files changed, 0 insertions, 0 deletions