* RV and RW fields must be at the last position in their respective
  section (per the conditions in the spec). Therefore, the parser now
  stops iterating over fields as soon as it encounters one of those
  fields and checks whether the end of the resource has been reached;
* Individual fields must have a valid length - the parser needs to check
  for invalid length values that violate boundary conditions of the
  resource.
* A zero-length field may be the last one in the resource, however, the
  boundary check is currently too strict to allow that.

Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
---
 src/util/virpcivpd.c  | 28 +++++++++++----
 tests/virpcivpdtest.c | 84 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 106 insertions(+), 6 deletions(-)

diff --git a/src/util/virpcivpd.c b/src/util/virpcivpd.c
index 8856bca459..cd49031fa4 100644
--- a/src/util/virpcivpd.c
+++ b/src/util/virpcivpd.c
@@ -466,8 +466,12 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uint16_t resPos, uint16_t re
 
     bool hasChecksum = false;
     bool hasRW = false;
+    bool endReached = false;
 
-    while (fieldPos + 3 < resPos + resDataLen) {
+    /* Note the equal sign - fields may have a zero length in which case they will
+     * just occupy 3 header bytes. In the in case of the RW field this may mean that
+     * no more space is left in the section. */
+    while (fieldPos + 3 <= resPos + resDataLen) {
         /* Keyword resources consist of keywords (2 ASCII bytes per the spec) and 1-byte length. */
         if (virPCIVPDReadVPDBytes(vpdFileFd, buf, 3, fieldPos, csum) != 3) {
             /* Invalid field encountered which means the resource itself is invalid too. Report
@@ -518,6 +522,13 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uint16_t resPos, uint16_t re
                 return false;
         }
 
+        if (resPos + resDataLen < fieldPos + fieldDataLen) {
+            /* In this case the field cannot simply be skipped since the position of the
+             * next field is determined based on the length of a previous field. */
+            virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+                           _("A field data length violates the resource length boundary."));
+            return false;
+        }
         if (virPCIVPDReadVPDBytes(vpdFileFd, buf, bytesToRead, fieldPos, csum) != bytesToRead) {
             virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
                            _("Could not parse a resource field data - VPD has invalid format"));
@@ -546,12 +557,13 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uint16_t resPos, uint16_t re
             hasChecksum = true;
             g_free(g_steal_pointer(&fieldKeyword));
             g_free(g_steal_pointer(&fieldValue));
-            continue;
+            break;
         } else if (fieldFormat == VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_RDWR) {
             /* Skip the read-write space since it is used for indication only. */
             hasRW = true;
             g_free(g_steal_pointer(&fieldKeyword));
             g_free(g_steal_pointer(&fieldValue));
+            break;
         } else if (fieldFormat == VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_LAST) {
             /* Skip unknown fields */
             g_free(g_steal_pointer(&fieldKeyword));
@@ -579,13 +591,17 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uint16_t resPos, uint16_t re
         g_free(g_steal_pointer(&fieldKeyword));
         g_free(g_steal_pointer(&fieldValue));
     }
-    if (readOnly && !hasChecksum) {
+
+    /* May have exited the loop prematurely in case RV or RW were encountered and
+     * they were not the last fields in the section. */
+    endReached = (fieldPos >= resPos + resDataLen);
+    if (readOnly && !(hasChecksum && endReached)) {
         virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-                       _("VPD-R does not contain the mandatory RV field"));
+                _("VPD-R does not contain the mandatory RV field as the last field"));
         return false;
-    } else if (!readOnly && !hasRW) {
+    } else if (!readOnly && !(hasRW && endReached)) {
         virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-                       _("VPD-W does not contain the mandatory RW field"));
+                       _("VPD-W does not contain the mandatory RW field as the last field"));
         return false;
     }
 
diff --git a/tests/virpcivpdtest.c b/tests/virpcivpdtest.c
index 2cc9069132..65607c1247 100644
--- a/tests/virpcivpdtest.c
+++ b/tests/virpcivpdtest.c
@@ -597,6 +597,58 @@ testVirPCIVPDParseFullVPD(const void *opaque G_GNUC_UNUSED)
     return ret;
 }
 
