On Fri, Mar 09, 2018 at 07:42:19PM +0100, Andrey Konovalov wrote:
> On Fri, Mar 9, 2018 at 7:32 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
> > Well, that's not quite how it works. KVM is an integral part of the
> > kernel, and I don't really want to have to deal with regression (not to
> > mention that KVM is an essential tool in our testing infrastructure).
> >
> > You could try and exclude KVM from the instrumentation (which we already
> > have for invasive things such as KASAN), but I'm afraid that having a
> > debugging option that conflicts with another essential part of the
> > kernel is not an option.
>
> Hm, KHWASAN instruments the very same parts of the kernel that KASAN
> does (it reuses the same flag).
Sure, but KASAN doesn't fiddle with the tag in pointers, and the KVM hyp
code relies on EL1/EL2 pointers having a fixed offset from each other
(implicitly relying on addr[63:56] being zero).
We have two aliases of the kernel in two disjoint address spaces:
TTBR0 TTBR1
-SS-KKKK-------- EL1 kernel mappings
----KKKK-------- EL2 hyp mappings
To convert between the two, we just flip a few high bits of the address.
See kern_hyp_va() in <asm/kvm_mmu.h>.
The EL1 mappings have the KASAN shadow, and kernel. The EL2 mappings
just have the kernel. So long as we don't instrument EL2 code with
KASAN, it's fine for EL1 code to be instrumented.
However, with KHASAN, pointers generated by EL1 will have some arbitrary
tag, and more work needs to be done to convert an address to its EL2
alias.
Thanks,
Mark.
