All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.