+static int
+testVirPCIVPDParseZeroLengthRW(const void *opaque G_GNUC_UNUSED)
+{
+    int fd = -1;
+    size_t dataLen = 0;
+
+    g_autoptr(virPCIVPDResource) res = NULL;
+    virPCIVPDResourceCustom *custom = NULL;
+
+    /* The RW field has a zero length  which means there is no more RW space left. */
+    const uint8_t fullVPDExample[] = {
+        VPD_STRING_RESOURCE_EXAMPLE_HEADER, VPD_STRING_RESOURCE_EXAMPLE_DATA,
+        VPD_R_FIELDS_EXAMPLE_HEADER, VPD_R_FIELDS_EXAMPLE_DATA,
+        PCI_VPD_LARGE_RESOURCE_FLAG | PCI_VPD_READ_WRITE_LARGE_RESOURCE_FLAG, 0x08, 0x00,
+        'V', 'Z', 0x02, '4', '2',
+        'R', 'W', 0x00,
+        PCI_VPD_RESOURCE_END_VAL
+    };
+
+    dataLen = sizeof(fullVPDExample) / sizeof(uint8_t);
+    fd = virCreateAnonymousFile(fullVPDExample, dataLen);
+    res = virPCIVPDParse(fd);
+    VIR_FORCE_CLOSE(fd);
+
+    if (!res) {
+        virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+                       "The resource pointer is NULL after parsing which is unexpected");
+        return -1;
+    }
+
+    if (!res->ro) {
+        virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+                "Read-only keywords are missing from the VPD resource.");
+        return -1;
+    } else if (!res->rw) {
+        virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+                "Read-write keywords are missing from the VPD resource.");
+        return -1;
+    }
+
+    if (testVirPCIVPDValidateExampleReadOnlyFields(res))
+        return -1;
+
+    custom = g_ptr_array_index(res->rw->vendor_specific, 0);
+    if (custom->idx != 'Z' || STRNEQ_NULLABLE(custom->value, "42"))
+        return -1;
+
+    custom = NULL;
+    return 0;
+}
+
+
 static int
 testVirPCIVPDParseFullVPDSkipInvalidKeywords(const void *opaque G_GNUC_UNUSED)
 {
@@ -717,6 +769,32 @@ testVirPCIVPDParseFullVPDInvalid(const void *opaque G_GNUC_UNUSED)
     'R', 'V', 0x02, 0x8A, 0x00, \
     PCI_VPD_RESOURCE_END_VAL
 
+/* The SN field has a length field that goes past the resource boundaries. */
+# define VPD_INVALID_SN_FIELD_LENGTH \
+    VPD_STRING_RESOURCE_EXAMPLE_HEADER, \
+    't', 'e', 's', 't', 'n', 'a', 'm', 'e', \
+    PCI_VPD_LARGE_RESOURCE_FLAG | PCI_VPD_READ_ONLY_LARGE_RESOURCE_FLAG, 0x0A, 0x00, \
+    'S', 'N', 0x42, 0x04, 0x02, \
+    'R', 'V', 0x02, 0xE8, 0x00, \
+    PCI_VPD_RESOURCE_END_VAL
+
+/* The RV field is not the last one in VPD-R while the checksum is valid. */
+# define VPD_INVALID_RV_NOT_LAST \
+    VPD_STRING_RESOURCE_EXAMPLE_HEADER, \
+    't', 'e', 's', 't', 'n', 'a', 'm', 'e', \
+    PCI_VPD_LARGE_RESOURCE_FLAG | PCI_VPD_READ_ONLY_LARGE_RESOURCE_FLAG, 0x0A, 0x00, \
+    'R', 'V', 0x02, 0xD1, 0x00, \
+    'S', 'N', 0x02, 0x04, 0x02, \
+    PCI_VPD_RESOURCE_END_VAL
+
+# define VPD_INVALID_RW_NOT_LAST \
+    VPD_STRING_RESOURCE_EXAMPLE_HEADER, VPD_STRING_RESOURCE_EXAMPLE_DATA, \
+    VPD_R_FIELDS_EXAMPLE_HEADER, VPD_R_FIELDS_EXAMPLE_DATA, \
+    PCI_VPD_LARGE_RESOURCE_FLAG | PCI_VPD_READ_WRITE_LARGE_RESOURCE_FLAG, 0x08, 0x00, \
+    'R', 'W', 0x00, \
+    'V', 'Z', 0x02, '4', '2', \
+    PCI_VPD_RESOURCE_END_VAL
+
 # define TEST_INVALID_VPD(invalidVPD) \
     do { \
         g_autoptr(virPCIVPDResource) res = NULL; \
@@ -741,6 +819,9 @@ testVirPCIVPDParseFullVPDInvalid(const void *opaque G_GNUC_UNUSED)
     TEST_INVALID_VPD(VPD_R_UNEXPECTED_RW_IN_VPD_R_KEY);
     TEST_INVALID_VPD(VPD_R_INVALID_FIELD_VALUE);
     TEST_INVALID_VPD(VPD_INVALID_STRING_RESOURCE_VALUE);
+    TEST_INVALID_VPD(VPD_INVALID_SN_FIELD_LENGTH);
+    TEST_INVALID_VPD(VPD_INVALID_RV_NOT_LAST);
+    TEST_INVALID_VPD(VPD_INVALID_RW_NOT_LAST);
 
     return 0;
 }
@@ -767,6 +848,9 @@ mymain(void)
         ret = -1;
     if (virTestRun("Parsing VPD string resources ", testVirPCIVPDParseVPDStringResource, NULL) < 0)
         ret = -1;
+    if (virTestRun("Parsing a VPD resource with a zero-length RW ",
+                   testVirPCIVPDParseZeroLengthRW, NULL) < 0)
+        ret = -1;
     if (virTestRun("Parsing a VPD resource with an invalid keyword ",
                    testVirPCIVPDParseFullVPDSkipInvalidKeywords, NULL) < 0)
         ret = -1;
-- 
2.32.0

On Fri, Oct 22, 2021 at 03:45:42PM +0300, Dmitrii Shcherbakov wrote:
> * RV and RW fields must be at the last position in their respective
>   section (per the conditions in the spec). Therefore, the parser now
>   stops iterating over fields as soon as it encounters one of those
>   fields and checks whether the end of the resource has been reached;
> * Individual fields must have a valid length - the parser needs to check
>   for invalid length values that violate boundary conditions of the
>   resource.
> * A zero-length field may be the last one in the resource, however, the
>   boundary check is currently too strict to allow that.
> 
> Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
> ---
>  src/util/virpcivpd.c  | 28 +++++++++++----
>  tests/virpcivpdtest.c | 84 +++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 106 insertions(+), 6 deletions(-)
> 
> diff --git a/src/util/virpcivpd.c b/src/util/virpcivpd.c
> index 8856bca459..cd49031fa4 100644
> --- a/src/util/virpcivpd.c
> +++ b/src/util/virpcivpd.c
> @@ -466,8 +466,12 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uint16_t resPos, uint16_t re
>  
>      bool hasChecksum = false;
>      bool hasRW = false;
> +    bool endReached = false;
>  
> -    while (fieldPos + 3 < resPos + resDataLen) {
> +    /* Note the equal sign - fields may have a zero length in which case they will
> +     * just occupy 3 header bytes. In the in case of the RW field this may mean that
> +     * no more space is left in the section. */
> +    while (fieldPos + 3 <= resPos + resDataLen) {
>          /* Keyword resources consist of keywords (2 ASCII bytes per the spec) and 1-byte length. */
>          if (virPCIVPDReadVPDBytes(vpdFileFd, buf, 3, fieldPos, csum) != 3) {
>              /* Invalid field encountered which means the resource itself is invalid too. Report
> @@ -518,6 +522,13 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uint16_t resPos, uint16_t re
>                  return false;
>          }
>  
> +        if (resPos + resDataLen < fieldPos + fieldDataLen) {
> +            /* In this case the field cannot simply be skipped since the position of the
> +             * next field is determined based on the length of a previous field. */
> +            virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> +                           _("A field data length violates the resource length boundary."));
> +            return false;
> +        }
>          if (virPCIVPDReadVPDBytes(vpdFileFd, buf, bytesToRead, fieldPos, csum) != bytesToRead) {
>              virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
>                             _("Could not parse a resource field data - VPD has invalid format"));
> @@ -546,12 +557,13 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uint16_t resPos, uint16_t re
>              hasChecksum = true;
>              g_free(g_steal_pointer(&fieldKeyword));
>              g_free(g_steal_pointer(&fieldValue));
> -            continue;
> +            break;
>          } else if (fieldFormat == VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_RDWR) {
>              /* Skip the read-write space since it is used for indication only. */
>              hasRW = true;
>              g_free(g_steal_pointer(&fieldKeyword));
>              g_free(g_steal_pointer(&fieldValue));
> +            break;
>          } else if (fieldFormat == VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_LAST) {
>              /* Skip unknown fields */
>              g_free(g_steal_pointer(&fieldKeyword));
> @@ -579,13 +591,17 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uint16_t resPos, uint16_t re
>          g_free(g_steal_pointer(&fieldKeyword));
>          g_free(g_steal_pointer(&fieldValue));
>      }
> -    if (readOnly && !hasChecksum) {
> +
> +    /* May have exited the loop prematurely in case RV or RW were encountered and
> +     * they were not the last fields in the section. */
> +    endReached = (fieldPos >= resPos + resDataLen);
> +    if (readOnly && !(hasChecksum && endReached)) {
>          virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> -                       _("VPD-R does not contain the mandatory RV field"));
> +                _("VPD-R does not contain the mandatory RV field as the last field"));
>          return false;
> -    } else if (!readOnly && !hasRW) {
> +    } else if (!readOnly && !(hasRW && endReached)) {
>          virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> -                       _("VPD-W does not contain the mandatory RW field"));
> +                       _("VPD-W does not contain the mandatory RW field as the last field"));
>          return false;

