This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCHv4] Enable -fsanitize-recover for KASan

On 10/23/2014 01:55 PM, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
>> IMO we don't need different versions of __asan_load* and __asan_load*_noabort, because
>> -fno-sanitize-recover=kernel-address will never work with the linux kernel.
>> I already said this before, and repeat this once again:
>> There is few places in kernel where we validly touch poisoned memory,
>> so we need to disable error reporting in runtime for such memory accesses.
>> I use per-thread flag which is raised before the valid access to poisoned memory.
>> This flag checked in __asan_report*() function. If it raised then we shouldn't print any error message,
>> just silently exit from report.
> Can't you just use __attribute__((no_sanitize_address)) on the functions
> that have such a code?  Or you could use special macros for those accesses
> (which could e.g. call function to read memory or write memory, implemented
> in assembly or in __attribute__((no_sanitize_address)) function), or

Those are quite generic functions used from a lot of places. So we want to instrument
them in general, but there are few call sites which use those functions for poisoned memory.

> temporarily unpoison and poison again.

That's a bit tricky. State of shadow memory is unknown, so we would need to store shadow
somewhere before unpoisoning to restore it later.

> 	Jakub

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]