Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #3556
Closed
Open
Issue created Apr 19, 2019 by Derek Bruening@derekbrueningContributor

Add interoperability with W^X policies

This is a feature request to add support in DR for working in the presence of W^X policies. These PaX-like policies typically disallow execution from any page that came from mmap +wx or ever had mprotect +x applied to it, which rules out writing and later marking read-only. The proposal here is to use a dual-mapping strategy: having two virtual pages backed by the same physical page, with one +rw for writing and the other +rx for execution.

This will likely be limited to 64-bit Linux but could be extended to Windows in the future if desired.

With #1132 (closed) in place, we can make a new reservation the same size as vmcode and have a constant offset between each pair of pages. We would then keep all variables tracking addresses as scalars, and when we want to write, we would simply add the offset.

It may be best to first extend #774 (closed) and #1132 (closed) to make the size of vmcode 2G by default, to avoid any issues with out-of-reservation allocations.

Assignee
Assign to
Time tracking