netdev - Re: [PATCH] xfrm: force flush upon NETDEV

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: <aXd3QjzwOVm0Q9LF@krikkit>
Date: Mon, 26 Jan 2026 15:16:34 +0100
From: Sabrina Dubroca <sd@...asysnail.net>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Steffen Klassert <steffen.klassert@...unet.com>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	Boris Pismenny <borisp@...lanox.com>,
	"David S. Miller" <davem@...emloft.net>,
	Florian Westphal <fw@...len.de>,
	Kristian Evensen <kristian.evensen@...il.com>,
	Leon Romanovsky <leon@...nel.org>,
	Leon Romanovsky <leonro@...dia.com>,
	Raed Salem <raeds@...lanox.com>, Raed Salem <raeds@...dia.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Yossi Kuperman <yossiku@...lanox.com>,
	Network Development <netdev@...r.kernel.org>,
	Aviad Yehezkel <aviadye@...dia.com>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH] xfrm: force flush upon NETDEV_UNREGISTER event

2026-01-22, 22:07:46 +0900, Tetsuo Handa wrote:
> On 2026/01/22 20:32, Steffen Klassert wrote:
> > On Thu, Jan 22, 2026 at 08:28:31PM +0900, Tetsuo Handa wrote:
> >> On 2026/01/22 20:15, Steffen Klassert wrote:
> >>> Hm, I'd say we should not try to offload to a device that does
> >>> not support NETIF_F_HW_ESP.
> >>
> >> I was about to post the patch below, but you are suggesting that "do not allow calling
> >> xfrm_dev_state_add()/xfrm_dev_policy_add() if (dev->features & NETIF_F_HW_ESP) == 0" ?
> > 
> > As said, I think this is the correct way to do it. But let's wait
> > on opinions from the hardware people.

But the current behavior ("ignore NETIF_F_HW_ESP and call
xdo_dev_state_add for new states anyway") has been established for
multiple years. Changing that now seems a bit risky.

> OK. I guess something like below.
> 
>  net/xfrm/xfrm_device.c |   10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
> index 52ae0e034d29..19aa61609d24 100644
> --- a/net/xfrm/xfrm_device.c
> +++ b/net/xfrm/xfrm_device.c
> @@ -292,6 +292,13 @@ int xfrm_dev_state_add(struct net *net, struct xfrm_state *x,
>  		dst_release(dst);
>  	}
>  
> +	if (!(dev->features & NETIF_F_HW_ESP)) {
> +		NL_SET_ERR_MSG(extack, "Device doesn't support offload");
> +		xso->dev = NULL;
> +		dev_put(dev);
> +		return -EINVAL;
> +	}

I'm not sure we want to make state creation fail in this case...

> +
>  	if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_state_add) {

while it will succeed (just without offload) in that case.

>  		xso->dev = NULL;
>  		dev_put(dev);
> @@ -367,7 +374,8 @@ int xfrm_dev_policy_add(struct net *net, struct xfrm_policy *xp,
>  	if (!dev)
>  		return -EINVAL;
>  
> -	if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_policy_add) {
> +	if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_policy_add ||
> +	    !(dev->features & NETIF_F_HW_ESP)) {
>  		xdo->dev = NULL;
>  		dev_put(dev);
>  		NL_SET_ERR_MSG(extack, "Policy offload is not supported");

-- 
Sabrina