OLD | NEW |
| (Empty) |
1 # PartitionAlloc Design | |
2 | |
3 This document explains a high-level design of PartitionAlloc. | |
4 If you're interested in its in-depth implementation, see comments | |
5 in PartitionAlloc.h. | |
6 | |
7 [TOC] | |
8 | |
9 ## Overview | |
10 | |
11 PartitionAlloc is a memory allocator optimized for performance and security | |
12 in Blink. All objects in Blink are expected to be allocated with | |
13 PartitionAlloc or Oilpan (but not yet done). | |
14 | |
15 ## Partitions and buckets | |
16 | |
17 PartitionAlloc has three partitions. A partition is a heap that contains | |
18 certain types of objects. Specifically, PartitionAlloc allocates objects | |
19 on either of the following three partitions depending on their types: | |
20 | |
21 * LayoutObject partition: A partition to allocate LayoutObjects. | |
22 | |
23 * Buffer partition: A partition to allocate objects that have a strong risk | |
24 that the length and/or the contents are exploited by user scripts. | |
25 Specifically, Vectors, HashTables, ArrayBufferContents and Strings are | |
26 allocated on the Buffer partition. | |
27 | |
28 * FastMalloc partition: A partition to allocate all other objects. | |
29 Objects marked with USING_FAST_MALLOC are allocated on the FastMalloc partition. | |
30 | |
31 Each partition holds multiple buckets. A bucket is a region in a partition | |
32 that contains similar-sized objects. Each object allocation must be aligned | |
33 with the closest bucket size. For example, if a partition has three buckets | |
34 for 64 bytes, 256 bytes and 1024 bytes, then an object of 128 bytes is | |
35 rounded up to 256 bytes and allocated on the second bucket. | |
36 | |
37 The LayoutObject partition has buckets for all N * sizeof(void*) (N = 1, 2, ...,
N_max). | |
38 This means that no extra padding is needed to allocate a LayoutObject object. | |
39 Different sizes of LayoutObjects are allocated in different buckets. | |
40 | |
41 The Buffer partition and the FastMalloc partition have many buckets. | |
42 They support any arbitrary size of allocations but padding may be added | |
43 to align the allocation with the closest bucket size. The bucket sizes are | |
44 chosen to keep the worst-case memory overhead less than 10%. | |
45 | |
46 Large allocations (> 1 MB) are realized by direct memory mmapping. | |
47 | |
48 ## Performance | |
49 | |
50 PartitionAlloc doesn't acquire a lock when allocating on the LayoutObject | |
51 partition, because it's guaranteed that LayoutObjects are allocated | |
52 only by the main thread. | |
53 | |
54 PartitionAlloc acquires a lock when allocating on the Buffer partition and | |
55 the FastMalloc partition. PartitionAlloc uses a spin lock because thread content
ion | |
56 would be rare in Blink. | |
57 | |
58 PartitionAlloc is designed to be extremely fast in fast paths. Just two | |
59 (reasonably predictable) branches are required for the fast paths of an | |
60 allocation and deallocation. The number of operations in the fast paths | |
61 is minimized, leading to the possibility of inlining. | |
62 | |
63 Having a dedicated partition for LayoutObjects is helpful to improve cache | |
64 locality and thus help improve performance. | |
65 | |
66 ## Security | |
67 | |
68 Security is one of the most important goals of PartitionAlloc. | |
69 | |
70 Different partitions are guaranteed to exist in separate address spaces. | |
71 When objects contained in a page in a partition are all freed, | |
72 the physical memory is returned to the system but the address space | |
73 remains reserved. The address space may be reused later only for the partition. | |
74 Remember that PartitionAlloc puts LayoutObjects into a dedicated partition. | |
75 This is because LayoutObjects are likely to be a source of use-after-free. | |
76 Simiarly, PartitionAlloc puts Strings, Vectors etc into the Buffer partition | |
77 because the length and/or contents may be exploited by user scripts. | |
78 This means that PartitionAlloc greedily uses virtual address spaces in favor of | |
79 security hardening. | |
80 | |
81 Also the following security properties are provided: | |
82 | |
83 * Linear overflows cannot corrupt into the partition. | |
84 | |
85 * Linear overflows cannot corrupt out of the partition. | |
86 | |
87 * Metadata is recorded in a dedicated region (not next to each object). | |
88 Linear overflow or underflow cannot corrupt the metadata. | |
89 | |
90 * Buckets are helpful to allocate different-sized objects on different addresses
. | |
91 One page can contain only similar-sized objects. | |
92 | |
93 * Dereference of a freelist pointer should fault. | |
94 | |
95 * Partial pointer overwrite of freelist pointer should fault. | |
96 | |
97 * Large allocations are guard-paged at the beginning and end. | |
OLD | NEW |