Hubble: fix traffic direction and is reply when IPSec is enabled

[kaworu]

Backport note: this patch won't apply cleanly on top of v1.13 which doesn't have the SRV6 encap/decap trace reasons, in v1.13 we only need the TraceReasonIsKnown() change in datapath_trace.go and the couple of TRACE_FROM_LXC test cases added in parser_test.go.

Before this patch, Hubble would wrongly report known traffic direction and reply status when IPSec was enabled.

The Cilium datapath uses trace_reason to convey both the trace reason and encryption status of trace notifications.The trace reason is decoded as-is in by userspace in the TraceNotify.Reason field, and users of the Reason field must carefully check the encrypt bit (see for example here or here). Unfortunately, TraceReasonIsKnown, TraceReasonIsEncap, and TraceReasonIsDecap didn't take the encrypt bit into account and thus returned wrong results when the encrypt bit was set.

One proper fix would be to refactor the monitor code to provide enough helpers for users so that they would not need to directly access the Reason field. This will be implemented in a separate PR in order to avoid backporting refactoring commits.

Related to #31202

[kaworu]

After closer inspection: while it's clear that in the datapath TRACE_REASON_ENCRYPTED is intended to be used as a mask (see also here), it is effectively always provided as-is (i.e. without additional trace reason), see for example

cilium/bpf/bpf_host.c

Lines 1093 to 1094 in 7e4ad4a

	send_trace_notify(ctx, TRACE_FROM_STACK, identity, 0, 0,
	ctx->ingress_ifindex, TRACE_REASON_ENCRYPTED, 0);

cc @learnitall to confirm this it's related to #29616 and the coccinelle script assumes no masking of TRACE_REASON_ENCRYPTED.

If correct and with the masking logic in mind, TRACE_REASON_ENCRYPTED is equivalent to TRACE_REASON_POLICY | TRACE_REASON_ENCRYPTED, and thus we never hit the bugs fixed by this patch as it would require either

• TRACE_REASON_UNKNOWN | TRACE_REASON_ENCRYPTED
• TRACE_REASON_SRV6_ENCAP | TRACE_REASON_ENCRYPTED
• TRACE_REASON_SRV6_DECAP | TRACE_REASON_ENCRYPTED

Consequently, while this patch fixes the monitor helper functions the behaviour should be unchanged by the patch. So I'm unsure whether it is correct to qualify the PR as either bug fix nor need backport. Since it doesn't fix any actual bug it could be misleading to report it as bug fix in the release notes, and while the backport should be very low risk IMHO it's not worth the effort (we could close this PR and the fix will land in main through #31226). cc @joestringer for guidance here 🙏

[joestringer]

If TRACE_REASON_ENCRYPTED is a property bit then I'd expect every trace message with that bit set to also contain the actual reason, at minimum with TRACE_REASON_UNKNOWN (which unfortunately has a non-zero value for historic reasons, so needs to be explicitly set). Though ideally we as developers should have an idea about why we're emitting the trace notification and allocate a reason for that purpose, otherwise we're apparently just emitting additional notifications for no reason, which is a waste of resources.

[joestringer]

Datapath logic here looks good. Not sure if we're going far enough on fixing up usage of the encrypted trace mask, but that doesn't have to be addressed here.

[kaworu]

/test

[kaworu]

/ci-ginkgo

[kaworu]

/ci-runtime

[kaworu]

/ci-ginkgo