netdev - Re: [PATCH iwl-next] ice: use DSN instead of PCI BDF for ice

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: <9727f77b-907a-49f6-b277-51387c499a6f@intel.com>
Date: Tue, 11 Mar 2025 11:14:13 +0100
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: "Temerkhanov, Sergey" <sergey.temerkhanov@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "Keller, Jacob E" <jacob.e.keller@...el.com>,
	"Jakub Kicinski" <kuba@...nel.org>, "Loktionov, Aleksandr"
	<aleksandr.loktionov@...el.com>, "Kolacinski, Karol"
	<karol.kolacinski@...el.com>, "Nitka, Grzegorz" <grzegorz.nitka@...el.com>,
	"Schmidt, Michal" <mschmidt@...hat.com>
Subject: Re: [PATCH iwl-next] ice: use DSN instead of PCI BDF for ice_adapter
 index

On 3/10/25 13:23, Jiri Pirko wrote:
> Mon, Mar 10, 2025 at 09:40:16AM +0100, przemyslaw.kitszel@...el.com wrote:
>>> Subject: Re: [PATCH iwl-next] ice: use DSN instead of PCI BDF for ice_adapter index
>>
>> regarding -net vs -next, no one have complained that this bug hurts
> 
> Wait, so we are now waiting for someone to hit the bug and complain,
> before we do fix? Does not make any sense to me.

no one is waiting for a fix, but it could affect users with weird NVM
images, so -next seems reasonable

> 
> 
>>
>>>> +	return (unsigned long)pci_get_dsn(pdev);
>>>
>>>> How do you ensure there is no xarray index collision then you cut the number like this?
>>
>> The reduction occurs only on "32b" systems, which are unlikely to have
>> this device. And any mixing of the upper and lower 4B part still could
>> collide.
> 
> Passtrough to 32 bit qemu machine? Even how unlikely is that, you are
> risking a user to hit a bug for newly introduced code without good
> reason. Why?

I will combine the two, by simple xor

> 
> 
>>
>>>
>>> It is also probably necessary to check if all devices supported by the driver have DSN capability enabled.
>>
>> I will double check on the SoC you have in mind.

IMO an NVM issue, will handle this offline