[PATCH] pci: Update VPD size with correct length

[PATCH] pci: Update VPD size with correct length

[Hannes Reinecke]

PCI-2.2 VPD entries have a maximum size of 32k, but might actually
be smaller than that. To figure out the actual size one has to read
the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting'
effects, from simple read errors to crashing the card. And to make
matters worse not every PCI card implements this properly, leaving
us with no 'end' marker or even completely invalid data.
This path modifies the size of the VPD attribute to the available
size, and disables the VPD attribute altogether if no valid data
could be read.

Cc: Alexander Duyck <alexander.h.duyck@redhat.com>
Cc: Michal Kubecek <mkubecek@suse.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/pci/access.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 59ac36f..afa86d6 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -475,6 +475,48 @@ static const struct pci_vpd_ops pci_vpd_f0_ops = {
 	.release = pci_vpd_pci22_release,
 };
 
+/**
+ * pci_vpd_size - determine actual size of Vital Product Data
+ * @dev:	pci device struct
+ * @old_size:	current assumed size, also maximum allowed size
+ *
+ */
+static size_t
+pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
+{
+	size_t off = 0;
+	unsigned char header[1+2];	/* 1 byte tag, 2 bytes length */
+
+	while (off < old_size && pci_read_vpd(dev, off, 1, header)) {
+		unsigned char tag;
+
+		if (header[0] == 0xff) {
+			/* Invalid data from VPD read */
+			tag = header[0];
+		} else if (header[0] & 0x80) {
+			/* Large Resource Data Type Tag */
+			if (pci_read_vpd(dev, off+1, 2, &header[1]) != 2)
+				return off + 1;
+			off += 3 + ((header[2] << 8) | header[1]);
+			tag = (header[0] & 0x7f);
+		} else {
+			/* Short Resource Data Type Tag */
+			off += 1 + (header[0] & 0x07);
+			tag = (header[0] & 0x78) >> 3;
+		}
+		if (tag == 0x0f)	/* End tag descriptor */
+			break;
+		if ((tag != 0x02) && (tag != 0x10) && (tag != 0x11)) {
+			dev_debug(&dev->dev,
+				   "invalid %s vpd tag %02x at offset %zu.",
+				   header[0] & 0x80 ? "large" : "short",
+				   tag, off);
+			break;
+		}
+	}
+	return off;
+}
+
 int pci_vpd_pci22_init(struct pci_dev *dev)
 {
 	struct pci_vpd_pci22 *vpd;
@@ -497,6 +539,13 @@ int pci_vpd_pci22_init(struct pci_dev *dev)
 	vpd->cap = cap;
 	vpd->busy = false;
 	dev->vpd = &vpd->base;
+	vpd->base.len = pci_vpd_pci22_size(dev, vpd->base.len);
+	if (vpd->base.len == 0) {
+		dev_debug(&dev->dev, "Disabling VPD access.");
+		dev->vpd = NULL;
+		kfree(vpd);
+		return -ENXIO;
+	}
 	return 0;
 }
 
-- 
1.8.5.6

Re: [PATCH] pci: Update VPD size with correct length

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Hi Hannes,

[auto build test ERROR on pci/next]
[also build test ERROR on v4.4-rc5 next-20151216]

url:    https://github.com/0day-ci/linux/commits/Hannes-Reinecke/pci-Update-VPD-size-with-correct-length/20151216-183013
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-x011-12141150 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/pci/access.c: In function 'pci_vpd_pci22_size':
>> drivers/pci/access.c:510:4: error: implicit declaration of function 'dev_debug' [-Werror=implicit-function-declaration]
       dev_debug(&dev->dev,
       ^
   cc1: some warnings being treated as errors

vim +/dev_debug +510 drivers/pci/access.c

   504				off += 1 + (header[0] & 0x07);
   505				tag = (header[0] & 0x78) >> 3;
   506			}
   507			if (tag == 0x0f)	/* End tag descriptor */
   508				break;
   509			if ((tag != 0x02) && (tag != 0x10) && (tag != 0x11)) {
 > 510				dev_debug(&dev->dev,
   511					   "invalid %s vpd tag %02x at offset %zu.",
   512					   header[0] & 0x80 ? "large" : "short",
   513					   tag, off);

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 21212 bytes --]

[PATCH] pci: Update VPD size with correct length

[Hannes Reinecke]

PCI-2.2 VPD entries have a maximum size of 32k, but might actually
be smaller than that. To figure out the actual size one has to read
the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting'
effects, from simple read errors to crashing the card.
This path modifies the attribute size to the avialable VPD size.

Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/pci/access.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 6bc9b12..4f8208e 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)
 	return ret;
 }
 
