0

Is there a way to find out which anonymous Virtual Memory Areas are created/accessed by libc?

I have a program that mprotects VMAs on its address space. But when it mprotects an area that will be accessed by libc, a SIGSEGV occurs. Unfortunately, the signal handler that I've installed only handles faults that occurred on my code, and not libc's.

In detail, the fault I am getting is because printf uses varargs. It tries to access the location of reg_save_area which is within the va_list structure. That location belongs to an anonymous VMA which I have earlier mprotected.

So, is there a to know which are these areas before I mprotect them? Or at least a way to know where stdarg.h chooses to place reg_save_area?

The most clean way would be to handle SIGSEGV's that occur within the libc. But I doubt that there is such a way.

Note: The data/bss segment of libc can be easily identified because it is not anonymous. If I mprotect that VMA too, it will also cause an unhandled SIGSEGV, which is why I choose not to.

user12205
  • 2,684
  • 1
  • 20
  • 40
Paschalis
  • 11,929
  • 9
  • 52
  • 82

2 Answers2

4

The simplest answer to your question is: all of them except the ones that you explicitly mapped yourself.

Do not do mprotect memory ranges that you didn't mmap yourself. Libraries and possibly even the kernel will do things behind your back all the time. They will do their own allocations and mappings. You are not allowed to change them because they are not yours to manage.

Btw. I really do mean mmap above. The protection of memory you get from malloc or any other allocating function is not yours to touch either. If you want full control over your memory mappings, do not use libc and don't do dynamic linking.

Art
  • 19,807
  • 1
  • 34
  • 60
  • thanks you. Nice idea. However, currently I am trying something else that it might work. I 'll give an update a bit later! – Paschalis Jul 10 '15 at 13:14
  • @Paschalis What you're doing is firing a shotgun into the engine of your car then asking the internet where to aim so that it doesn't catch fire. The correct answer isn't to tell you where to aim, but to tell you to stop shooting your engine with a shotgun. – Art Jul 10 '15 at 13:16
  • Yes, this is exactly how it looks like, unless you know the reason that I am doing it! ;) – Paschalis Jul 26 '15 at 16:03
0

The most clean way would be to handle SIGSEGV's that occur within the libc. But I doubt that there is such a way.

Actually, the SIGSEGV's that are caused withing the C library's code can be handled. And I do handle them. The SIGSEGV's cannot be handled are the ones that occur either within the handler function itself, or within the function that is doing the mprotection of VMAs.

So, is there a to know which are these areas before I mprotect them? Or at least a way to know where stdarg.h chooses to place reg_save_area?

There's no way to know which areas are created by libc, other than the recommendation by @Art, but the solution to my problem was by skipping the protection of pages that were being used by the handler itself, or the function that was setting up the whole protection mechanism.

PS. I don't consider this as an answer to my question, as it simply does not answer the question I asked. It solved my original problem though, and that's why I am sharing it.

Paschalis
  • 11,929
  • 9
  • 52
  • 82