Something is still not right with the logic here as this error report
is triggering on my machines. If I comment out this check, then I can
get data reported by libvirt


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Hi Daniel,

> Something is still not right with the logic here as this error report
is triggering on my machines. If I comment out this check, then I can
get data reported by libvirt

The VPD example you shared previously has multiple violations of the VPD format:

* Invalid field values ("N/A" in the read-only section, 0xFF in the
read-write section);
* The lack of the RW field at the end of the read-write section.

Previously, the VPD was discarded due to invalid values.

I thought honoring the RW requirement would still make sense and kept
the RW presence check.

I added it as a test case here (converted to hex):
https://listman.redhat.com/archives/libvir-list/2021-October/msg00871.html

The spec says the following (PCIe 4.0 "6.28.2.3 Read/Write Fields"):

"RW | Remaining Read/Write Area |
This descriptor is used to identify the unused portion of the
read/write space. The product
vendor initializes this parameter based on the size of the read/write
space or the space remaining
following the Vx VPD items. One or more of the Vx, Yx, and RW items
are required."

I can also confirm that by looking at the hexdump and looking for hex
values for R (0x52) and W (0x57):

hexdump -e '16/1 "0x%02x, " "\n"' vpd

I could ease it up and allow it to be missing as we do not care much
about it when reading so long as the resource
length is correct. However, if we were to allow Libvirt to write to
the read-write section in the future we would need to
know how much free space is there in the first place.

