Is there a way to mark a piece of allocated memory as read-only?

Question

if I allocate some memory using malloc() , there is a way to mark it read-only. So memcpy () fails if someone tries to write to it?

This is due to the faulty api architecture, where users skip the const pointer returned by the GetValue() method, which is part of a large memory structure. Since we want to avoid copying a large piece of memory, we return a live pointer inside structured memory, which has a specific format. Now the problem is that some users find a hack to get things that work directly when writing to this memory and avoid calling SetValue (), which distributes and correctly transfers the binary memory format that we developed. Despite the fact that it once worked, but sometimes it causes a violation of memory access due to incorrect interpretation of control flags that were canceled by the user.

Educating the user is one of the tasks, but let me say that now we want the code to crash there.

I'm just wondering if we can just protect against this case.

For an analogy, suppose someone gets a blob column from a sqlite statement and then writes back. Although in the case of sqlite this will not make sense, but this is a bit of a hassle in our case.

Answer 1

On most hardware architectures, you can only change security attributes on entire pages of memory; You cannot mark a fragment of a page as read-only.

Relevant APIs:

• mprotect() on Unix;
• VirtualProtect() on Windows.

You need to make sure that the memory page does not contain anything that you do not want to do read-only. To do this, you will either have to combine with malloc() , or use another distribution API, for example mmap() , posix_memalign() or VirtualAlloc() .

Answer 2

Depends on the platform. On Linux, you can use mprotect () ( http://linux.die.net/man/2/mprotect ).

On Windows, you can try VirtualProtect () ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).aspx ). I have never used it, though.

Edit: This is not a duplicate of the NPE answer. NPE originally had a different answer; it was edited later, and mprotect () and VirtualProtect () were added.

Answer 3

erroneous api design, where users skip the const pointer returned by GetValue (), which is part of a large memory structure. Since we want to avoid copying a large fragment of memory, we return a pointer to the live image inside structured memory, which has a specific format

This is clearly not an API design error. An API is a contract: you promise that your class will behave in a certain way, clients of this class promise to use the API appropriately. Dirty tricks like const_cast are wrong (and in some, but not all cases, have undefined behavior ).

It would be a design error if using const_cast would lead to a security problem. In this case, you must copy a piece of memory or reverse engineer the API. This is the norm in Java , which does not have the equivalent of const (despite const being a reserved word in Java).

Answer 4

Discuss the pointer. those. return the pointer plus offset to the client, now they cannot use the pointer directly. whenever a pointer is passed into your code through the official API, subtract the offset and use the pointer as usual.