[Bug 211924] lib/libc/sys/mmap_test:mmap_truncate_signal fails with SIGSEGV instead of SIGBUS

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211924

--- Comment #7 from Jilles Tjoelker <jilles at FreeBSD.org> ---
Here is a real-world example of code expecting SIGBUS:
https://gitlab.freedesktop.org/xorg/xserver/blob/master/os/busfault.c

(Note that this is the same "busfault" I referred to in the file sealing review
https://reviews.freebsd.org/D21391 . I think preventing truncation via sealing
is generally a better option than handling signals, but it may not always be
possible.)

Like the NetBSD testcase, this assumes that truncating after the mapping has
been created behaves normally, as if the truncation has been done beforehand.

Sending SIGSEGV where SIGBUS is expected will expose the X server to an easy
DoS by a client truncating a file or posixshm mapped by the X server. This only
applies to certain modern protocol extensions since older ones use SysV shared
memory segments that have a fixed size.

Accepting SIGSEGV in the X server code runs the risk of trying to "fix", for
example, an incorrect write to a read-only mapping or a jump to a
non-executable mapping by treating it as if the client unexpectedly truncated
the object. Checking si_code does not help since FreeBSD currently sends
SEGV_ACCERR in both situations.

The signal definitions should indeed not be changed back to what they were.
Instead, the number of possible signal/code combinations from page faults
should be increased from two to three. In sys/amd64/amd64/trap.c, this
corresponds to the return value from trap_pfault(). This will also need changes
to sys/vm/vm_fault.c, since vm_fault() currently returns
KERN_PROTECTION_FAILURE for both accesses violating the protection such as
writes to a read-only mapping (which should result in SIGSEGV with code
SEGV_ACCERR) and accesses inside a valid mapping but outside the underlying
object (which should result in SIGBUS with code BUS_OBJERR).

-- 
You are receiving this mail because:
You are the assignee for the bug.