netdev - Re: [PATCH net-next v3 15/24] ovpn: implement peer lookup logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zlda5GcgKd9Y9O_o@hog>
Date: Wed, 29 May 2024 18:42:12 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Antonio Quartulli <antonio@...nvpn.net>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
	Sergey Ryazanov <ryazanov.s.a@...il.com>,
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
	Andrew Lunn <andrew@...n.ch>, Esben Haabendal <esben@...nix.com>
Subject: Re: [PATCH net-next v3 15/24] ovpn: implement peer lookup logic

2024-05-28, 22:09:37 +0200, Antonio Quartulli wrote:
> On 28/05/2024 18:42, Sabrina Dubroca wrote:
> > 2024-05-06, 03:16:28 +0200, Antonio Quartulli wrote:
> > > @@ -303,10 +427,28 @@ static struct ovpn_peer *ovpn_peer_get_by_id_p2p(struct ovpn_struct *ovpn,
> > >   struct ovpn_peer *ovpn_peer_get_by_id(struct ovpn_struct *ovpn, u32 peer_id)
> > >   {
> > > -	struct ovpn_peer *peer = NULL;
> > > +	struct ovpn_peer *tmp, *peer = NULL;
> > > +	struct hlist_head *head;
> > > +	u32 index;
> > >   	if (ovpn->mode == OVPN_MODE_P2P)
> > > -		peer = ovpn_peer_get_by_id_p2p(ovpn, peer_id);
> > > +		return ovpn_peer_get_by_id_p2p(ovpn, peer_id);
> > > +
> > > +	index = ovpn_peer_index(ovpn->peers.by_id, &peer_id, sizeof(peer_id));
> > > +	head = &ovpn->peers.by_id[index];
> > > +
> > > +	rcu_read_lock();
> > > +	hlist_for_each_entry_rcu(tmp, head, hash_entry_id) {
> > > +		if (tmp->id != peer_id)
> > > +			continue;
> > > +
> > > +		if (!ovpn_peer_hold(tmp))
> > > +			continue;
> > 
> > Can there ever be multiple peers with the same id? (ie, is it worth
> > continuing the loop if this fails? the same question probably applies
> > to ovpn_peer_get_by_transp_addr as well)
> 
> Well, not at the same time, but theoretically we could re-use the ID of a
> peer that is being released (i.e. still in the list but refcnt at 0) because
> it won't be returned by this lookup.
> 
> This said, I truly believe it's impossible for a peer to have refcnt 0 and
> still being in the list:
> Either
> * delete on the peer was not yet called, thus peer is in the list and the
> last reference wasn't yet dropped
> * delete on the peer was called, thus peer cannot be in the list anymore and
> refcnt may or may not be 0...

Ok, thanks. Let's just keep this code.


> > > +/**
> > > + * ovpn_nexthop_from_rt6 - look up the IPv6 nexthop for the given destination
> > 
> > I'm a bit confused by this talk about "destination" when those two
> > functions are then used with the source address from the packet, from
> > a function called "get_by_src".
> 
> well, in my brain a next hop can exists only when I want to reach a certain
> destination. Therefore, at a low level, the terms nextop and destination
> always need to go hand in hand.
> 
> This said, when implementing RPF (Reverse Path Filtering) I need to imagine
> that I want to route to the source IP of the incoming packet. If the nexthop
> I looked up matches the peer the packet came from, then everything is fine.
> 
> makes sense?

Yeah, that's fair.

> 
> [FTR I have already renamed/changed get_by_src into check_by_src, because I
> don't need to truly extract a peer and get a reference, but I only need to
> perform the aforementioned comparison.]

Ok.

> > > + * @ovpn: the private data representing the current VPN session
> > > + * @dst: the destination to be looked up
> > > + *
> > > + * Looks up in the IPv6 system routing table the IO of the nexthop to be used
> > 
> > "the IO"?
> 
> typ0: "the IP"
> 
> > 
> > > + * to reach the destination passed as argument. IF no nexthop can be found, the
> > > + * destination itself is returned as it probably has to be used as nexthop.
> > > + *
> > > + * Return: the IP of the next hop if found or the dst itself otherwise
> > 
> > "the dst" tends to refer to a dst_entry, maybe "or @dst otherwise"?
> 
> it refers to @dst (the function argument). That's basically the case where
> the destination is "onlink" and thus it is the nexthop (basically the
> destination is the connected peer).

I understand that, it's just the wording "the dst" that I'm
nitpicking. s/dst/addr/ would help easily-confused people like me (for
both "the dst" and my confusion with source vs destination in
caller/callee), but I can live with this.

-- 
Sabrina