Le 12/12/2019 à 08:42, Balbir Singh a écrit :
On 12/12/19 1:24 am, Daniel Axtens wrote:
Hi Balbir,
+Discontiguous memory can occur when you have a machine with memory spread
+across multiple nodes. For example, on a Talos II with 64GB of RAM:
+
+ - 32GB runs from 0x0 to 0x0000_0008_0000_0000,
+ - then there's a gap,
+ - then the final 32GB runs from 0x0000_2000_0000_0000 to 0x0000_2008_0000_0000
+
+This can create _significant_ issues:
+
+ - If we try to treat the machine as having 64GB of _contiguous_ RAM, we would
+ assume that ran from 0x0 to 0x0000_0010_0000_0000. We'd then reserve the
+ last 1/8th - 0x0000_000e_0000_0000 to 0x0000_0010_0000_0000 as the shadow
+ region. But when we try to access any of that, we'll try to access pages
+ that are not physically present.
+
If we reserved memory for KASAN from each node (discontig region), we might survive
this no? May be we need NUMA aware KASAN? That might be a generic change, just thinking
out loud.
The challenge is that - AIUI - in inline instrumentation, the compiler
doesn't generate calls to things like __asan_loadN and
__asan_storeN. Instead it uses -fasan-shadow-offset to compute the
checks, and only calls the __asan_report* family of functions if it
detects an issue. This also matches what I can observe with objdump
across outline and inline instrumentation settings.
This means that for this sort of thing to work we would need to either
drop back to out-of-line calls, or teach the compiler how to use a
nonlinear, NUMA aware mem-to-shadow mapping.
Yes, out of line is expensive, but seems to work well for all use cases.
I'm not sure this is true. Looking at scripts/Makefile.kasan, allocas,
stacks and globals will only be instrumented if you can provide
KASAN_SHADOW_OFFSET. In the case you're proposing, we can't provide a
static offset. I _think_ this is a compiler limitation, where some of
those instrumentations only work/make sense with a static offset, but
perhaps that's not right? Dmitry and Andrey, can you shed some light on
this?
From what I can read, everything should still be supported, the info page
for gcc states that globals, stack asan should be enabled by default.
allocas may have limited meaning if stack-protector is turned on (no?)
Where do you read that ?
As far as I can see, there is not much details about
-fsanitize=kernel-address and -fasan-shadow-offset=number in GCC doc
(https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html)
[...]
I think I got CONFIG_PHYS_MEM_SIZE_FOR_KASN wrong, honestly I don't get why
we need this size? The size is in MB and the default is 0.
Why does the powerpc port of KASAN need the SIZE to be explicitly specified?
AFAICS, it is explained in details in Daniel's commit log. That's
because on book3s64, KVM requires KASAN to also work when MMU is off.
The 0 default is for when CONFIG_KASAN is not selected, in order to
avoid a forest of #ifdefs in the code.
Christophe