+/**
+ * pci_vpd_size - determine actual size of Vital Product Data
+ * @dev:	pci device struct
+ * @old_size:	current assumed size, also maximum allowed size
+ *
+ */
+size_t
+pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
+{
+	loff_t off = 0;
+	unsigned char header[1+2];	/* 1 byte tag, 2 bytes length */
+
+	while (off < old_size && pci_read_vpd(dev, off, 1, header)) {
+		if (header[0] == 0x78)	/* End tag descriptor */
+			return off + 1;
+		if (header[0] & 0x80) {
+			/* Large Resource Data Type Tag */
+			if (pci_read_vpd(dev, off+1, 2, &header[1]) != 2)
+				return off + 1;
+			off += 3 + ((header[2] << 8) | header[1]);
+		} else {
+			/* Short Resource Data Type Tag */
+			off += 1 + (header[0] & 0x07);
+		}
+	}
+	return old_size;
+}
+
 int pci_vpd_pci22_init(struct pci_dev *dev)
 {
 	struct pci_vpd_pci22 *vpd;
@@ -436,6 +464,7 @@ int pci_vpd_pci22_init(struct pci_dev *dev)
 	vpd->cap = cap;
 	vpd->busy = false;
 	dev->vpd = &vpd->base;
+	vpd->base.len = pci_vpd_pci22_size(dev, vpd->base.len);
 	return 0;
 }
 
-- 
1.8.5.6

Re: [PATCH] pci: Update VPD size with correct length

[kbuild test robot]

Hi Hannes,

[auto build test WARNING on pci/next -- if it's inappropriate base, please suggest rules for selecting the more suitable base]

url:    https://github.com/0day-ci/linux/commits/Hannes-Reinecke/pci-Update-VPD-size-with-correct-length/20151023-171224
reproduce:
        # apt-get install sparse
        make ARCH=x86_64 allmodconfig
        make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/pci/access.c:499:1: sparse: symbol 'pci_vpd_pci22_size' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

Re: [PATCH] pci: Update VPD size with correct length

[Alexander Duyck]

On 10/23/2015 02:09 AM, Hannes Reinecke wrote:
> PCI-2.2 VPD entries have a maximum size of 32k, but might actually
> be smaller than that. To figure out the actual size one has to read
> the VPD area until the 'end marker' is reached.
> Trying to read VPD data beyond that marker results in 'interesting'
> effects, from simple read errors to crashing the card.
> This path modifies the attribute size to the avialable VPD size.
>
> Signed-off-by: Hannes Reinecke <hare@suse.de>
> ---
>   drivers/pci/access.c | 29 +++++++++++++++++++++++++++++
>   1 file changed, 29 insertions(+)
>
> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> index 6bc9b12..4f8208e 100644
> --- a/drivers/pci/access.c
> +++ b/drivers/pci/access.c
> @@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)
>   	return ret;
>   }
>
> +/**
> + * pci_vpd_size - determine actual size of Vital Product Data
> + * @dev:	pci device struct
> + * @old_size:	current assumed size, also maximum allowed size
> + *
> + */
> +size_t
> +pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
> +{
> +	loff_t off = 0;
> +	unsigned char header[1+2];	/* 1 byte tag, 2 bytes length */
> +
> +	while (off < old_size && pci_read_vpd(dev, off, 1, header)) {
> +		if (header[0] == 0x78)	/* End tag descriptor */
> +			return off + 1;
> +		if (header[0] & 0x80) {
> +			/* Large Resource Data Type Tag */
> +			if (pci_read_vpd(dev, off+1, 2, &header[1]) != 2)
> +				return off + 1;
> +			off += 3 + ((header[2] << 8) | header[1]);
> +		} else {
> +			/* Short Resource Data Type Tag */
> +			off += 1 + (header[0] & 0x07);
> +		}
> +	}
> +	return old_size;
> +}
> +

My understanding is that the end tag can have some data associated with 
it such as a checksum.  What you may want to look at doing is process 
long tag and short tag bits first.  Then you could do a mask and compare 
after and if ((header[0] & ~0x7) == 0x78) then you return off + 1.

Also I was wondering if you have looked at the cxgb4 network driver? 
They are using the vpd read/write calls to access their EEPROM and I 
assume they are doing so outside the actual VPD fields.

- Alex

Re: [PATCH] pci: Update VPD size with correct length

[Hannes Reinecke]

