59 lines
2.4 KiB
Plaintext
59 lines
2.4 KiB
Plaintext
|
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 limitiation, 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.
|