On 6/18/19 3:56 PM, Arnd Bergmann wrote:
> On Mon, Jun 17, 2019 at 4:02 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>>
>> On Mon, Jun 17, 2019 at 02:31:09PM +0200, Arnd Bergmann wrote:
>>> objtool points out a condition that it does not like:
>>>
>>> lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x4a: call to stackleak_track_stack() with UACCESS enabled
>>> lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x4a: call to stackleak_track_stack() with UACCESS enabled
>>>
>>> I guess this is related to the call ubsan_type_mismatch_common()
>>> not being inline before it calls user_access_restore(), though
>>> I don't fully understand why that is a problem.
>>
>> The rules are that when AC is set, one is not allowed to CALL schedule,
>> because scheduling does not save/restore AC. Preemption, through the
>> exceptions is fine, because the exceptions do save/restore AC.
>>
>> And while most functions do not appear to call into schedule, function
>> trace ensures that every single call does in fact call into schedule.
>> Therefore any CALL (with AC set) is invalid.
>
> I see that stackleak_track_stack is already marked 'notrace',
> since we must ensure we don't recurse when calling into it from
> any of the function trace logic.
>
> Does that mean we could just mark it as another safe call?
>
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -486,6 +486,7 @@ static const char *uaccess_safe_builtin[] = {
> "__ubsan_handle_type_mismatch",
> "__ubsan_handle_type_mismatch_v1",
> /* misc */
> + "stackleak_track_stack",
> "csum_partial_copy_generic",
> "__memcpy_mcsafe",
> "ftrace_likely_update", /* CONFIG_TRACE_BRANCH_PROFILING */
>
>
>> Maybe we should disable stackleak when building ubsan instead? We
>> already disable stack-protector when building ubsan.
>
> I couldn't find out how that is done.
>
I guess this:
ccflags-y += $(DISABLE_STACKLEAK_PLUGIN)
