summaryrefslogtreecommitdiffstats
path: root/secure
diff options
context:
space:
mode:
authoralc <alc@FreeBSD.org>2009-11-26 05:16:07 +0000
committeralc <alc@FreeBSD.org>2009-11-26 05:16:07 +0000
commit2d9252d6c71a08629a451a1966338c6e119912d1 (patch)
tree439fa48cd35e4006d82b065ffb58d6904316bd64 /secure
parent91785603f392f8a8a6ce7a20efe9065cfa5d2701 (diff)
downloadFreeBSD-src-2d9252d6c71a08629a451a1966338c6e119912d1.zip
FreeBSD-src-2d9252d6c71a08629a451a1966338c6e119912d1.tar.gz
Replace VM_PROT_OVERRIDE_WRITE by VM_PROT_COPY. VM_PROT_OVERRIDE_WRITE has
represented a write access that is allowed to override write protection. Until now, VM_PROT_OVERRIDE_WRITE has been used to write breakpoints into text pages. Text pages are not just write protected but they are also copy-on-write. VM_PROT_OVERRIDE_WRITE overrides the write protection on the text page and triggers the replication of the page so that the breakpoint will be written to a private copy. However, here is where things become confused. It is the debugger, not the process being debugged that requires write access to the copied page. Nonetheless, the copied page is being mapped into the process with write access enabled. In other words, once the debugger sets a breakpoint within a text page, the program can write to its private copy of that text page. Whereas prior to setting the breakpoint, a SIGSEGV would have occurred upon a write access. VM_PROT_COPY addresses this problem. The combination of VM_PROT_READ and VM_PROT_COPY forces the replication of a copy-on-write page even though the access is only for read. Moreover, the replicated page is only mapped into the process with read access, and not write access. Reviewed by: kib MFC after: 4 weeks
Diffstat (limited to 'secure')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud