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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55d91682-762e-411e-8abc-0790a9d81102@openvpn.net>
Date: Tue, 26 Nov 2024 09:17:22 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sergey Ryazanov <ryazanov.s.a@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, 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>,
 sd@...asysnail.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v11 05/23] ovpn: keep carrier always on

On 25/11/2024 22:32, Sergey Ryazanov wrote:
[...]
>> FTR, here is the text in the manpage:
>>
>>         --persist-tun
>>                Don't close and reopen TUN/TAP device or run up/down 
>> scripts across SIGUSR1 or --ping-restart restarts.
>>
>>                SIGUSR1 is a restart signal similar to SIGHUP, but 
>> which offers finer-grained control over reset options.
>>
>>
>> SIGUSR1 is a session reconnection, not a process restart.
>> The manpage just indicates what happens at the low level when this 
>> option is provided.
> 
> Still no mentions of the traffic leaking prevention. Is it?

Like I said, the manpage only mentions the low level bits.
I have already proposed a patch to further extend this text.

[...]
>> Having userspace configure a blackhole route is something that can be 
>> considered by whoeever decides to implement the "kill switch" feature.
>>
>> OpenVPN does not. It just implements --persist-tun.
>>
>> So all in all, the conclusion is that in this case it's usersapce to 
>> decide when the interface should go up and down, depending on the 
>> configuration. I'd like to keep it as it is to avoid the ovpn 
>> interface to make decisions on its own.
>>
>> I can spell this out in the comment (I think it definitely makes 
>> sense), to clarify that the netcarrier is expected to be driven by 
>> userspace (where the control plane is) rather than having the device 
>> make decisions without having the full picture.
>>
>> What do you think?
> 
> It wasn't suggested to destroy the interface in case of interface 
> becoming non-operational. I apologize if something I wrote earlier 
> sounded like that. The interface existence stays unquestionable. It's 
> going to be solid persistent.
> 
> Back to the proposed rephrasing. If the 'full picture' means forcing the 
> running state indication even when the netdev is not capable to deliver 
> packets, then it looks like an attempt to hide the control knob of the 
> misguiding feature somewhere else.
> 
> And since the concept of on-purpose false indication is still here, many 
> words regarding the control plane and a full picture do not sound good 
> either.

Can you please point out the code where other virtual drivers are doing 
what you are suggesting so I can have a look?

Wireguard is the closest module in terms of concept and I couldn't see 
anything like that. Neither in ipsec.
But I may have overlooked something.

Please let me know.

Regards,


-- 
Antonio Quartulli
OpenVPN Inc.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