mmap_low_allowed is the name of the boolean moving forward.
This access has proven to be a critical security feature,
and several kernel/root vulnerabilities will be prevented
by turning this boolean off, with the only down side,
preventing old windows applications from running by default in wine.
(If vbetool is fixed).
It is a mistake to believe "the only down side is preventing
old [W]indows applications from running by default in wine."
The claim is not true.
I have three applications that fundamentally fail to work
if mmap(0,PAGE_SIZE,,MAP_FIXED,,) is disallowed. Addressing
memory at address 0 is fundamental to the way that they work.
Using "any other page" would totally prevent two of the apps
from working at all, and would severely cripple the third.
They are not "old [W]indows apps". They are every-day utilities
and development tools written for Linux, and I object to them
being broken.
The kernel could remove 99.9% of the vulnerability, with
no dynamic cost to processes that don't use page 0, by:
1. Reduce STACK_TOP by one page, and reserve the corresponding
virtual page frame.
2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the
process status bit which forces "slow path" for kernel entry
via system call from that process. In the slow path, check for
a mapping at page 0 and if so then move that mapping to the
reserved page at STACK_TOP, and turn off the mapping at page 0.
Reverse the substitution when returning from the syscall.
3. Add the necessary check in the trap handler for
copy_{to,from}_user() to handle intended kernel access to page 0
(including I/O) by substituting the reserved page instead.
This would allow mmap(0,,,MAP_FIXED,,) yet still protect all
synchronous kernel execution. The only remaining window of
vulnerability is interrupt handlers. If an interrupt handler
is touching *any* user address space then the problems are more
serious than mmap(0).
--
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
