Commit | Line | Data |
---|---|---|
41b7a347 | 1 | KASAN is supported on powerpc on 32-bit and Radix 64-bit only. |
60e832de DA |
2 | |
3 | 32 bit support | |
4 | ============== | |
5 | ||
6 | KASAN is supported on both hash and nohash MMUs on 32-bit. | |
7 | ||
8 | The shadow area sits at the top of the kernel virtual memory space above the | |
9 | fixmap area and occupies one eighth of the total kernel virtual memory space. | |
10 | ||
11 | Instrumentation of the vmalloc area is optional, unless built with modules, | |
12 | in which case it is required. | |
41b7a347 DA |
13 | |
14 | 64 bit support | |
15 | ============== | |
16 | ||
17 | Currently, only the radix MMU is supported. There have been versions for hash | |
18 | and Book3E processors floating around on the mailing list, but nothing has been | |
19 | merged. | |
20 | ||
21 | KASAN support on Book3S is a bit tricky to get right: | |
22 | ||
23 | - It would be good to support inline instrumentation so as to be able to catch | |
24 | stack issues that cannot be caught with outline mode. | |
25 | ||
26 | - Inline instrumentation requires a fixed offset. | |
27 | ||
28 | - Book3S runs code with translations off ("real mode") during boot, including a | |
29 | lot of generic device-tree parsing code which is used to determine MMU | |
30 | features. | |
31 | ||
32 | - Some code - most notably a lot of KVM code - also runs with translations off | |
33 | after boot. | |
34 | ||
35 | - Therefore any offset has to point to memory that is valid with | |
36 | translations on or off. | |
37 | ||
38 | One approach is just to give up on inline instrumentation. This way boot-time | |
39 | checks can be delayed until after the MMU is set is up, and we can just not | |
40 | instrument any code that runs with translations off after booting. This is the | |
41 | current approach. | |
42 | ||
43 | To avoid this limitiation, the KASAN shadow would have to be placed inside the | |
44 | linear mapping, using the same high-bits trick we use for the rest of the linear | |
45 | mapping. This is tricky: | |
46 | ||
47 | - We'd like to place it near the start of physical memory. In theory we can do | |
48 | this at run-time based on how much physical memory we have, but this requires | |
49 | being able to arbitrarily relocate the kernel, which is basically the tricky | |
50 | part of KASLR. Not being game to implement both tricky things at once, this | |
51 | is hopefully something we can revisit once we get KASLR for Book3S. | |
52 | ||
53 | - Alternatively, we can place the shadow at the _end_ of memory, but this | |
54 | requires knowing how much contiguous physical memory a system has _at compile | |
55 | time_. This is a big hammer, and has some unfortunate consequences: inablity | |
56 | to handle discontiguous physical memory, total failure to boot on machines | |
57 | with less memory than specified, and that machines with more memory than | |
58 | specified can't use it. This was deemed unacceptable. |