Re: [PATCH bpf] bpf: tail calls do not modify packet data

["Teichmann, Martin" <martin.teichmann@xfel.eu>]

Dear Eduard,

> But really, I don't see that many options on the table:
> a. Be conservative and assume that every tail call modifies packed data.

That's actually what I want, be conservative. But that means that old programs should continue to run.

I have worked on this in the meantime and I think I found a solution for all cases, I will send it soon.

The origin of the problem is that tail calls just were not designed for ever returning. This way once we required the same scrutiny for the tail call as for the caller, the verifier could just stop at the tail call. Letting tail calls return is actually really weird, especially given that we also have constraints on the return values of a tail call, which are indeed verified in check_return_code. But why would we check that at all if that is not actually the end of the program, but we just return to the caller, which cannot do anything with that return value, or can it?

So if we go along this path, we would like to have new PROG_TYPEs for tail calls, which just check what is needed inside the tail call, but not the return value, as it returns to another program anyways. We would have types like BPF_PROG_TYPE_TAIL_CALL and BPF_PROC_TYPE_TAIL_CALL_PACKET_MODIFYING or so. Then we should start asking why it is a tail call at all, why can't we just call functions from maps, like we call global functions? Then we could even have proper calling conventions like r1 to r5 are parameters, r0 is return.

I do not advocate for any of this, I think this would be a lot of work for not much benefit. So for the time being, I will just try to make my old code work again, as it should. As said, I'll post a patch soon.

Greetings

Martin