On 12/13/2016 05:13 PM, Dmitry Vyukov wrote:

On Tue, Dec 13, 2016 at 2:59 PM, Andrey Ryabinin
[off-list ref] wrote:

quoted

On 12/13/2016 12:38 PM, Dmitry Vyukov wrote:

quoted

On Tue, Dec 13, 2016 at 10:20 AM, Andrey Ryabinin
[off-list ref] wrote:

quoted

On 12/13/2016 11:58 AM, Dmitry Vyukov wrote:

quoted

--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst

@@ -40,6 +40,14 @@ similar to the following to the respective kernel Makefile:

     KASAN_SANITIZE := n

+Sometimes it may be useful to disable instrumentation of reads, or writes
+or both for the entire kernel. For example, if binary size is a concern,
+it may be useful to disable instrumentation of reads to reduce binary size but
+still catch more harmful bugs on writes. Or, if one is interested only in
+sanitization of a particular module and performance is a concern, she can
+disable instrumentation of both reads and writes for kernel code.
+Instrumentation can be disabled with CONFIG_KASAN_READS and

CONFIG_KASAN_WRITES.
+

I don't understand this. How this can be related to modules? Configs are global.
You can't just disable/enable config per module.

Build everything without instrumentation. Then enable instrumentation
and do "make lib/test_kasan.ko".
Or build everything, copy out bzImage, change config, build everything again.

Yeah, this is soooooo convenient...

Seriously speaking, per-file instrumentation is absolutely irrelevant to this patch and should have been
addressed from a different angle. E.g. see how UBSAN/GCOV/KCOV do that.

KASAN already has that functionality (i.e. KASAN_SANITIZE_main.o :=
n). But that functionality is intended for cases when we want to
persistently disable instrumentation of some files (e.g. if they cause
crashes of false positives). CONFIG_KASAN_READS/WRITES is intended for
situations when one wants to disable instrumentation wholesale.

I'm talking about UBSAN_SANITIZE_ALL/KCOV_INSTRUMENT_ALL/GCOV_PROFILE_ALL
KASAN doesn't have something similar. I didn't add this because IMO it's not very useful for KASAN.
One may have a bug in instrumented code, but it can be easily missed if access is done in generic
code. Very simple example is passing invalid pointer in strcpy()

quoted

As for this patch, I'd say only one option would be enough - KASAN_DONT_SANITIZE_READS.
Nobody wants to sanitize only reads without writes, right? Writes are fewer and more dangerous.

I've asked this question in v1. See the case related to modules -- one
can use completely uninstrumented kernel, but load an instrumented
modules.

I get it, but again, it's not the right way to address this problem.