Use sys::Memory::AllocateRWX for JIT code

[krytarowski]

Summary

NetBSD ships with PaX MPROTECT (known as W^X).

This means that if a memory page was writable, it cannot be switched to executable.
Allocating such pages requires extended interface that is handled inside AllocateRWX.

This fixes circa 200 unexpected failures in LLVM tests ("check-llvm") on NetBSD 8.0(beta).
All JIT, ExecutionEngine and similar failures are resolved.

Sponsored by <The NetBSD Foundation>

[lhames]

Could you hold off committing while I review?

[krytarowski]

In D35558#815296, @lhames wrote:

Could you hold off committing while I review?

OK

[rnk]

Yeah, I spoke too soon. I didn't realize that AllocateRWX now does different things on different OSs. We should revisit that.

[lhames]

Is AllocateRWX returning RWX blocks? If so, is anyone clearing the W bit later?

For architectures that support it, I think I would like to keep the existing scheme: JIT'd memory is initialized while in RW- mode, then switched to RX- mode prior to execution. That means JIT'd code has no easy way to modify itself during execution.

I'm also open to changing the model (I'm not a security expert) but that would require more consideration.

[krytarowski]

In D35558#815333, @lhames wrote:

Is AllocateRWX returning RWX blocks? If so, is anyone clearing the W bit later?

For architectures that support it, I think I would like to keep the existing scheme: JIT'd memory is initialized while in RW- mode, then switched to RX- mode prior to execution. That means JIT'd code has no easy way to modify itself during execution.

I'm also open to changing the model (I'm not a security expert) but that would require more consideration.

Right, the pages are allocated RWX.

As far as I can tell, this interface is not prepared to disable R, W, X properties at least in a portable way.

I've missed that we need to use ReleaseRWX() for the RWX regions.

Switching a page from the W mode to X is prohibited with PaX MPROTECT (on NetBSD).

[lhames]

Right, the pages are allocated RWX.

It seems odd to prevent the flipping of the W/X bits while allowing RWX pages. I assume there are additional privileges required (granted only to JITs and debuggers?) to get RWX pages? Is there a good source for me to read up about the PaX MPROTECT design?

I think we need to consider this design further before we move to it by default, but I am keen to look into this: to the extent that we can support RWX pages there are some excellent optimizations we can make for JIT'd code that have been on my wish-list for a while.

We could develop the new scheme alongside the old one by introducing parallel RWX-based stub and callback managers.

[joerg]

In D35558#815442, @lhames wrote:

Right, the pages are allocated RWX.

It seems odd to prevent the flipping of the W/X bits while allowing RWX pages. I assume there are additional privileges
required (granted only to JITs and debuggers?) to get RWX pages? Is there a good source for me to read up about the PaX MPROTECT design?

They are not allocated RWX, they are allocated RW with the option for later X. I.e. the kernel enforces W^X, but you can request
additional protections for later use. Without that, mprotect with X would be rejected later. There are patching for Linux for similar effect, but I don't think
they ever got merged. libffi is a victim of that on Linux.

[krytarowski]

In D35558#815442, @lhames wrote:

Right, the pages are allocated RWX.

It seems odd to prevent the flipping of the W/X bits while allowing RWX pages. I assume there are additional privileges required (granted only to JITs and debuggers?) to get RWX pages? Is there a good source for me to read up about the PaX MPROTECT design?

I think that the whole design is about remapping all (R)WX pages to (R)W and not allowing to remap it as X in future.
AllocateRWX uses OS-specific interfaces to workaround it (if possible).

By default attaching to a process with ptrace(2) eliminates this restriction for debuggers. This is needed to insert software breakpoints.

I think we need to consider this design further before we move to it by default, but I am keen to look into this: to the extent that we can support RWX pages there are some excellent optimizations we can make for JIT'd code that have been on my wish-list for a while.

We could develop the new scheme alongside the old one by introducing parallel RWX-based stub and callback managers.

I recommend to discuss it with @joerg as he is the author of our JIT interface in mmap(2).
I have no personal preferences here, I want to get LLVM JIT functional.

[rnk]

In D35558#815451, @joerg wrote:

