netdev - Re: PCI VPD checksum ambiguity

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: <20250410162157.GA328195@bhelgaas>
Date: Thu, 10 Apr 2025 11:21:57 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Pavan Chebbi <pavan.chebbi@...adcom.com>,
	Michael Chan <mchan@...adcom.com>,
	Potnuri Bharat Teja <bharat@...lsio.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Leon Romanovsky <leon@...nel.org>
Cc: netdev@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: PCI VPD checksum ambiguity

On Tue, Apr 01, 2025 at 03:55:44PM -0500, Bjorn Helgaas wrote:
> Hi,
> 
> The PCIe spec is ambiguous about how the VPD checksum should be
> computed, and resolving this ambiguity might break drivers.

Any more input on this?  It would be great to have more information
about how vendors compute the checksum on their devices.

There is a proposed PCIe spec change to resolve the ambiguity, and the
intent is to make a change that reflects what vendors have actually
implemented.

The only concrete data I've seen so far is from Pavan at Broadcom
(thank you very much for that), where the checksum starts at the
beginning of VPD, not at the beginning of VPD-R.

If you can collect VPD data from devices, you can use something like
this to compute the checksum from the beginning of VPD:

  addr=0; sum=0; xxd -r -c 32 vpd.txt | xxd -p -g1 -c1 x.bin | while read X; do sum=$(($sum + "0x$X")); printf "addr 0x%04x: 0x%02x sum 0x%02x\n" $addr "0x$X" $(($sum % 256)); addr=$(($addr + 1)); done

(You still have to figure out manually where the RV item is so you
don't include the writable VPD-W part.)

> PCIe r6.0 sec 6.27 says only the VPD-R list should be included in the
> checksum:
> 
>   One VPD-R (10h) tag is used as a header for the read-only keywords.
>   The VPD-R list (including tag and length) must checksum to zero.
> 
> But sec 6.27.2.2 says "all bytes in VPD ... up to the checksum byte":
> 
>   RV   The first byte of this item is a checksum byte. The checksum is
>        correct if the sum of all bytes in VPD (from VPD address 0 up
>        to and including this byte) is zero.
> 
> These are obviously different unless VPD-R happens to be the first
> item in VPD.  But sec 6.27 and 6.27.2.1 suggest that the Identifier
> String item should be the first item, preceding the VPD-R list:
> 
>   The first VPD tag is the Identifier String (02h) and provides the
>   product name of the device. [6.27]
> 
>   Large resource type Identifier String (02h)
> 
>     This tag is the first item in the VPD storage component. It
>     contains the name of the add-in card in alphanumeric characters.
>     [6.27.2.1, Table 6-23]
> 
> I think pci_vpd_check_csum() follows sec 6.27.2.2: it sums all the
> bytes in the buffer up to and including the checksum byte of the RV
> keyword.  The range starts at 0, not at the beginning of the VPD-R
> read-only list, so it likely includes the Identifier String.
> 
> As far as I can tell, only the broadcom/tg3 and chelsio/cxgb4/t4
> drivers use pci_vpd_check_csum().  Of course, other drivers might
> compute the checksum themselves.
> 
> Any thoughts on how this spec ambiguity should be resolved?
> 
> Any idea how devices in the field populate their VPD?
> 
> Can you share any VPD dumps from devices that include an RV keyword
> item?
> 
> Bjorn