Is changing the signal handler rapidly wasteful?
It seems annoying to have this overhead to fix this problem. Could the
signal handler *always* be replaced, and just have a (per thread?) flag
that is turned on/off indicating how it can behave. Or could there be a
zero-cost method: the signal handler is always replaced and figures out
if the access is an address in a shm map to decide what to do.
Neil Roberts wrote:
Linux will let you mmap a region of a file that is larger than the
size of the file. If you then try to read from that region the process
will get a SIGBUS signal. Currently the clients can use this to crash
a compositor because it can create a pool and lie about the size of
the file which will cause the compositor to try and read past the end
of it. The compositor can't simply check the size of the file to
verify that it is big enough because then there is a race condition
where the client may truncate the file after the check is performed.
This patch adds the following two public functions in the server API
which can be used wrap access to an SHM buffer:
void wl_shm_buffer_begin_access(struct wl_shm_buffer *buffer);
void wl_shm_buffer_end_access(struct wl_shm_buffer *buffer);
In-between calls to these functions there will be a signal handler for
SIGBUS. If the signal is caught then the buffer is remapped to an
anonymous private buffer at the same address which allows the
compositor to continue without crashing. The end_access function will
then post an error to the buffer resource.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
