Implement KASAN

[balbirsinghcan]

We should really implement KASAN for radix, there are sample implementations for x86 and arm64. We could a hash implementation as well, but that requires a little more juggling of virtual address space and some work to bolt mappings for shadow space.

[chleroy]

For information, a KASAN implementation for nohash ppc32 was proposed there https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=55450

[mpe]

Balbir did an RFC for Radix:
https://patchwork.ozlabs.org/patch/795211/

[mpe]

Aneesh also did some work on a hash implementation, not sure what state it's in:

https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=&submitter=664&state=*&q=kasan

[chleroy]

ppc32 implementation is at https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=87535

[chleroy]

Looks like both the Radix and the Hash64 implementations are relatively old and should be revisited.

Both do behavioural modifications to the core part of KASAN it looks. Are those modifications unavoidable ?

[mpe]

I'm not sure they're unavoidable, but we need to change something to get KASAN working. Either we tweak the generic code to cater to powerpc weirdness or we tweak powerpc code to work with the existing KASAN code. It's not clear to me what the right trade off is at the moment.

[chleroy]

At the time being, the ppc32 implementation sets up an early shadow mapping on the same model as arm64 and x86, ie using several PGD entries all pointing on the same single pagetable. All the PTEs of that pagetable points to the shadow zero page. This works for nohash32 and for non-hash 6xx (book3s), ie for the 603.

For other 6xx, ie the ones using a hash table, we need:
1/ One pagetable for each PGD entry, because of the _PAGE_HASHPTE flag.
2/ To set up an hash table early.

Point 1/ is easy to do, it will just take some more static init memory (32 pagetables, 4k for each pagetable ie 128k bytes).

At the time being, the hash table is dynamically allocated with memblock_alloc() based on the amount of RAM. All the low level code handling the hash tables is written for a 256kB hash table, and patched at runtime to take into account the real size of the hash table.

For point 2/, my idea is to early set up a static 256 kB hash table in init memory, and then switch to the final hash table once it is set up.

[chleroy]

Note that there is a nice explanation here about why it is necessary to do the early kasan init:

https://patchwork.ozlabs.org/patch/795211/#1740214

[daxtens]

I've had a lot of trouble with early init on 64bit because we do a lot of instrumented stuff like printk() very early, before we fully switch on the MMU (IIUC!). I was going to propose a core change to deal with it; we already need one for dealing with the discontiguous memory anyway...

…

On Mon, Feb 11, 2019 at 6:42 PM chleroy ***@***.***> wrote: Note that there is a nice explanation here about why it is necessary to do the early kasan init: https://patchwork.ozlabs.org/patch/795211/#1740214 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#106 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJ5BazPG5gyoLuO8D7B4itdpZjm3CKlks5vMR7_gaJpZM4Zy0K4> .

[chleroy]

On 32 bits, we have kernel space typically going from 0xC000000 to 0xffffffff.
The kasan shadow mem covers the entire kernel space, it is a 128Mbytes virtual area (1/8th of Kernel space) and we place it between the fixmap area and the vmalloc area.
So this works regardless of whether memory is contiguous or not as far as it is in the kernel space.

Can't the same principle apply to 64 bits ?

[daxtens]

On book3e nohash (e.g. e6500) we have the linear area going from 0xc000 0000 0000 0000 upwards and we have a non-linear area going from 0x8000 0000 0000 0000 to 0x8000 1000 0000 0000. So a shadow area that covers 0x8000 0000 0000 0000 to 0xc000 would take > (1/8) * 0x4000 0000 0000 0000 = > 0x0800 0000 0000 0000 bytes of shadow memory.

Unfortunately the pagetable range is only 1 << (9+7+9+9+12) = 1 << 46 = 0x0000 4000 0000 0000, so we can't make something big enough.

I think the situation is a bit better on 64-bit book3s as then the non-linear map is at 0xd000.... but I haven't tried that yet.

[I should add that I'm learning about ppc memory management as I go so I might be wrong on some details.]

[chleroy]

I've had a lot of trouble with early init on 64bit because we do a lot of instrumented stuff like printk() very early, before we fully switch on the MMU (IIUC!). I was going to propose a core change to deal with it; we already need one for dealing with the discontiguous memory anyway...
…
On Mon, Feb 11, 2019 at 6:42 PM chleroy @.***> wrote: Note that there is a nice explanation here about why it is necessary to do the early kasan init: https://patchwork.ozlabs.org/patch/795211/#1740214 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#106 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ADJ5BazPG5gyoLuO8D7B4itdpZjm3CKlks5vMR7_gaJpZM4Zy0K4 .

RFC at https://patchwork.ozlabs.org/patch/1068260/ shows how we can activate KASAN early enough in order to avoid early init troubles.

[chleroy]

PPC32 implementation at https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=104852

[chleroy]

PPC32 implementation merged into powerpc/next linuxppc/linux@2edb16e

[chleroy]

RADIX Implementation (Outline only) merged in linuxppc/linux@41b7a34

BOOK3E/64 merged in linuxppc/linux@c7b9ed7

[chleroy]

@mpe, are we expecting a KASAN implementation for HASH64 MMU, or is it finished ?