lkml.org 
[lkml]   [2014]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.
>> +
>




\
 
 \ /
  Last update: 2014-09-15 18:01    [W:0.229 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site