netdev - Re: [PATCH net-next 0/4] devlink: Add port function attributes to enable/disable IPsec crypto and packet offloads

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]

Date:   Wed, 29 Mar 2023 09:42:51 +0200
From:   Dima Chumak <dchumak@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>,
        Leon Romanovsky <leon@...nel.org>,
        Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/4] devlink: Add port function attributes to
 enable/disable IPsec crypto and packet offloads

On 3/23/23 6:23 PM, Jakub Kicinski wrote:
> On Thu, 23 Mar 2023 13:10:55 +0200 Dima Chumak wrote:
>> Currently, mlx5 PCI VFs are disabled by default for IPsec functionality.
>> A user does not have the ability to enable IPsec support for a PCI VF
>> device.
>>
>> It is desirable to provide a user with a fine grained control of the PCI
>> VF device IPsec capabilities.
> 
> Is it fine grained? How many keys can each VF allocate?

When I referred to "fine grained" control, I was talking about the
different types of IPsec offload (crypto and packet offload) in the
software stack. 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 goal is to provide a similar level of granularity for controlling VF
IPsec offload capabilities, which would be consistent 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).

>> The above are a hypervisor level control, to set the functionality of
>> devices passed through to guests.
>>
>> This is achieved by extending existing 'port function' object to control
>> capabilities of a function. It enables users to control capability of
>> the device before enumeration.
>>
>> The series introduces two new boolean attributes of port function:
>> ipsec_crypto and ipsec_packet. They can be controlled independently.
>> Each to provide a distinct level of IPsec offload support that may
>> require different system and/or device firmware resources.
> 
> On a quick read I have no idea what the difference between the two
> knobs is :S

At a high level, the difference 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 also IPsec encapsulation is offloaded. For XFRM state, it's
possible to choose between crypto and packet offload types. From HW
perspective different resources may be required for each type of
offload, and this gives more options for HW resource allocation.