netdev - Re: linux-next: build failure after merge of the net-next tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <94b98645-581b-7824-f116-2467d1987347@iogearbox.net>
Date:   Fri, 12 Jan 2018 17:21:54 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     David Miller <davem@...emloft.net>, sfr@...b.auug.org.au,
        netdev@...r.kernel.org, ast@...nel.org, linux-next@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the net-next tree

On 01/12/2018 04:56 PM, Alexei Starovoitov wrote:
> On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
>> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
>>> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
>>>> From: Alexei Starovoitov <alexei.starovoitov@...il.com>
>>>> Date: Wed, 10 Jan 2018 17:58:54 -0800
>>>>
>>>>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> After merging the net-next tree, today's linux-next build (x86_64
>>>>>> allmodconfig) failed like this:
>>>>>>
>>>>>> kernel/bpf/verifier.o: In function `bpf_check':
>>>>>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
>>>>>>
>>>>>> Caused by commit
>>>>>>
>>>>>>   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
>>>>>>
>>>>>> interacting with commit
>>>>>>
>>>>>>   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>>>>>>
>>>>>> from the bpf and net trees.
>>>>>>
>>>>>> I have just reverted commit 290af86629b2 for today.  A better solution
>>>>>> would be nice (lie fixing this in a merge between the net-next and net
>>>>>> trees).
>>>>>
>>>>> that's due to 'endif' from 290af86629b2 needs to be moved above
>>>>> bpf_patch_call_args() definition.
>>>>
>>>> That doesn't fix it, because then you'd need to expose
>>>> interpreters_args as well and obviously that can't be right.
>>>>
>>>> Instead, we should never call bpf_patch_call_args() when JIT always on
>>>> is enabled.  So if we fail to JIT the subprogs we should fail
>>>> immediately.
>>>
>>> right, as I was trying to say one extra hunk would be needed for net-next.
>>> I was reading this patch:
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index a2b211262c25..ca80559c4ec3 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env *env)
>>>                 depth = get_callee_stack_depth(env, insn, i);
>>>                 if (depth < 0)
>>>                         return depth;
>>> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
>>> +               return -ENOTSUPP;
>>> +#else
>>>                 bpf_patch_call_args(insn, depth);
>>> +#endif
>>>         }
>>>         return 0;
>>>
>>> but below should be fine too.
>>> Will test it asap.
>>>
>>>> This is the net --> net-next merge resolution I am about to use to fix
>>>> this:
>>>>
>>>> ...
>>>>  +static int fixup_call_args(struct bpf_verifier_env *env)
>>>>  +{
>>>>  +	struct bpf_prog *prog = env->prog;
>>>>  +	struct bpf_insn *insn = prog->insnsi;
>>>> - 	int i, depth;
>>>> ++	int i, depth, err;
>>>>  +
>>>> - 	if (env->prog->jit_requested)
>>>> - 		if (jit_subprogs(env) == 0)
>>>> ++	err = 0;
>>
>> Looks fine to me. The only thing I was wondering was whether we should
>> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
>> if for some reason we would missed to set prog->jit_requested bit under
>> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
>> calls in the prog. But that also means for bpf_prog_load() that right
>> after bpf_check() returned, we would go into bpf_prog_select_runtime()
>> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
>> from there wouldn't do anything either since prog->jit_requested was
>> not set in the first place, therefore we return with -ENOTSUPP from
>> there. So the resolution looks fine to me, we can leave it as is.
> 
> jit_subprogs() can fail, so err = -ENOTSUPP is necessary.

But if jit_subprogs() fails, then the err is propagated at the end of
the function (the 'return err' I mean).