diff options
author | Jamie Liu <jamieliu@google.com> | 2019-03-25 12:41:36 -0700 |
---|---|---|
committer | Shentubot <shentubot@google.com> | 2019-03-25 12:42:43 -0700 |
commit | f3723f805989d0c5956fbb6aa88b1cd9ac20753c (patch) | |
tree | f8992ae20287a20ab4325a0fa8f5da213283470f /pkg/sentry/hostcpu | |
parent | ddc05e3053e387be9c81aa98c621b6fc92b01000 (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