On 10/24/2015 02:52 AM, Alexander Duyck wrote:
> On 10/23/2015 02:09 AM, Hannes Reinecke wrote:
>> PCI-2.2 VPD entries have a maximum size of 32k, but might actually
>> be smaller than that. To figure out the actual size one has to read
>> the VPD area until the 'end marker' is reached.
>> Trying to read VPD data beyond that marker results in 'interesting'
>> effects, from simple read errors to crashing the card.
>> This path modifies the attribute size to the avialable VPD size.
>>
>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>> ---
>>   drivers/pci/access.c | 29 +++++++++++++++++++++++++++++
>>   1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
>> index 6bc9b12..4f8208e 100644
>> --- a/drivers/pci/access.c
>> +++ b/drivers/pci/access.c
>> @@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)
>>       return ret;
>>   }
>>
>> +/**
>> + * pci_vpd_size - determine actual size of Vital Product Data
>> + * @dev:    pci device struct
>> + * @old_size:    current assumed size, also maximum allowed size
>> + *
>> + */
>> +size_t
>> +pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
>> +{
>> +    loff_t off = 0;
>> +    unsigned char header[1+2];    /* 1 byte tag, 2 bytes length */
>> +
>> +    while (off < old_size && pci_read_vpd(dev, off, 1, header)) {
>> +        if (header[0] == 0x78)    /* End tag descriptor */
>> +            return off + 1;
>> +        if (header[0] & 0x80) {
>> +            /* Large Resource Data Type Tag */
>> +            if (pci_read_vpd(dev, off+1, 2, &header[1]) != 2)
>> +                return off + 1;
>> +            off += 3 + ((header[2] << 8) | header[1]);
>> +        } else {
>> +            /* Short Resource Data Type Tag */
>> +            off += 1 + (header[0] & 0x07);
>> +        }
>> +    }
>> +    return old_size;
>> +}
>> +
> 
> My understanding is that the end tag can have some data associated with
> it such as a checksum.  What you may want to look at doing is process
> long tag and short tag bits first.  Then you could do a mask and compare
> after and if ((header[0] & ~0x7) == 0x78) then you return off + 1.
> 
Ah. Oh. Hmm. Wasn't aware of that one.
Bjorn?

> Also I was wondering if you have looked at the cxgb4 network driver?
> They are using the vpd read/write calls to access their EEPROM and I
> assume they are doing so outside the actual VPD fields.
> 
As indicated; VPD page access is basically directly wired to the device.
So if the vendor chooses to do some extra magic there by all means let
him do so. This patch is meant for cards/vendors which (try) to adhere
to the PCI VPD specification, so our access to that should be
conformant, too.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: [PATCH] pci: Update VPD size with correct length

[Bjorn Helgaas]

Hi Hannes,

On Sun, Oct 25, 2015 at 04:34:34AM +0100, Hannes Reinecke wrote:
> On 10/24/2015 02:52 AM, Alexander Duyck wrote:
> > On 10/23/2015 02:09 AM, Hannes Reinecke wrote:
> >> PCI-2.2 VPD entries have a maximum size of 32k, but might actually
> >> be smaller than that. To figure out the actual size one has to read
> >> the VPD area until the 'end marker' is reached.
> >> Trying to read VPD data beyond that marker results in 'interesting'
> >> effects, from simple read errors to crashing the card.
> >> This path modifies the attribute size to the avialable VPD size.
> >>
> >> Signed-off-by: Hannes Reinecke <hare@suse.de>
> >> ---
> >>   drivers/pci/access.c | 29 +++++++++++++++++++++++++++++
> >>   1 file changed, 29 insertions(+)
> >>
> >> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> >> index 6bc9b12..4f8208e 100644
> >> --- a/drivers/pci/access.c
> >> +++ b/drivers/pci/access.c
> >> @@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)
> >>       return ret;
> >>   }
> >>
> >> +/**
> >> + * pci_vpd_size - determine actual size of Vital Product Data
> >> + * @dev:    pci device struct
> >> + * @old_size:    current assumed size, also maximum allowed size
> >> + *
> >> + */
> >> +size_t
> >> +pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
> >> +{
> >> +    loff_t off = 0;
> >> +    unsigned char header[1+2];    /* 1 byte tag, 2 bytes length */
> >> +
> >> +    while (off < old_size && pci_read_vpd(dev, off, 1, header)) {
> >> +        if (header[0] == 0x78)    /* End tag descriptor */
> >> +            return off + 1;
> >> +        if (header[0] & 0x80) {
> >> +            /* Large Resource Data Type Tag */
> >> +            if (pci_read_vpd(dev, off+1, 2, &header[1]) != 2)
> >> +                return off + 1;
> >> +            off += 3 + ((header[2] << 8) | header[1]);
> >> +        } else {
> >> +            /* Short Resource Data Type Tag */
> >> +            off += 1 + (header[0] & 0x07);
> >> +        }
> >> +    }
> >> +    return old_size;
> >> +}
> >> +
> > 
> > My understanding is that the end tag can have some data associated with
> > it such as a checksum.  What you may want to look at doing is process
> > long tag and short tag bits first.  Then you could do a mask and compare
> > after and if ((header[0] & ~0x7) == 0x78) then you return off + 1.
> > 
> Ah. Oh. Hmm. Wasn't aware of that one.
> Bjorn?

