netdev - Re: [PATCH net-next,v3,2/2] i40e: support generic devlink param "max_mac_per

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] [day] [month] [year] [list]

Message-ID: <5dce7d9f-d5e9-4ea9-8a72-ed8e52d62e71@intel.com>
Date: Fri, 5 Sep 2025 16:29:33 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Simon Horman <horms@...nel.org>
CC: <mheib@...hat.com>, <intel-wired-lan@...ts.osuosl.org>,
	<przemyslawx.patynowski@...el.com>, <jiri@...nulli.us>,
	<netdev@...r.kernel.org>, <aleksandr.loktionov@...el.com>,
	<anthony.l.nguyen@...el.com>, <przemyslaw.kitszel@...el.com>
Subject: Re: [PATCH net-next,v3,2/2] i40e: support generic devlink param
 "max_mac_per_vf"



On 9/5/2025 4:46 AM, Simon Horman wrote:
> On Wed, Sep 03, 2025 at 03:25:40PM -0700, Jacob Keller wrote:
>> We didn't rate limit it before. I am not sure how fast the VF can
>> actually send messages, so I'm not sure if that change would be required.
>>
>> You could optionally also report the mac_add_max for the untrusted
>> message as well, but I think its fine to leave as-is in that case as well.
> 
> I'm not sure either. I'm more used to rate limits in the datapath,
> where network traffic can result in a log.
> 
> I think that if we want to go down the path you suggest then we should
> look at what other logs fall into the same category: generated by VM admin
> actions. And perhaps start by looking in the i40e driver for such cases.
> 
> Just my 2c worth on this one.
> 

I noticed that a VF can cause this message to be spammed indefinitely at
whatever rate the PF processes the virtchnl message, once its MAC cap is
hit. I don't think we really protect against that in any virtchnl
message, so that makes me think its likely not been considered a problem
thus far.


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)