Re: [PATCH net-next v24 09/23] ovpn: implement packet processing

[Antonio Quartulli]

On 24/03/2025 12:02, Sabrina Dubroca wrote:
> 2025-03-18, 02:40:44 +0100, Antonio Quartulli wrote:
> > +int ovpn_crypto_state_reset(struct ovpn_crypto_state *cs,
> > +			    const struct ovpn_peer_key_reset *pkr)
> > +{
> > +	struct ovpn_crypto_key_slot *old = NULL, *new;
> > +	u8 idx;
> > +
> > +	if (pkr->slot != OVPN_KEY_SLOT_PRIMARY &&
> > +	    pkr->slot != OVPN_KEY_SLOT_SECONDARY)
> > +		return -EINVAL;
> > +
> > +	new = ovpn_aead_crypto_key_slot_new(&pkr->key);
> > +	if (IS_ERR(new))
> > +		return PTR_ERR(new);
> > +
> > +	spin_lock_bh(&cs->lock);
>
> At this point, should there be a check that we're not installing 2
> keys with the same key_id at the same time? I expect a well-behaved
> userspace never does that, but it would confuse
> ovpn_crypto_key_id_to_slot if it ever happened.
>
> ["well, then the tunnel is broken. if userspace sets up a broken
> config that's not the kernel's problem." is an acceptable answer]

The behaviour of ovpn_crypto_key_id_to_slot() is still "deterministic" 
as we will first lookup the primary key.

Therefore we will simply always use the primary key and never the other, 
which is what we should expect in this situation from the code.

I'd say this is just an ill-formed configuration, yet not invalid.
As per your statement, I'd say it's userspace's problem.

Cheers,


--
Antonio Quartulli
OpenVPN Inc.