Download raw body.
Allocated WebAssembly stack memory with MAP_STACK in firefoxes
Allocated WebAssembly stack memory with MAP_STACK in firefoxes
Allocated WebAssembly stack memory with MAP_STACK in firefoxes
++#ifdef __OpenBSD__
++ // OpenBSD kills the process if the stack pointer points into memory not
++ // mapped with MAP_STACK. That flag can only be set at mmap() time, so remap
++ // the region in place. The pages are freshly mapped and untouched, so
++ // discarding their contents here is fine.
++ void* result = MozTaggedAnonymousMmap(
++ region, length, int(PageAccess::ReadWrite),
++ MAP_PRIVATE | MAP_ANON | MAP_FIXED | MAP_STACK, -1, 0, "js-gc-stack");
++ if (result != region) {
++ UnmapPages(region, length);
++ return nullptr;
++ }
++#endif
This is really sad and pathetic.
First off, it is not your fault. You are sending a diff for a workaround.
However, it has been clear for a while that all these new fancy "memory
safe" claimed stacks cannot handle REAL, HARD memory safety primitives,
and have to work around them because while they promise noone else can
cheat, they depend upon the ability to cheat themselves.
The workaround mechanisms are already pre-coded and a function call away.
You just use what they have.
It is clear that firefox will never use mimmutable(), which would
prevent attacks from redoing mappings, because an interface exists precisely
to redo mappings in non-attack code. Their own code is not considered
as engaging in attacks, until the day someone plays with invariants and
use their code against them. I'm saying this remapping interface does not
exist by chance. It exists because they depend on it, at the same time
they claim attacks cannot play with memory.
Allocated WebAssembly stack memory with MAP_STACK in firefoxes
Allocated WebAssembly stack memory with MAP_STACK in firefoxes
Allocated WebAssembly stack memory with MAP_STACK in firefoxes