DynamoRIO / DynamoRIO/dynamorio

additional special heap unit sizes and reservations are not page-aligned

Open
#3,439 0 comments 0 reactions 1 assignee Claimed by @derekbruening View on GitHub
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 15h
Merged PRs (30d)
31

Description

I noticed this while debugging a large app.
Here are its 4 stub units:

```
(gdb) p *((special_units_t*)stub_heap)->top_unit
$38 = {
alloc_pc = 0x4c1d5000 "",
start_pc = 0x4c1d5030 "geH\243",
end_pc = 0x4c1d6000 "",
cur_pc = 0x4c1d6000 "",
reserved_end_pc = 0x4c1d6000 "",
next = 0x4d18f000
}
(gdb) p *((special_units_t*)stub_heap)->top_unit->next
$39 = {
alloc_pc = 0x4d18f000 "",
start_pc = 0x4d18f030 "geH\243",
end_pc = 0x4d191020 "",
cur_pc = 0x4d191015 "",
reserved_end_pc = 0x4d191020 "",
next = 0x4da66000
}
(gdb) p *((special_units_t*)stub_heap)->top_unit->next->next
$40 = {
alloc_pc = 0x4da66000 "",
start_pc = 0x4da66030 "geH\243",
end_pc = 0x4da6a060 "",
cur_pc = 0x4da6a056 "",
reserved_end_pc = 0x4da6a060 "",
next = 0x4ddd5000
}
(gdb) p *((special_units_t*)stub_heap)->top_unit->next->next->next
$41 = {
alloc_pc = 0x4ddd5000 "",
start_pc = 0x4ddd5030 "geH\243",
end_pc = 0x4ddd7000 ,
cur_pc = 0x4ddd657b "",
reserved_end_pc = 0x4dddd0e0 ,
next = 0x0
}

$ grep 4c1d proc_maps
4c1c5000-4c1d5000 rwxp 00000000 00:00 0
4c1d5000-4c1d7000 rwxp 00000000 00:00 0
4c1d7000-4c2aa000 rw-p 00000000 00:00 0
$ grep 4d18 proc_maps
4d17f000-4d180000 rwxp 00000000 00:00 0
4d180000-4d18f000 ---p 00000000 00:00 0
4d18f000-4d192000 rwxp 00000000 00:00 0
$ grep 4da6 proc_maps
4da3c000-4da66000 rw-p 00000000 00:00 0
4da66000-4da6b000 rwxp 00000000 00:00 0
4da6b000-4da6c000 rw-p 00000000 00:00 0
$ grep 4ddd proc_maps
4ddcd000-4ddd5000 rw-p 00000000 00:00 0
4ddd5000-4ddd6000 rwxp 00000000 00:00 0
4ddd6000-4ddd7000 rw-p 00000000 00:00 0
4ddd7000-4ddde000 ---p 00000000 00:00 0
4ddde000-4dde0000 rw-p 00000000 00:00 0
```

We're running -no_guard_pages here with a small initial heap size as well.
Strangely it gets off of page alignment: ok it's b/c UNIT_RESERVED_ROOM
uses start_pc instead of alloc_pc. So it's allocating non-page-aligned
sizes. It's b/c special heaps have an offset start_pc unlike regular
heaps.

I think the only consequence is wasting space.

We do have:
#define SPECIAL_UNIT_RESERVED_SIZE(u) ((u)->reserved_end_pc - (u)->alloc_pc)

But special_heap_calloc uses UNITALLOC(u) which uses UNIT_RESERVED_SIZE().

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.