Re: [RFC/PATCH v2 01/10] Add kernel address sanitizer infrastructure.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
>> +
> 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]