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: <816d8b43-8c19-4a4c-9e37-98a3415848b5@openvpn.net>
Date: Tue, 12 Nov 2024 16:44:09 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
 Shuah Khan <shuah@...nel.org>, ryazanov.s.a@...il.com,
 Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v11 20/23] ovpn: kill key and notify userspace in
 case of IV exhaustion

On 05/11/2024 11:33, Sabrina Dubroca wrote:
> 2024-10-29, 11:47:33 +0100, Antonio Quartulli wrote:
>> +int ovpn_nl_key_swap_notify(struct ovpn_peer *peer, u8 key_id)
>> +{
> [...]
>> +
>> +	nla_nest_end(msg, k_attr);
>> +	genlmsg_end(msg, hdr);
>> +
>> +	genlmsg_multicast_netns(&ovpn_nl_family, dev_net(peer->ovpn->dev), msg,
>> +				0, OVPN_NLGRP_PEERS, GFP_ATOMIC);
>> +
> 
> Is openvpn meant to support moving the device to a different netns? In
> that case I'm not sure the netns the ovpn netdevice is in is the right
> one, the userspace client will be in the encap socket's netns instead
> of the netdevice's?
> 
> (same thing in the next patch)

Well, moving between netns's may not be among the most common use cases, 
but I can see people doing all kind of weird things, if not forbidden.

Hence, I would not assume the netdevice to always stay in the same netns 
all time long.

This said, what you say assumes that the userspace process won't change 
netns after having added the peer.
I think we can live with that.

I will change this call to use the sock's netns then.

Thanks a lot!

Regards,

> 

-- 
Antonio Quartulli
OpenVPN Inc.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