netdev - Re: [PATCH net-next v3 0/8] devlink: Add port function attributes

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: <20230818041959.GX22185@unreal>
Date: Fri, 18 Aug 2023 07:19:59 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Dima Chumak <dchumak@...dia.com>, Jiri Pirko <jiri@...nulli.us>,
	Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
	netdev@...r.kernel.org, Saeed Mahameed <saeedm@...dia.com>,
	Steffen Klassert <steffen.klassert@...unet.com>,
	Simon Horman <simon.horman@...igine.com>
Subject: Re: [PATCH net-next v3 0/8] devlink: Add port function attributes

On Thu, Aug 17, 2023 at 08:07:25PM -0700, Jakub Kicinski wrote:
> On Thu, 17 Aug 2023 12:11:22 +0300 Leon Romanovsky wrote:
> > Introduce hypervisor-level control knobs to set the functionality of PCI
> > VF devices passed through to guests. The administrator of a hypervisor
> > host may choose to change the settings of a port function from the
> > defaults configured by the device firmware.
> > 
> > The software stack has two types of IPsec offload - crypto and packet.
> > Specifically, the ip xfrm command has sub-commands for "state" and
> > "policy" that have an "offload" parameter. With ip xfrm state, both
> > crypto and packet offload types are supported, while ip xfrm policy can
> > only be offloaded in packet mode.
> > 
> > The series introduces two new boolean attributes of a port function:
> > ipsec_crypto and ipsec_packet. The goal is to provide a similar level of
> > granularity for controlling VF IPsec offload capabilities, which would
> > be aligned with the software model. This will allow users to decide if
> > they want both types of offload enabled for a VF, just one of them, or
> > none at all (which is the default).
> > 
> > At a high level, the difference between the two knobs is that with
> > ipsec_crypto, only XFRM state can be offloaded. Specifically, only the
> > crypto operation (Encrypt/Decrypt) is offloaded. With ipsec_packet, both
> > XFRM state and policy can be offloaded. Furthermore, in addition to
> > crypto operation offload, IPsec encapsulation is also offloaded. For
> > XFRM state, choosing between crypto and packet offload types is
> > possible. From the HW perspective, different resources may be required
> > for each offload type.
> 
> What's going on with all the outstanding nVidia patches?!
> The expectation is 1 series per vendor / driver. Let's say
> 2 if there are core changes. You had 5 outstanding today.

I sent only three security related series, two of three were already reviewed
and waiting to be applied [1,2]. This third series is only one which touches core.

It is very strange to expect 1 series per vendor/driver without taking
into account the size of that driver and the amount of upstream work
involvement from that vendor.

Thanks

[1] https://patchwork.kernel.org/project/netdevbpf/list/?series=774239&state=*
[2] https://patchwork.kernel.org/project/netdevbpf/list/?series=775702

> 
> I'm tossing this out.
> -- 
> pw-bot: defer