They are not allocated RWX, they are allocated RW with the option for later X. I.e. the kernel enforces W^X, but you can request
additional protections for later use. Without that, mprotect with X would be rejected later. There are patching for Linux for similar effect, but I don't think
they ever got merged. libffi is a victim of that on Linux.

That makes sense, but it seems like the right thing then is for LLVM to change its APIs to allocate RW pages everywhere and then flip them between RW and RX. We should remove this error-prone AllocateRWX API.

[krytarowski]

In D35558#815451, @joerg wrote:

In D35558#815442, @lhames wrote:

Right, the pages are allocated RWX.

It seems odd to prevent the flipping of the W/X bits while allowing RWX pages. I assume there are additional privileges
required (granted only to JITs and debuggers?) to get RWX pages? Is there a good source for me to read up about the PaX MPROTECT design?

They are not allocated RWX, they are allocated RW with the option for later X. I.e. the kernel enforces W^X, but you can request
additional protections for later use. Without that, mprotect with X would be rejected later. There are patching for Linux for similar effect, but I don't think
they ever got merged. libffi is a victim of that on Linux.

Right, this is NetBSD-specific implementation detail of AllocateRWX.

libffi examples (ffi_closure_alloc):
https://github.com/libffi/libffi/blob/6e2e041b6df6a3c3a5ca8a750dedbbd465e5ca97/src/closures.c

[joerg]

Keep in mind that the SELinux case in libffi is not fork-safe. One important part LLVM needs to consider is
whether it wants to enshrine the performance penalty of mprotect-after-commit in its APIs or not. The second part
is whether platforms should aim to support hot-patchable JIT for multi-threaded environments or not. If the latter is
not considered relevant, the API only needs to provide a function to allocate JIT-safe memory and a function to make
it executable. If the latter is relevant, the current AllocateRWX is the interface you will end up with, one way or the other.

[lhames]

They are not allocated RWX, they are allocated RW with the option for later X. I.e. the kernel enforces W^X, but you can request additional protections for later use.

When you say "additional protections" do you mean you can add the 'X' permission later (to get RWX), or just that you can later toggle from RW- to R-X?

That makes sense, but it seems like the right thing then is for LLVM to change its APIs to allocate RW pages everywhere and then flip them between RW and RX. We should remove this error-prone AllocateRWX API.

From a quick grep it seems like AllocateRWX is only called from the llvm-rtdyld tool. I'll see how difficult it is to remove it. If it's easy enough we can kill it, then discuss more future-proof APIs.

One important part LLVM needs to consider is whether it wants to enshrine the performance penalty of mprotect-after-commit in its APIs or not. The second part is whether platforms should aim to support hot-patchable JIT for multi-threaded environments or not.

For the JIT I'm hoping we can avoid having to choose by providing different implementations of a common higher-level API. Probably the StubsManager/CallbackManager level: If your platform supports hot-patching, use a HotPatchableStubsManager and you get the extra performance. If not, use a SlowButSafeStubsManager and everything still works. I hope to have time to prototype and sanity check that idea in a week or so.

[joerg]

In D35558#816891, @lhames wrote:

They are not allocated RWX, they are allocated RW with the option for later X. I.e. the kernel enforces W^X, but you can request additional protections for later use.

When you say "additional protections" do you mean you can add the 'X' permission later (to get RWX), or just that you can later toggle from RW- to R-X?

The kernel strictly enforces W^X, so you can't request RWX. You can say "I want RW now and later maybe X" and with that to you can toggle from RW to RX (well, and back).

That makes sense, but it seems like the right thing then is for LLVM to change its APIs to allocate RW pages everywhere and then flip them between RW and RX. We should remove this error-prone AllocateRWX API.

From a quick grep it seems like AllocateRWX is only called from the llvm-rtdyld tool. I'll see how difficult it is to remove it. If it's easy enough we can kill it, then discuss more future-proof APIs.

One important part LLVM needs to consider is whether it wants to enshrine the performance penalty of mprotect-after-commit in its APIs or not. The second part is whether platforms should aim to support hot-patchable JIT for multi-threaded environments or not.

For the JIT I'm hoping we can avoid having to choose by providing different implementations of a common higher-level API.
Probably the StubsManager/CallbackManager level: If your platform supports hot-patching, use a HotPatchableStubsManager
and you get the extra performance. If not, use a SlowButSafeStubsManager and everything still works. I hope to have time
to prototype and sanity check that idea in a week or so.

