I recently tried to run qemu, and it failed with SIGABRT and dmesg
map stack 0x86277000-0x86378000 of map 0xd5343afc failed: bad protection
map stack for pid 43079 failed
I initially think about missing MAP_STACK. And effectively, the flag is
missing on the port (function qemu_alloc_stack() in util/oslib-posix.c).
But in fact, it seems it isn't underline problem of my failure: even
with MAP_STACK, the program is still aborted at the same place.
The real problem is qemu implements a stackguard protection
> Sebastien Marie wrote:
> > Assuming the check on protection is a bit too restrictive, and it is
> > fine to have some chunks with PROT_NONE, I think we want something like:
> are readonly stacks meaningful? if so, we should fix that too now instead of
Other systems lack allocators that opportunistically place guard pages
off the edge of mmap/malloc allocations.
That as led some programs to install their own guard-page to catch
small-range stack overflows (useless for large-range reach, as the
public learned a couple months ago).
The full range gets passed to sigaltstack, which freaks out due to a
recently added check included in the MAP_STACK work. That check isn't
needed since prot checks still get evaluated seperately by uvm_fault
and sigaltstack should always succeed.
So stefan is deleting the check.
What occurs without this check? The sigaltstack MAP_STACK-overtake will
override the in-region guard-page, turning it into PROT_READ|PROT_WRITE
w/ MAP_STACK. I have a seperate discussion with stefan about how to
avoid PROT_* mangling that one page inside uvm_map_remap_as_stack(),
basically if the overflow-end of stack is properly aligned, ignore 1
full page in case it is a guard. Don't make it MAP_STACK, and don't
change it's permissions.
MAP_STACK can therefore act as an opportunistic overflow detector, and
an applications own PROT_NONE guard can act so otherwise.