forked from Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
58 lines
2.4 KiB
58 lines
2.4 KiB
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.
|
|
|