Messages in this thread | | | Date | Mon, 15 Sep 2014 19:28:14 +0400 | From | Andrey Ryabinin <> | Subject | Re: [RFC/PATCH v2 01/10] Add kernel address sanitizer infrastructure. |
| |
On 09/14/2014 05:35 AM, Randy Dunlap wrote: > Following sentence is confusing. I'm not sure how to fix it. >
Perhaps rephrase is like this:
Do not use slub poisoning with KASan if user tracking enabled (iow slub_debug=PU). User tracking info (allocation/free stacktraces) are stored inside slub object's metadata. Slub poisoning overwrites slub object and it's metadata with poison value on freeing. So if KASan will detect use after free, allocation/free stacktraces will be overwritten and KASan won't be able to print them.
>> +Please don't use slab poisoning with KASan (slub_debug=P), beacuse if KASan will > > drop: will > >> +detects use after free allocation and free stacktraces will be overwritten by > > maybe: use after free, > >> +poison bytes, and KASan won't be able to print this backtraces. > > backtrace. > >> + >> +Each shadow byte corresponds to 8 bytes of the main memory. We use the >> +following encoding for each shadow byte: 0 means that all 8 bytes of the >> +corresponding memory region are addressable; k (1 <= k <= 7) means that >> +the first k bytes are addressable, and other (8 - k) bytes are not; >> +any negative value indicates that the entire 8-byte word is unaddressable. >> +We use different negative values to distinguish between different kinds of >> +unaddressable memory (redzones, freed memory) (see mm/kasan/kasan.h). >> + > > Is there any need for something similar to k (1 <= k <= 7) but meaning that the > *last* k bytes are addressable instead of the first k bytes? >
There is no need for that. Slub allocations are always 8 byte aligned (at least on 64bit systems). Now I realized that it could be a problem for 32bit systems. Anyway, the best way to deal with that would be align allocation to 8 bytes.
>> +Poisoning or unpoisoning a byte in the main memory means writing some special >> +value into the corresponding shadow memory. This value indicates whether the >> +byte is addressable or not. >> + >
| |