Messages in this thread | | | Date | Thu, 11 Sep 2014 09:31:10 +0400 | From | Andrey Ryabinin <> | Subject | Re: [RFC/PATCH v2 02/10] x86_64: add KASan support |
| |
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@intel.com>: >> >> 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. > >
| |