projects / linux-block.git / blame
| 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. |