1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
.. highlight:: none


.. index::
   pair: POSIX; protection interface design
   pair: POSIX protection interface; design

.. _design-protix:


POSIX implementation of protection module
=========================================

.. mps:prefix:: design.mps.protix
   pair: POSIX; protection interface design
   pair: POSIX protection interface; design


Introduction
------------

:mps:tag:`readership` Any MPS developer

:mps:tag:`intro` This is the design of the POSIX implementation of the
protection module. It makes use of various services provided by POSIX.
It is intended to work with POSIX Threads.


Requirements
------------

:mps:tag:`req.general` Required to implement the general protection
interface defined in design.mps.prot.if_.

.. _design.mps.prot.if: prot.html#design.mps.prot.if


Data structures
---------------

:mps:tag:`data.signext` If the SIGSEGV signal is not handled by any MPS
arena, :c:func:`sigHandle()` needs to forward the signal to the next signal
handler in the chain (the signal handler that was installed when the
:c:func:`ProtSetup()` was called), by temporarily reinstalling the old
signal handler and calling :c:func:`kill()`. The only way to pass the next
signal handler to the current signal handler is via a global variable,
in this case the variable ``sigNext``.


Functions
---------

:mps:tag:`fun.setup` :c:func:`ProtSetup()` installs a signal handler for the
signal :c:macro:`SIGSEGV` to catch and handle protection faults (this handler
is the function :c:func:`sigHandle()`).

:mps:tag:`fun.setup.previous` The previous handler is recorded (in the
variable ``sigNext``, see :mps:ref:`.data.signext`) so that it can be reached
from :c:func:`sigHandle()` if it fails to handle the fault.

:mps:tag:`fun.setup.restart` We set the :c:macro:`SA_RESTART` flag when installing
the signal handler so that if the mutator gets a protection fault
while blocked in a system call, the system call is automatically
restarted after the signal is handled, instead of failing with
:c:macro:`EINTR`. Note that unlike the corresponding case in the thread
management subsystem (see design.mps.thread-manager.req.thread.intr_)
we are unsure if this case can actually arise: the :c:macro:`SIGSEGV` from a
protection fault is delivered to the thread that accessed the
protected memory, but in all the cases we have checked, if this access
occurred during a blocking system call such as a :c:func:`read()` with the
buffer in protected memory, the system call fails with :c:macro:`EFAULT` and
is not restarted. However, it costs us nothing to set the
:c:macro:`SA_RESTART` flag.

.. _design.mps.thread-manager.req.thread.intr: thread-manager.html#design.mps.thread-manager.req.thread.intr

:mps:tag:`fun.set` :c:func:`ProtSet()` uses :c:func:`mprotect()` to adjust the
protection for pages.

:mps:tag:`fun.set.convert` The requested protection (which is expressed in
the ``mode`` parameter, see design.mps.prot.if.set_) is translated into
an operating system protection. If read accesses are to be forbidden
then all accesses are forbidden, this is done by setting the
protection of the page to :c:macro:`PROT_NONE`. If write accesses are to be
forbidden (and not read accesses) then write accesses are forbidden
and read accesses are allowed, this is done by setting the protection
of the page to ``PROT_READ|PROT_EXEC``. Otherwise (all access are
okay), the protection is set to ``PROT_READ|PROT_WRITE|PROT_EXEC``.

.. _design.mps.prot.if.set: prot.html#design.mps.prot.if.set

:mps:tag:`fun.set.assume.mprotect` We assume that the call to :c:func:`mprotect()`
always succeeds.  We should always call the function with valid
arguments (aligned, references to mapped pages, and with an access
that is compatible with the access of the underlying object).

:mps:tag:`fun.sync` :c:func:`ProtSync()` does nothing in this implementation as
:c:func:`ProtSet()` sets the protection without any delay.


Threads
-------

:mps:tag:`threads` The design must operate in a multi-threaded environment
(with POSIX Threads) and cooperate with the POSIX support for locks
(see design.mps.lock_) and the thread suspension mechanism (see
design.mps.pthreadext_ ).

.. _design.mps.pthreadext: pthreadext.html
.. _design.mps.lock: lock.html

:mps:tag:`threads.suspend` The :c:macro:`SIGSEGV` signal handler does not mask out
any signals, so a thread may be suspended while the handler is active,
as required by the design (see
design.mps.pthreadext.req.suspend.protection_). The signal handlers
simply nest at top of stack.

.. _design.mps.pthreadext.req.suspend.protection: pthreadext.html#design.mps.pthreadext.req.suspend.protection

:mps:tag:`threads.async` POSIX imposes some restrictions on signal handler
functions (see design.mps.pthreadext.analysis.signal.safety_). Basically
the rules say the behaviour of almost all POSIX functions inside a
signal handler is undefined, except for a handful of functions which
are known to be "async-signal safe". However, if it's known that the
signal didn't happen inside a POSIX function, then it is safe to call
arbitrary POSIX functions inside a handler.

.. _design.mps.pthreadext.analysis.signal.safety: pthreadext.html#design.mps.pthreadext.analysis.signal.safety

:mps:tag:`threads.async.protection` If the signal handler is invoked because
of an MPS access, then we know the access must have been caused by
client code, because the client is not allowed to permit access to
protectable memory to arbitrary foreign code. In these circumstances,
it's OK to call arbitrary POSIX functions inside the handler.

.. note::

    Need a reference for "the client is not allowed to permit access
    to protectable memory to arbitrary foreign code".

:mps:tag:`threads.async.other` If the signal handler is invoked for some
other reason (that is, one we are not prepared to handle) then there
is less we can say about what might have caused the SIGSEGV. In
general it is not safe to call arbitrary POSIX functions inside the
handler in this case.

:mps:tag:`threads.async.choice` The signal handler calls :c:func:`ArenaAccess()`
to determine whether the segmentation fault was the result of an MPS
access. :c:func:`ArenaAccess()` will claim various MPS locks (that is, the
arena ring lock and some arena locks). The code calls no other POSIX
functions in the case where the segmentation fault is not an MPS
access. The locks are implemented as mutexes and are claimed by
calling :c:func:`pthread_mutex_lock()`, which is not defined to be
async-signal safe.

:mps:tag:`threads.async.choice.ok` However, despite the fact that POSIX
Threads documentation doesn't define the behaviour of
:c:func:`pthread_mutex_lock()` in these circumstances, we expect the POSIX
Threads implementation will be well-behaved unless the segmentation
fault occurs while while in the process of locking or unlocking one of
the MPS locks. But we can assume that a segmentation fault will not
happen then (because we use the locks correctly, and generally must
assume that they work). Hence we conclude that it is OK to call
:c:func:`ArenaAccess()` directly from the signal handler.

:mps:tag:`threads.async.improve` In future it would be preferable to not
have to assume reentrant mutex locking and unlocking functions. An
alternative approach would be necessary anyway when supporting another
platform which doesn't offer reentrant locks (if such a platform does
exist).

:mps:tag:`threads.async.improve.how` We could avoid the assumption if we had
a means of testing whether an address lies within an arena chunk
without the need to claim any locks. Such a test might actually be
possible. For example, arenas could update a global datastructure
describing the ranges of all chunks, using atomic updates rather than
locks; the handler code would be allowed to read this without locking.
However, this is somewhat tricky; a particular consideration is that
it's not clear when it's safe to deallocate stale portions of the
datastructure.

:mps:tag:`threads.sig-stack` We do not handle signals on a separate signal
stack. Separate signal stacks apparently don't work properly with
POSIX Threads.