I don't know.  I took a very quick glance at the PCI 3.0 spec and I
didn't see the description of data associated with an End Tag.  It'd
be nice to have a spec reference for whatever we implement here.

It sounds like this fixes some real problems, and it'd also be nice to
have more specifics about them, e.g., what devices, how to reproduce,
etc.

Bjorn

Re: [PATCH] pci: Update VPD size with correct length

[Alexander Duyck]

On 11/25/2015 09:17 AM, Bjorn Helgaas wrote:
> Hi Hannes,
>
> On Sun, Oct 25, 2015 at 04:34:34AM +0100, Hannes Reinecke wrote:
>> On 10/24/2015 02:52 AM, Alexander Duyck wrote:
>>> On 10/23/2015 02:09 AM, Hannes Reinecke wrote:
>>>> PCI-2.2 VPD entries have a maximum size of 32k, but might actually
>>>> be smaller than that. To figure out the actual size one has to read
>>>> the VPD area until the 'end marker' is reached.
>>>> Trying to read VPD data beyond that marker results in 'interesting'
>>>> effects, from simple read errors to crashing the card.
>>>> This path modifies the attribute size to the avialable VPD size.
>>>>
>>>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>>>> ---
>>>>    drivers/pci/access.c | 29 +++++++++++++++++++++++++++++
>>>>    1 file changed, 29 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
>>>> index 6bc9b12..4f8208e 100644
>>>> --- a/drivers/pci/access.c
>>>> +++ b/drivers/pci/access.c
>>>> @@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)
>>>>        return ret;
>>>>    }
>>>>
>>>> +/**
>>>> + * pci_vpd_size - determine actual size of Vital Product Data
>>>> + * @dev:    pci device struct
>>>> + * @old_size:    current assumed size, also maximum allowed size
>>>> + *
>>>> + */
>>>> +size_t
>>>> +pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
>>>> +{
>>>> +    loff_t off = 0;
>>>> +    unsigned char header[1+2];    /* 1 byte tag, 2 bytes length */
>>>> +
>>>> +    while (off < old_size && pci_read_vpd(dev, off, 1, header)) {
>>>> +        if (header[0] == 0x78)    /* End tag descriptor */
>>>> +            return off + 1;
>>>> +        if (header[0] & 0x80) {
>>>> +            /* Large Resource Data Type Tag */
>>>> +            if (pci_read_vpd(dev, off+1, 2, &header[1]) != 2)
>>>> +                return off + 1;
>>>> +            off += 3 + ((header[2] << 8) | header[1]);
>>>> +        } else {
>>>> +            /* Short Resource Data Type Tag */
>>>> +            off += 1 + (header[0] & 0x07);
>>>> +        }
>>>> +    }
>>>> +    return old_size;
>>>> +}
>>>> +
>>>
>>> My understanding is that the end tag can have some data associated with
>>> it such as a checksum.  What you may want to look at doing is process
>>> long tag and short tag bits first.  Then you could do a mask and compare
>>> after and if ((header[0] & ~0x7) == 0x78) then you return off + 1.
>>>
>> Ah. Oh. Hmm. Wasn't aware of that one.
>> Bjorn?
>
> I don't know.  I took a very quick glance at the PCI 3.0 spec and I
> didn't see the description of data associated with an End Tag.  It'd
> be nice to have a spec reference for whatever we implement here.

I had originally based my suggestion to include length off an example I 
saw in the third edition of "PCI System Architecture".  However it 
didn't explain things very well so I did some digging.

The end tag was defined in the Plug and Play ISA Specification, Version 
1.0a, section 6.2.2.11.  There the end tag  supported 1 byte of data for 
a checksum.  I believe the PCI 3.0 spec calls this out as the reference 
for the small tags and as such we probably should support it.

It is highly likely that there may be implementations that followed the 
above example and have end tags that may have an additional byte 
dangling off of them for the checksum.  So I would say it is worth it to 
cover at least that case.

- Alex