[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/1] tools/libs/light: fix BAR memory address truncation


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Jiqian Chen <Jiqian.Chen@xxxxxxx>
  • From: Jürgen Groß <jgross@xxxxxxxx>
  • Date: Fri, 10 Oct 2025 11:02:57 +0200
  • Autocrypt: addr=jgross@xxxxxxxx; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
  • Cc: Huang Rui <ray.huang@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 10 Oct 2025 09:03:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.10.25 10:19, Jan Beulich wrote:
On 10.10.2025 10:00, Jiqian Chen wrote:
64-bit BAR memory address is truncated when removing a passthrough pci
device from guest since it uses "unsigned int".

You talking of address truncation only here, ...

--- a/tools/libs/light/libxl_pci.c
+++ b/tools/libs/light/libxl_pci.c
@@ -2001,7 +2001,8 @@ static void pci_remove_detached(libxl__egc *egc,
  {
      STATE_AO_GC(prs->aodev->ao);
      libxl_ctx *ctx = libxl__gc_owner(gc);
-    unsigned int start = 0, end = 0, flags = 0, size = 0, irq = 0;
+    unsigned long long start = 0, end = 0, flags = 0, size = 0;
+    unsigned int irq = 0;

... does "flags" really need widening, too?

At least on the system I looked the value was printed as a 64-bit one:

# cat /sys/bus/pci/devices/0000:00:00.0/resource
0x0000000000000000 0x0000000000000000 0x0000000000000000
...

So not widening flags would rely on UB to preserve the evaluated PCI_BAR_IO
flag in case the high 32 bits don't contain 0.


@@ -2031,7 +2032,7 @@ static void pci_remove_detached(libxl__egc *egc,
      }
for (i = 0; i < PROC_PCI_NUM_RESOURCES; i++) {
-        if (fscanf(f, "0x%x 0x%x 0x%x\n", &start, &end, &flags) != 3)
+        if (fscanf(f, "0x%llx 0x%llx 0x%llx\n", &start, &end, &flags) != 3)

While touching this, don't we want to drop the stray 0x in here? Their
presence causes bogus input like 0x0x0 to be accepted, afaict.

Hmm, do we really expect a sysfs file to produce bogus output?

Wouldn't it be better to keep the "0x" in order to detect a differing
output format, which could result in silent misbehavior?

I'm not really feeling strong here, as both cases seem highly unlikely.


@@ -2040,7 +2041,7 @@ static void pci_remove_detached(libxl__egc *egc,
                                                   size, 0);
                  if (rc < 0)
                      LOGED(ERROR, domid,
-                          "xc_domain_ioport_permission error 0x%x/0x%x",
+                          "xc_domain_ioport_permission error 0x%llx/0x%llx",
                            start,
                            size);
              } else {
@@ -2050,7 +2051,7 @@ static void pci_remove_detached(libxl__egc *egc,
                                                  0);
                  if (rc < 0)
                      LOGED(ERROR, domid,
-                          "xc_domain_iomem_permission error 0x%x/0x%x",
+                          "xc_domain_iomem_permission error 0x%llx/0x%llx",

In the hypervisor I would request use of %#llx here; not sure what the
toolstack's take on this is.

I'd go a little bit further and request to use uint64_t instead of
"unsigned long long" and then use "#"PRIx64 for the format.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.