[PATCH][PING] Enable -fsanitize-recover for KASan

Yury Gribov y.gribov@samsung.com
Thu Sep 18 13:14:00 GMT 2014


Added Marek to comment on proposed UBSan option change.

On 09/18/2014 02:52 PM, Jakub Jelinek wrote:
>> --- a/gcc/opts.c
>> +++ b/gcc/opts.c
>> @@ -1551,6 +1551,12 @@ common_handle_option (struct gcc_options *opts,
>>   			     | SANITIZE_RETURNS_NONNULL_ATTRIBUTE))
>>   	  opts->x_flag_delete_null_pointer_checks = 0;
>>
>> +	/* UBSan and KASan enable recovery by default.  */
>> +	opts->x_flag_sanitize_recover
>> +	  = !!(flag_sanitize & (SANITIZE_UNDEFINED
>> +				| SANITIZE_UNDEFINED_NONDEFAULT
>> +				| SANITIZE_KERNEL_ADDRESS));
>> +
>
> Doesn't this override even user supplied -fsanitize-recover or
> -fno-sanitize-recover ?  Have you tried both
> -fno-sanitize-recover -fsanitize=kernel-address
> and
> -fsanitize=kernel-address -fno-sanitize-recover
> option orders?

I did and this worked in a seemingly logical way:
* -fsanitize=address (disable recovery)
* -fsanitize-recover -fsanitize=address (disable recovery)
* -fsanitize=address -fsanitize-recover (enable recovery)
* -fsanitize=kernel-address (enable recovery)
* -fno-sanitize-recover -fsanitize=kernel-address (enable recovery)
* -fsanitize=kernel-address -fno-sanitize-recover (enable recovery)

> Seems for -fdelete-null-pointer-checks we got it wrong too,
> IMHO for -fsanitize={null,{,returns-}nonnull-attribute,undefined}
> we want to disable it unconditionally, regardless of whether
> that option appears on the command line or not.

My understanding is that all 
-fsanitize=(address|kernel-address|undefined|you-name-it) are simply 
packs of options to enable. User may override any selected option from 
the pack if he so desires.

> I don't think your proposal will work properly though,
> if one compiles with
> -fsanitize=undefined -fsanitize=address
> you'll just get userland asan with error recovery, which is highly
> undesirable

Now that's a problem. Looks like I'll need a separate flag to achieve 
what I need (-fasan-recover? And maybe then rename -fsanitize-recover to 
-fubsan-recover for consistency?).

> or asan.c needs to limit it to flag_sanitize & SANITIZE_KERNEL_ADDRESS
> mode only.

We may want to UBsanitize kernel in future and this may cause the same 
problem as for userspace Asan/UBSan interaction you described above.

 > Depends if you ever want to add recovery for userland
 > sanitization.

Also kernel developers want both recoverable (more user-friendly) and 
non-recoverable (faster) Asan error handling.

-Y



More information about the Gcc-patches mailing list