On Tue, Oct 26, 2021 at 08:28:20PM +0300, Dmitrii Shcherbakov wrote:
> Hi Daniel,
> 
> > Something is still not right with the logic here as this error report
> is triggering on my machines. If I comment out this check, then I can
> get data reported by libvirt
> 
> The VPD example you shared previously has multiple violations of the VPD format:
> 
> * Invalid field values ("N/A" in the read-only section, 0xFF in the
> read-write section);
> * The lack of the RW field at the end of the read-write section.
> 
> Previously, the VPD was discarded due to invalid values.
> 
> I thought honoring the RW requirement would still make sense and kept
> the RW presence check.
> 
> I added it as a test case here (converted to hex):
> https://listman.redhat.com/archives/libvir-list/2021-October/msg00871.html
> 
> The spec says the following (PCIe 4.0 "6.28.2.3 Read/Write Fields"):
> 
> "RW | Remaining Read/Write Area |
> This descriptor is used to identify the unused portion of the
> read/write space. The product
> vendor initializes this parameter based on the size of the read/write
> space or the space remaining
> following the Vx VPD items. One or more of the Vx, Yx, and RW items
> are required."
> 
> I can also confirm that by looking at the hexdump and looking for hex
> values for R (0x52) and W (0x57):
> 
> hexdump -e '16/1 "0x%02x, " "\n"' vpd
> 
> I could ease it up and allow it to be missing as we do not care much
> about it when reading so long as the resource
> length is correct. However, if we were to allow Libvirt to write to
> the read-write section in the future we would need to
> know how much free space is there in the first place.

