On Tue, Sep 15, 2020 at 8:03 AM Daniel Borkmann <[email protected]> wrote: > > On 9/15/20 6:39 AM, Alexei Starovoitov wrote: > > On Fri, Sep 11, 2020 at 08:59:27PM +0200, Maciej Fijalkowski wrote: > >> On Thu, Sep 03, 2020 at 12:51:14PM -0700, Alexei Starovoitov wrote: > >>> On Wed, Sep 02, 2020 at 10:08:15PM +0200, Maciej Fijalkowski wrote: > [...] > >>> Could you add few more tests to exercise the new feature more thoroughly? > >>> Something like tailcall3.c that checks 32 limit, but doing tail_call from > >>> subprog. > >>> And another test that consume non-trival amount of stack in each function. > >>> Adding 'volatile char arr[128] = {};' would do the trick. > >> > >> Yet another prolonged silence from my side, but not without a reason - > >> this request opened up a Pandora's box. > > > > Great catch and thanks to our development practices! As a community we > > should > > remember this lesson and request selftests more often than not. > > +1, speaking of pandora ... ;-) I recently noticed that we also have the > legacy > ld_abs/ld_ind instructions. Right now check_ld_abs() gates them by bailing out > if env->subprog_cnt > 1, but that doesn't solve everything given the prog > itself > may not have bpf2bpf calls, but it could get tail-called out of a subprog. We > need to reject such cases (& add selftests for it), otherwise this would be a > verifier bypass given they may implicitly exit the program (and then mismatch > the return type that the verifier was expecting).
Good point. I think it's easier to allow ld_abs though. The comment in check_ld_abs() is obsolete after gen_ld_abs() was added. The verifier needs to check that subprog that is doing ld_abs or tail_call has 'int' return type and check_reference_leak() doesn't error before ld_abs and before bpf_tail_call. In that sense doing bpf_tail_call from subprog has the same issues as ld_abs (reference leaks and int return requirement)
