Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Hannes Reinecke <hare@suse.de>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 4/5] PCI/VPD: Don't check Large Resource types for validity
Date: Wed, 28 Jul 2021 18:46:13 -0500	[thread overview]
Message-ID: <20210728234613.GA871409@bjorn-Precision-5520> (raw)
In-Reply-To: <1b0fd08b-4603-d7af-b936-95a3e451ee0c@suse.de>

On Fri, Jul 16, 2021 at 08:03:45AM +0200, Hannes Reinecke wrote:
> On 7/15/21 11:59 PM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas <bhelgaas@google.com>
> > 
> > VPD consists of a series of Small and Large Resources.  Computing the size
> > of VPD requires only the length of each, which is specified in the generic
> > tag of each resource.  We only expect to see ID_STRING, RO_DATA, and
> > RW_DATA in VPD, but it's not a problem if it contains other resource types.
> > 
> > Drop the validity checking of Large Resource items.
> > 
> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > ---
> >   drivers/pci/vpd.c | 37 ++++++++++++++-----------------------
> >   1 file changed, 14 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> > index 9c2744d79b53..d7a4a9f05bd6 100644
> > --- a/drivers/pci/vpd.c
> > +++ b/drivers/pci/vpd.c
> > @@ -82,31 +82,22 @@ static size_t pci_vpd_size(struct pci_dev *dev, size_t old_size)
> >   		if (header[0] & PCI_VPD_LRDT) {
> >   			/* Large Resource Data Type Tag */
> >   			tag = pci_vpd_lrdt_tag(header);
> > -			/* Only read length from known tag items */
> > -			if ((tag == PCI_VPD_LTIN_ID_STRING) ||
> > -			    (tag == PCI_VPD_LTIN_RO_DATA) ||
> > -			    (tag == PCI_VPD_LTIN_RW_DATA)) {
> > -				if (pci_read_vpd(dev, off+1, 2,
> > -						 &header[1]) != 2) {
> > -					pci_warn(dev, "failed VPD read at offset %zu",
> > -						 off + 1);
> > -					return 0;
> > -				}
> > -				size = pci_vpd_lrdt_size(header);
> > -
> > -				/*
> > -				 * Missing EEPROM may read as 0xff.
> > -				 * Length of 0xffff (65535) cannot be valid
> > -				 * because VPD can't be that large.
> > -				 */
> > -				if (size > PCI_VPD_MAX_SIZE)
> > -					goto error;
> > -				off += PCI_VPD_LRDT_TAG_SIZE + size;
> > -			} else {
> > -				pci_warn(dev, "invalid large VPD tag %02x at offset %zu",
> > -					 tag, off);
> > +			if (pci_read_vpd(dev, off + 1, 2, &header[1]) != 2) {
> > +				pci_warn(dev, "failed VPD read at offset %zu",
> > +					 off + 1);
> >   				return 0;
> >   			}
> > +			size = pci_vpd_lrdt_size(header);
> > +
> > +			/*
> > +			 * Missing EEPROM may read as 0xff.  Length of
> > +			 * 0xffff (65535) cannot be valid because VPD can't
> > +			 * be that large.
> > +			 */
> > +			if (size > PCI_VPD_MAX_SIZE)
> > +				goto error;
> > +
> > +			off += PCI_VPD_LRDT_TAG_SIZE + size;
> >   		} else {
> >   			/* Short Resource Data Type Tag */
> >   			tag = pci_vpd_srdt_tag(header);
> > 
> I'm not entirely happy with this; we really have to rely on well-formed VPD
> tags for the protocol to work correctly, and that's why I took the cautious
> approach. But with the check for missing EEPROM I hope we've covered the
> most common causes for invalid tags. Let's see how it goes.

True.  The tags need to be well-formed in the sense of having
intelligible lengths so we can identify the beginning and end of each
resource.  But we don't actually depend on the resource name
(ID_STRING, etc) or the content.

> Reviewed-by: Hannes Reinecke <hare@suse.de>
> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke                Kernel Storage Architect
> hare@suse.de                              +49 911 74053 688
> SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer

  reply	other threads:[~2021-07-28 23:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 20:53 [PATCH 0/5] PCI/VPD: Further improvements Heiner Kallweit
2021-05-13 20:55 ` [PATCH 2/5] PCI: Clean up VPD constants and functions in pci.h Heiner Kallweit
2021-07-14 16:43   ` Bjorn Helgaas
2021-05-13 20:56 ` [PATCH 3/5] PCI/VPD: Remove old_size argument from pci_vpd_size Heiner Kallweit
2021-05-13 20:56 ` [PATCH 4/5] PCI/VPD: Make pci_vpd_wait uninterruptible Heiner Kallweit
2021-05-13 20:58 ` [PATCH 1/5] PCI/VPD: Refactor pci_vpd_size Heiner Kallweit
2021-07-13 20:25   ` Bjorn Helgaas
2021-07-13 21:13     ` Heiner Kallweit
2021-07-14 15:50       ` Bjorn Helgaas
2021-07-15  8:31         ` Heiner Kallweit
2021-05-13 21:02 ` [PATCH 5/5] PCI/VPD: Remove pci_vpd member flag Heiner Kallweit
2021-07-06  5:56 ` [PATCH 0/5] PCI/VPD: Further improvements Heiner Kallweit
2021-07-06 14:32   ` Bjorn Helgaas
2021-07-15 21:59 ` [PATCH 0/5] PCI/VPD: pci_vpd_size() cleanups Bjorn Helgaas
2021-07-15 21:59   ` [PATCH 1/5] PCI/VPD: Correct diagnostic for VPD read failure Bjorn Helgaas
2021-07-15 22:07     ` Heiner Kallweit
2021-07-16  5:58     ` Hannes Reinecke
2021-07-15 21:59   ` [PATCH 2/5] PCI/VPD: Check Resource tags against those valid for type Bjorn Helgaas
2021-07-16  5:59     ` Hannes Reinecke
2021-07-15 21:59   ` [PATCH 3/5] PCI/VPD: Consolidate missing EEPROM checks Bjorn Helgaas
2021-07-15 22:16     ` Heiner Kallweit
2021-07-28 23:42       ` Bjorn Helgaas
2021-07-29  6:10         ` Heiner Kallweit
2021-07-29 18:31           ` Bjorn Helgaas
2021-07-16  6:00     ` Hannes Reinecke
2021-07-15 21:59   ` [PATCH 4/5] PCI/VPD: Don't check Large Resource types for validity Bjorn Helgaas
2021-07-16  6:03     ` Hannes Reinecke
2021-07-28 23:46       ` Bjorn Helgaas [this message]
2021-07-15 21:59   ` [PATCH 5/5] PCI/VPD: Allow access to valid parts of VPD if some is invalid Bjorn Helgaas
2021-07-16  6:04     ` Hannes Reinecke
2021-08-02 22:32 ` [PATCH 0/5] PCI/VPD: Further improvements Bjorn Helgaas
2021-08-05 19:10   ` Heiner Kallweit
2021-08-05 19:29     ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210728234613.GA871409@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=hare@suse.de \
    --cc=hkallweit1@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox