Apply TBI to virtual addresses on aarch64.

[pcc]

In tag-based KASAN modes, TCR_EL1.TBI1 is enabled, which causes the top 8 bits of virtual addresses to be ignored for address translation purposes. Do the same in the page table iterator. There is no harm in doing so unconditionally, as the architecture does not support >56 bit VA sizes.

[osandov]

There is no harm in doing so unconditionally

On non-KASAN configurations, this could lead us to read from bogus addresses with garbage in the most significant bits without realizing this, right? If there's an easy way to avoid this, it'd be nice to, but otherwise it's not a huge deal.

I also wonder whether it makes sense to apply this mask earlier than in the page table iterator. /proc/kcore at least exports the kernel memory ranges so that the page table iterator isn't normally needed, so applying the mask earlier in the memory reader code could avoid calling the page table iterator at all. It is still used for vmalloc and module memory for vmcores. Whether this would help you depends on how your remote target exports memory ranges, though.

[pcc]

On non-KASAN configurations, this could lead us to read from bogus addresses with garbage in the most significant bits without realizing this, right?

In most cases with garbage addresses it seems unlikely that bits 56..63 will contain garbage without bits VA_BITS..55 also containing garbage, so I don't think we lose much by masking out these bits.

If there's an easy way to avoid this, it'd be nice to, but otherwise it's not a huge deal.

Yes, the KASAN state isn't really exposed very easily. We could do something like check for the presence of KASAN-specific symbols in the kernel symbol table, but with HW tags KASAN there's also a runtime component to whether KASAN is enabled (it can be disabled with kasan=off or if the hardware doesn't support MTE). It's also worth noting that TBI0 is also enabled in all userspace processes, so we'd need to mask the bits when reading a userspace page table even if KASAN is disabled. So I reckon it's probably not worth it.

I also wonder whether it makes sense to apply this mask earlier than in the page table iterator. /proc/kcore at least exports the kernel memory ranges so that the page table iterator isn't normally needed, so applying the mask earlier in the memory reader code could avoid calling the page table iterator at all.

I think it makes sense. We could have something like an arch-specific hook for fixing up tagged addresses (similar to untagged_addr in the kernel).

Whether this would help you depends on how your remote target exports memory ranges, though.

For my remote target support, I just have one direct mapping in virtual space of size 4096 for the swapper page table and everything else uses the page table reader. I hadn't looked at the /proc/kcore support very closely so I hadn't realized that most things weren't going through the page table reader in that case.

[pcc]

I think it makes sense. We could have something like an arch-specific hook for fixing up tagged addresses (similar to untagged_addr in the kernel).

Done in the new patch.

[pcc]

Rebased; ping. I needed to patch this in so that I could test #376 with tag-based KASAN.

[osandov]

Thanks!