Windows has a private heap system where you can disable code execution from the pages allocated to `HeapCreate`, if you don't* set that flag:

https://learn.microsoft.com/en-us/windows/win32/api/heapapi/...

> HEAP_CREATE_ENABLE_EXECUTE

> 0x00040000

> All memory blocks that are allocated from this heap allow code execution, if the hardware enforces data execution prevention. Use this flag heap in applications that run code from the heap. If HEAP_CREATE_ENABLE_EXECUTE is not specified and an application attempts to run code from a protected page, the application receives an exception with the status code STATUS_ACCESS_VIOLATION.

I think POSIX has equivalent memory protection calls, but no equivalent to HeapCreate

But you can still call VirtualAlloc(), VirtualProtect(), and LoadLibrary(), so this isn't really a security mechanism, but more of a safety mechanism.

I don't think Windows provides a mechanism to disable creating any further executable pages, although I've seen Chrome do it by hooking those functions (and I know it because I've had to bypass it :)).

App Sandboxing and VBS enclaves go onto that direction.

I wouldn't expect windows to prevent creating further executable pages; there are legitimate use cases for creating dynamically allocated executable memory. It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code)

There are legitimate uses, but the point would be that the process could ask the system to lock it down with whatever executable code is already present. This could be used to prevent already running code from tampering with the process' behavior by loading new code, or to thwart code injection.

>It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code)

But malloc() and all the other standard memory allocation functions already return pointers into non-executable pages, anyway. Perhaps those functions call into this one internally, but using this over whatever your language offers by default offers no additional protection.

The benefit of heapalloc and heapcreate is that it makes serialization of data simpler because you can define the bounds of the heap so you can easily save pointer offsets. There are other flags available as well. It's a win32 feature so you would only use it if windows is your target platform (and then write other bindings for other platforms)

I still don't get it. Why can't you do the same with a regular buffer?

All of this calls VirtualAlloc behind the scenes, and you can do that yourself as well for manual page allocation. Each page can have options set with VirtualProtect to allow or disallow execution of code within the pages as well.

iOS won't let you do that. Or at least Apple won't let you do that on iOS.

What's actually happening is that the SDK doesn't expose the system calls necessary to do it, but I can guarantee that if you can get a native binary to run on the device, you can have it do whatever you want. If that wasn't the case, the few apps that do support JITting wouldn't work.