[ upstream commit ebb4c47 ]

Policy map key can have nexthdr and destination port fields
wildcarded. Cilium datapath typically performs two policy map lookups,
one with the L3 identity mapped from the relevant IP address (destination
or source IP for egress or ingress policy, respectively). Datapath
chooses between the two policy entries based on two booleans in the
policy entry: 'wildcarded_protocol' and 'wildcarded_dport'. The problem
is that 'wildcarded_dport' is set only if the destination port is fully
wildcarded, so partially wildcarded port is considered as "not
wildcarded" for this logic.

Fix this for partially wildcarded ports by always choosing between
L4-only and L3 policy matches by the key prefix length so that the most
specific entry is always selected, selecting the entry with a precific
identity if the prefix lengths are the same. That is, choose the policy
with specific L3 if the prefixes are the same length, otherwise choose
the policy with the longer prefix.

LPM map key already contains the prefix length, but unfortunately LPM map
lookup does not return the map key. This is why we store an 8-bit version
of the prefix length in the policy map entry, which is as follows:

0: both nexthdr and destination port fully wildcarded
8: nexthdr specified but port fully wildcarded
24: both nexthdr and destination port specified (no wildcarding)

Values between 8 and 24 represent the less or more wildcarded destination port.

Previously used wildcarded_protocol and wildcarded_dport flags are removed as redundant.

Before this change the precedence between the following two rules:

1. <ID>/TCP/80/15 -- L3 <ID> specified, TCP port 80 partially wildcarded (ports 80-81)
2. */TCP/80/16 -- L3 wildcarded, TCP port 80 not wildcarded

would have resulted in selecting the policy with <ID> specified even when
it's destination port is partially wildcarded, while the L4-only rule has
no wildcarding in it's destination port.

If the entries above were allow (1) and deny (3), Cilium agent masked
this behavior by adding an additional deny entry in this case:

3. <ID>/TCP/80/16 -- L3 <ID> specified, TCP port 80 not wildcarded

This masks the incorrect behavior for allow/deny case, since the
non-wildcarded key (3) is given precedence by the datapath.

There is no such additional entry logic in the allow/allow case, so if
the more specific L4-only policy entry has L7 policy, and the less
specific L3 policy not, then matching traffic would not be sent to the L7
proxy for policy enforcement.

After this change the policy with less L4 wildcarding (the more specific
L4) is given precedence, with L3 rule being selected when prefixes are of
the same length. This allows for simplifying policy map computation by
avoiding the need to add additional entries in cases where deny already
has the longer prefix length.

This change makes no difference for keys which only have the destination
port fully specified or fully wildcarded, so this only affects policies
with port ranges as enabled in Cilium 1.16.

Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>

[ upstream commit 60bc8fa ]

Move the prefix length field in the policy map value to the flags (same
byte as 'deny') to a previously unused space. This cleans up padding
space for future use.

Skip map entries with inconsistent prefix length field in value vs. key
so that the entry will be rewritten with the correct prefix length field
in the value. This fixes a potential issue in upgrade where a policy map
entry may remain with zero valued prefix length in value leading to
incorrect policy enforcement.

Fixes: cilium#35150

Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>