The issue I have is that 'lspci -vvv' will happily report the VPD
data on my machine:

        Capabilities: [e0] Vital Product Data
                Product Name: HP Ethernet 1Gb 2-port 361i Adapter
                Read-only fields:
                        [PN] Part number: N/A
                        [EC] Engineering changes: N/A
                        [SN] Serial number: N/A
                        [V0] Vendor specific: 4W/1W PCIeG2x4 2p 1GbE RJ45 Intel i350   
                        [RV] Reserved: checksum good, 0 byte(s) reserved
                Read/write fields:
                        [V1] Vendor specific: 5.7.06
                        [V3] Vendor specific: 2.8.20
                        [V6] Vendor specific: 1.5.35
                        [YA] Asset tag: N/A
                        [YB] System specific: <FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF>
                        [YC] System specific: <FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF>
                End


while libvirt refuses to report it. Even if the BIOS is not perfectly
following the spec, it is clearly still possible to extract the data
and display it to the user. So I don't think it is reasonable for libvirt
to refuse todo this.  I'd have sympathy if this machine was pre-production
hardware or from a no-name vendor, but this machine is typical production
quality hardware from a major vendor.

The only think there I think it is reasonable for libvirt to reject the
data is in the cae of the two fields that contain non-printable
characters <FF>.  Other than that I expect libvirt to report exactly
the same data as lspci will report, and not try to secondguess whether
the values provided by the vendor are semantically valid or not.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Daniel,

> The issue I have is that 'lspci -vvv' will happily report the VPD
> data on my machine:
>
> ...
>
> while libvirt refuses to report it. Even if the BIOS is not perfectly
> following the spec, it is clearly still possible to extract the data
> and display it to the user. So I don't think it is reasonable for libvirt
> to refuse todo this.  I'd have sympathy if this machine was pre-production
> hardware or from a no-name vendor, but this machine is typical production
> quality hardware from a major vendor.
>
> The only think there I think it is reasonable for libvirt to reject the
> data is in the cae of the two fields that contain non-printable
> characters <FF>.  Other than that I expect libvirt to report exactly
> the same data as lspci will report, and not try to secondguess whether
> the values provided by the vendor are semantically valid or not.

Makes sense to me: we can make a policy decision that better fits
users and the reality of existing hardware.

I also recognize that the VPD spec is quite old and it does not
include a very good description of the supported character set
(besides saying "alphanumeric").

I tried to follow the spec relatively strictly but I agree that a
balance between that and providing useful information is needed.

I'll resend the series and restrict the character set to the set of
printable ASCII code points and ignore the lack of RW at the end of
the read-write section.

Best Regards,
Dmitrii Shcherbakov
LP/oftc: dmitriis