On 09/11/2014 08:01 AM, H. Peter Anvin wrote: > On 09/10/2014 07:31 AM, Andrey Ryabinin wrote: >> This patch add arch specific code for kernel address sanitizer. >> >> 16TB of virtual addressed used for shadow memory. >> It's located in range [0xffff800000000000 - 0xffff900000000000] >> Therefore PAGE_OFFSET has to be changed from 0xffff880000000000 >> to 0xffff900000000000. > > NAK on this. > > 0xffff880000000000 is the lowest usable address because we have agreed > to leave 0xffff800000000000-0xffff880000000000 for the hypervisor or > other non-OS uses. > > Bumping PAGE_OFFSET seems needlessly messy, why not just designate a > zone higher up in memory? > I already answered to Dave why I choose to place shadow bellow PAGE_OFFSET (answer copied bellow). In short - yes, shadow could be higher. But for some sort of kernel bugs we could have confusing oopses in kasan kernel. On 09/11/2014 12:30 AM, Andrey Ryabinin wrote: > 2014-09-10 19:46 GMT+04:00 Dave Hansen <dave.hansen@xxxxxxxxx>: >> >> Is there a reason this has to be _below_ the linear map? Couldn't we >> just carve some space out of the vmalloc() area for the kasan area? >> > > Yes, there is a reason for this. For inline instrumentation we need to > catch access to userspace without any additional check. > This means that we need shadow of 1 << 61 bytes and we don't have so > many addresses available. However, we could use > hole between userspace and kernelspace for that. For any address > between [0 - 0xffff800000000000], shadow address will be > in this hole, so checking shadow value will produce general protection > fault (GPF). We may even try handle GPF in a special way > and print more user-friendly report (this will be under CONFIG_KASAN of course). > > But now I realized that we even if we put shadow in vmalloc, shadow > addresses corresponding to userspace addresses > still will be in between userspace - kernelspace, so we also will get GPF. > There is the only problem I see now in such approach. Lets consider > that because of some bug in kernel we are trying to access > memory slightly bellow 0xffff800000000000. In this case kasan will try > to check some shadow which in fact is not a shadow byte at all. > It's not a big deal though, kernel will crash anyway. In only means > that debugging of such problems could be a little more complex > than without kasan. > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>