diff options
Diffstat (limited to 'Documentation/powerpc/kasan.txt')
| -rw-r--r-- | Documentation/powerpc/kasan.txt | 58 |
1 files changed, 0 insertions, 58 deletions
diff --git a/Documentation/powerpc/kasan.txt b/Documentation/powerpc/kasan.txt deleted file mode 100644 index a4f647e4ff..0000000000 --- a/Documentation/powerpc/kasan.txt +++ /dev/null @@ -1,58 +0,0 @@ -KASAN is supported on powerpc on 32-bit and Radix 64-bit only. - -32 bit support -============== - -KASAN is supported on both hash and nohash MMUs on 32-bit. - -The shadow area sits at the top of the kernel virtual memory space above the -fixmap area and occupies one eighth of the total kernel virtual memory space. - -Instrumentation of the vmalloc area is optional, unless built with modules, -in which case it is required. - -64 bit support -============== - -Currently, only the radix MMU is supported. There have been versions for hash -and Book3E processors floating around on the mailing list, but nothing has been -merged. - -KASAN support on Book3S is a bit tricky to get right: - - - It would be good to support inline instrumentation so as to be able to catch - stack issues that cannot be caught with outline mode. - - - Inline instrumentation requires a fixed offset. - - - Book3S runs code with translations off ("real mode") during boot, including a - lot of generic device-tree parsing code which is used to determine MMU - features. - - - Some code - most notably a lot of KVM code - also runs with translations off - after boot. - - - Therefore any offset has to point to memory that is valid with - translations on or off. - -One approach is just to give up on inline instrumentation. This way boot-time -checks can be delayed until after the MMU is set is up, and we can just not -instrument any code that runs with translations off after booting. This is the -current approach. - -To avoid this limitation, the KASAN shadow would have to be placed inside the -linear mapping, using the same high-bits trick we use for the rest of the linear -mapping. This is tricky: - - - We'd like to place it near the start of physical memory. In theory we can do - this at run-time based on how much physical memory we have, but this requires - being able to arbitrarily relocate the kernel, which is basically the tricky - part of KASLR. Not being game to implement both tricky things at once, this - is hopefully something we can revisit once we get KASLR for Book3S. - - - Alternatively, we can place the shadow at the _end_ of memory, but this - requires knowing how much contiguous physical memory a system has _at compile - time_. This is a big hammer, and has some unfortunate consequences: inablity - to handle discontiguous physical memory, total failure to boot on machines - with less memory than specified, and that machines with more memory than - specified can't use it. This was deemed unacceptable. |