Hi Andrey, On 09/03/18 18:21, Andrey Konovalov wrote: > On Tue, Mar 6, 2018 at 3:24 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> On 05/03/18 14:36, Mark Rutland wrote: >>> On Fri, Mar 02, 2018 at 08:44:25PM +0100, Andrey Konovalov wrote: >>>> KHWASAN uses the Top Byte Ignore feature of arm64 CPUs to store a pointer >>>> tag in the top byte of each pointer. This commit enables the TCR_TBI1 bit, >>>> which enables Top Byte Ignore for the kernel, when KHWASAN is used. >>>> --- >>>> arch/arm64/include/asm/pgtable-hwdef.h | 1 + >>>> arch/arm64/mm/proc.S | 8 +++++++- >>>> 2 files changed, 8 insertions(+), 1 deletion(-) >>> >>> Before it's safe to do this, I also think you'll need to fix up at >>> least: >>> >>> * virt_to_phys() >>> >>> * access_ok() >>> >>> ... and potentially others which assume that bits [63:56] of kernel >>> addresses are 0xff. For example, bits of the fault handling logic might >>> need fixups. >> >> Indeed. I have the ugly feeling that KVM (and anything that leaves in a >> separate address space) will not be very happy with that change, as it >> derives HYP VAs from the kernel VA, and doesn't expect lingering bits. >> Nothing that cannot be addressed, but worth keeping in mind. >> > > Hi Marc! > > Yes, I would expect there would be issues with KVM. I'll see if I can > figure them out, but I think I'll just add a depends on !KVM or > something like this, and will have to deal with KVM once the main part > is committed. 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. I'm happy to help you with that though. Thanks, M. -- Jazz is not dead. It just smells funny...