There are two things to consider here: the short term use for 5.0 (and I support Kamil's patch in that regard) and the long term goal.
The current code is a strict no-go from the NetBSD perspective: you want to turn a pure RW mapping executable, that's not allowed.
We have an API for expressing the desired interface, so the short term fix can be the current patch.

Long term, the situation is a bit different. The problem with your approach is that it likely requires additional non-nop instructions as
patch point to be thread-safe. Consider incremental optimization in the JVM-JIT sense: you want to patch jumps at the beginning of
the function to point to any existing users to the new version. You can't just turn the page from RX to RW for that though, otherwise other
threads will fault.

[lhames]

There are two things to consider here: the short term use for 5.0 (and I support Kamil's patch in that regard) and the long term goal.
The current code is a strict no-go from the NetBSD perspective: you want to turn a pure RW mapping executable, that's not allowed.
We have an API for expressing the desired interface, so the short term fix can be the current patch.

The current patch switches from requesting RW- pages to RWX, which I don't think is valid on iOS although I'll have to double check that.

That said, it sounds the iOS requirement (assuming I'm remembering it right) and the NetBSD one are almost identical. It sounds like we just need to switch from raw allocateMappedMemory calls to a new pair:

allocateFutureExecutablePage(...)
makePageExecutable(...)

On iOS this just forwards to allocateMappedMemory. On NetBSD the first call could do whatever magic is required to make the page flippable. Does that sound reasonable?

This seems achievable before rc2, and potentially safer since it doesn't change the behavior on existing platforms.

Long term, the situation is a bit different. The problem with your approach is that it likely requires additional non-nop instructions as
patch point to be thread-safe. Consider incremental optimization in the JVM-JIT sense: you want to patch jumps at the beginning of
the function to point to any existing users to the new version. You can't just turn the page from RX to RW for that though, otherwise other
threads will fault.

It seems as if there are several approaches available here, depending on the target platform: If you have RWX pages you can just patch without changing permissions. Likewise if you can map the same page twice (once with RW- and once with R-X). As for nops, you can either not use them at all (do everything through indirection, though we still need to do the initial stub setup), we can make function starts patchable, or we can make call-sites patchable. Picking the right high level API should allow us experiment and/or support multiple implementations.

[lhames]

The current patch switches from requesting RW- pages to RWX, which I don't think is valid on iOS although I'll have to double check that.

Sorry - I just realized this doesn't address your earlier comment:

They are not allocated RWX, they are allocated RW with the option for later X. I.e. the kernel enforces W^X, but you can request
additional protections for later use. Without that, mprotect with X would be rejected later. There are patching for Linux for similar effect, but I don't think
they ever got merged. libffi is a victim of that on Linux.

So assuming the AllocateRWX call doesn't actually allocate RWX pages (and the latter calls to mprotect to flip the permissions work) we can go ahead with this patch as is, though I'd love to rename AllocateRWX on mainline to remove the confusion.

[krytarowski]

I have no opinion on further design, if this patch is fine as of now - an intermediate solution for 5.0.0(svn) - great.

[krytarowski]

Ping? Can I push this? I have another fix for MPROTECT on NetBSD with the original sys::Memory::allocateMappedMemory(), not directly related to RWX here. However both patches interfere and can break JIT for current users - without merging this one.

[lhames]

Ok - I've finally had a chance to read AllocateRWX (sorry - it has been a busy week) and it does indeed try to allocate RWX pages, at least on Darwin and Linux. I assume the 'PROT_MPROTECT(PROT_EXEC)' bit for NetBSD is the W^X extension you referenced earlier.

The proper API for existing JIT use-cases should consist of two parts: allocateFutureExecutablePage(...) which should allocate RW- pages on all platforms (as well as marking the page as 'future-executable' for NetBSD), and makePageExecutable(...) which should toggle from RW- to R-X mode on all platforms.

[lhames]

I'll be in #llvm on IRC as 'lhames' for the next couple of hours if you would like to chat about the design.

[krytarowski]

This should be done differently.

include/llvm/ExecutionEngine/Orc/IndirectionUtils.h

 class LocalJITCompileCallbackManager : public JITCompileCallbackManager {
 public:
   /// @brief Construct a InProcessJITCompileCallbackManager.
   /// @param ErrorHandlerAddress The address of an error handler in the target
   ///                            process to be used if a compile callback fails.
   LocalJITCompileCallbackManager(JITTargetAddress ErrorHandlerAddress)
       : JITCompileCallbackManager(ErrorHandlerAddress) {
     /// Set up the resolver block.
-    std::error_code EC;
-    ResolverBlock = sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
-        TargetT::ResolverCodeSize, nullptr,
-        sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
-    assert(!EC && "Failed to allocate resolver block");
+    std::string Err;
+    ResolverBlock = sys::OwningMemoryBlock(
+        sys::Memory::AllocateRWX(TargetT::ResolverCodeSize, nullptr, &Err));
+    if (!ResolverBlock.base())
+      report_fatal_error("Can't allocate enough memory: " + Err);
 
     TargetT::writeResolverCode(static_cast<uint8_t *>(ResolverBlock.base()),
                                &reenter, this);
 
+    std::error_code EC;
     EC = sys::Memory::protectMappedMemory(ResolverBlock.getMemoryBlock(),
                                           sys::Memory::MF_READ |
                                               sys::Memory::MF_EXEC);
     assert(!EC && "Failed to mprotect resolver block");
   }
 
 private:
   static JITTargetAddress reenter(void *CCMgr, void *TrampolineId) {
     JITCompileCallbackManager *Mgr =
         static_cast<JITCompileCallbackManager *>(CCMgr);
     return Mgr->executeCompileCallback(
         static_cast<JITTargetAddress>(
             reinterpret_cast<uintptr_t>(TrampolineId)));
   }
 
   void grow() override {
     assert(this->AvailableTrampolines.empty() && "Growing prematurely?");
 
-    std::error_code EC;
-    auto TrampolineBlock =
-        sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
-            sys::Process::getPageSize(), nullptr,
-            sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
-    assert(!EC && "Failed to allocate trampoline block");
+    std::string Err;
+    auto TrampolineBlock = sys::OwningMemoryBlock(
+        sys::Memory::AllocateRWX(sys::Process::getPageSize(), nullptr, &Err));
+    if (!TrampolineBlock.base())
+      report_fatal_error("Can't allocate enough memory: " + Err);
 
     unsigned NumTrampolines =
         (sys::Process::getPageSize() - TargetT::PointerSize) /
         TargetT::TrampolineSize;
 
     uint8_t *TrampolineMem = static_cast<uint8_t *>(TrampolineBlock.base());
     TargetT::writeTrampolines(TrampolineMem, ResolverBlock.base(),
                               NumTrampolines);
 
     for (unsigned I = 0; I < NumTrampolines; ++I)
       this->AvailableTrampolines.push_back(
           static_cast<JITTargetAddress>(reinterpret_cast<uintptr_t>(
               TrampolineMem + (I * TargetT::TrampolineSize))));
 
+    std::error_code EC;
     EC = sys::Memory::protectMappedMemory(TrampolineBlock.getMemoryBlock(),
                                           sys::Memory::MF_READ |
                                               sys::Memory::MF_EXEC);
     assert(!EC && "Failed to mprotect trampoline block");
 
     TrampolineBlocks.push_back(std::move(TrampolineBlock));
   }
 

include/llvm/ExecutionEngine/Orc/OrcRemoteTargetServer.h

struct Allocator {
     }
 
     ~Allocator() {
       for (auto &Alloc : Allocs)
         sys::Memory::releaseMappedMemory(Alloc.second);
     }
 
     Error allocate(void *&Addr, size_t Size, uint32_t Align) {
-      std::error_code EC;
-      sys::MemoryBlock MB = sys::Memory::allocateMappedMemory(
-          Size, nullptr, sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC);
-      if (EC)
-        return errorCodeToError(EC);
+      std::string Err;
+      sys::MemoryBlock MB = sys::Memory::AllocateRWX(Size, nullptr, &Err);
+      if (!MB.base())
+        report_fatal_error("Can't allocate enough memory: " + Err);
 
       Addr = MB.base();
       assert(Allocs.find(MB.base()) == Allocs.end() && "Duplicate alloc");
       Allocs[MB.base()] = std::move(MB);
       return Error::success();
     }
 
     Error setProtections(void *block, unsigned Flags) {
handleEmitIndirectStubs(ResourceIdMgr::ResourceId Id,
 
     auto &BlockList = StubOwnerItr->second;
     BlockList.push_back(std::move(IS));
 
     return std::make_tuple(StubsBase, PtrsBase, NumStubsEmitted);
   }
 
   Error handleEmitResolverBlock() {
-    std::error_code EC;
-    ResolverBlock = sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
-        TargetT::ResolverCodeSize, nullptr,
-        sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
-    if (EC)
-      return errorCodeToError(EC);
+    std::string Err;
+    ResolverBlock = sys::OwningMemoryBlock(
+        sys::Memory::AllocateRWX(TargetT::ResolverCodeSize, nullptr, &Err));
+    if (!ResolverBlock.base())
+      report_fatal_error("Can't allocate enough memory: " + Err);
 
     TargetT::writeResolverCode(static_cast<uint8_t *>(ResolverBlock.base()),
                                &reenter, this);
 
     return errorCodeToError(sys::Memory::protectMappedMemory(
         ResolverBlock.getMemoryBlock(),
         sys::Memory::MF_READ | sys::Memory::MF_EXEC));
   }
 
   Expected<std::tuple<JITTargetAddress, uint32_t>> handleEmitTrampolineBlock() {
-    std::error_code EC;
-    auto TrampolineBlock =
-        sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
-            sys::Process::getPageSize(), nullptr,
-            sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
-    if (EC)
-      return errorCodeToError(EC);
+    std::string Err;
+    auto TrampolineBlock = sys::OwningMemoryBlock(
+        sys::Memory::AllocateRWX(sys::Process::getPageSize(), nullptr, &Err));
+    if (!TrampolineBlock.base())
+      report_fatal_error("Can't allocate enough memory: " + Err);
 
     uint32_t NumTrampolines =
         (sys::Process::getPageSize() - TargetT::PointerSize) /
         TargetT::TrampolineSize;
 
     uint8_t *TrampolineMem = static_cast<uint8_t *>(TrampolineBlock.base());
     TargetT::writeTrampolines(TrampolineMem, ResolverBlock.base(),
                               NumTrampolines);
 
+    std::error_code EC;
     EC = sys::Memory::protectMappedMemory(TrampolineBlock.getMemoryBlock(),
                                           sys::Memory::MF_READ |
                                               sys::Memory::MF_EXEC);
 
     TrampolineBlocks.push_back(std::move(TrampolineBlock));
 
     auto TrampolineBaseAddr = static_cast<JITTargetAddress>(
         reinterpret_cast<uintptr_t>(TrampolineMem));

lib/ExecutionEngine/Orc/OrcABISupport.cpp

Error OrcAArch64::emitIndirectStubsBlock(IndirectStubsInfo &StubsInfo,
   const unsigned StubSize = IndirectStubsInfo::StubSize;
 
   // Emit at least MinStubs, rounded up to fill the pages allocated.
   unsigned PageSize = sys::Process::getPageSize();
   unsigned NumPages = ((MinStubs * StubSize) + (PageSize - 1)) / PageSize;
   unsigned NumStubs = (NumPages * PageSize) / StubSize;
 
   // Allocate memory for stubs and pointers in one call.
-  std::error_code EC;
-  auto StubsMem = sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
-      2 * NumPages * PageSize, nullptr,
-      sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
-
-  if (EC)
-    return errorCodeToError(EC);
+  std::string Err;
+  auto StubsMem = sys::OwningMemoryBlock(
+      sys::Memory::AllocateRWX(2 * NumPages * PageSize, nullptr, &Err));
+  if (!StubsMem.base())
+    report_fatal_error("Can't allocate enough memory: " + Err);
 
   // Create separate MemoryBlocks representing the stubs and pointers.
   sys::MemoryBlock StubsBlock(StubsMem.base(), NumPages * PageSize);
   sys::MemoryBlock PtrsBlock(static_cast<char *>(StubsMem.base()) +
                                  NumPages * PageSize,
                              NumPages * PageSize);
 
   // Populate the stubs page stubs and mark it executable.
Error OrcX86_64_Base::emitIndirectStubsBlock(IndirectStubsInfo &StubsInfo,
   const unsigned StubSize = IndirectStubsInfo::StubSize;
 
   // Emit at least MinStubs, rounded up to fill the pages allocated.
   unsigned PageSize = sys::Process::getPageSize();
   unsigned NumPages = ((MinStubs * StubSize) + (PageSize - 1)) / PageSize;
   unsigned NumStubs = (NumPages * PageSize) / StubSize;
 
   // Allocate memory for stubs and pointers in one call.
-  std::error_code EC;
-  auto StubsMem = sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
-      2 * NumPages * PageSize, nullptr,
-      sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
-
-  if (EC)
-    return errorCodeToError(EC);
+  std::string Err;
+  auto StubsMem = sys::OwningMemoryBlock(
+      sys::Memory::AllocateRWX(2 * NumPages * PageSize, nullptr, &Err));
+  if (!StubsMem.base())
+    report_fatal_error("Can't allocate enough memory: " + Err);
 
   // Create separate MemoryBlocks representing the stubs and pointers.
   sys::MemoryBlock StubsBlock(StubsMem.base(), NumPages * PageSize);
   sys::MemoryBlock PtrsBlock(static_cast<char *>(StubsMem.base()) +
                                  NumPages * PageSize,
                              NumPages * PageSize);
 
   // Populate the stubs page stubs and mark it executable.
Error OrcI386::emitIndirectStubsBlock(IndirectStubsInfo &StubsInfo,
   const unsigned StubSize = IndirectStubsInfo::StubSize;
 
   // Emit at least MinStubs, rounded up to fill the pages allocated.
   unsigned PageSize = sys::Process::getPageSize();
   unsigned NumPages = ((MinStubs * StubSize) + (PageSize - 1)) / PageSize;
   unsigned NumStubs = (NumPages * PageSize) / StubSize;
 
   // Allocate memory for stubs and pointers in one call.
-  std::error_code EC;
-  auto StubsMem = sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
-      2 * NumPages * PageSize, nullptr,
-      sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
-
-  if (EC)
-    return errorCodeToError(EC);
+  std::string Err;
+  auto StubsMem = sys::OwningMemoryBlock(
+      sys::Memory::AllocateRWX(2 * NumPages * PageSize, nullptr, &Err));
+  if (!StubsMem.base())
+    report_fatal_error("Can't allocate enough memory: " + Err);
 
   // Create separate MemoryBlocks representing the stubs and pointers.
   sys::MemoryBlock StubsBlock(StubsMem.base(), NumPages * PageSize);
   sys::MemoryBlock PtrsBlock(static_cast<char *>(StubsMem.base()) +
                                  NumPages * PageSize,
                              NumPages * PageSize);
 
   // Populate the stubs page stubs and mark it executable.

lib/ExecutionEngine/SectionMemoryManager.cpp

uint8_t *SectionMemoryManager::allocateSection(MemoryGroup &MemGroup,
   // Note that all sections get allocated as read-write.  The permissions will
   // be updated later based on memory group.
   //
   // FIXME: It would be useful to define a default allocation size (or add
   // it as a constructor parameter) to minimize the number of allocations.
   //
   // FIXME: Initialize the Near member for each memory group to avoid
   // interleaving.
-  std::error_code ec;
-  sys::MemoryBlock MB = sys::Memory::allocateMappedMemory(RequiredSize,
-                                                          &MemGroup.Near,
-                                                          sys::Memory::MF_READ |
-                                                            sys::Memory::MF_WRITE,
-                                                          ec);
-  if (ec) {
-    // FIXME: Add error propagation to the interface.
-    return nullptr;
-  }
+  std::string Err;
+  sys::MemoryBlock MB =
+      sys::Memory::AllocateRWX(RequiredSize, &MemGroup.Near, &Err);
+  if (!MB.base())
+    report_fatal_error("Can't allocate enough memory: " + Err);
 
   // Save this address as the basis for our next request
   MemGroup.Near = MB;
 
   // Remember that we allocated this memory
   MemGroup.AllocatedMem.push_back(MB);
   Addr = (uintptr_t)MB.base();
   uintptr_t EndOfBlock = Addr + MB.size();