[PATCH] server: Add API to protect access to an SHM buffer

[Bill Spitzak]

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.