[PATCH for-4.19] tools/dombuilder: Correct the length calculation in xc_dom_alloc_segment()

[PATCH for-4.19] tools/dombuilder: Correct the length calculation in xc_dom_alloc_segment()

[Andrew Cooper]

xc_dom_alloc_segment() is passed a size in bytes, calculates a size in pages
from it, then fills in the new segment information with a bytes value
re-calculated from the number of pages.

This causes the module information given to the guest (MB, or PVH) to have
incorrect sizes; specifically, sizes rounded up to the next page.

This in turn is problematic for Xen.  When Xen finds a gzipped module, it
peeks at the end metadata to judge the decompressed size, which is a -4
backreference from the reported end of the module.

Fill in seg->vend using the correct number of bytes.

Fixes: ea7c8a3d0e82 ("libxc: reorganize domain builder guest memory allocator")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony@xenproject.org>
CC: Juergen Gross <jgross@suse.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>

For 4.19: This was discovered when trying to test Daniel's gzip cleanup for
Hyperlaunch.  It's a subtle bug, hidden inside a second bug which isn't
appropriate content for 4.20.
---
 tools/libs/guest/xg_dom_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libs/guest/xg_dom_core.c b/tools/libs/guest/xg_dom_core.c
index c4f4e7f3e27a..f5521d528be1 100644
--- a/tools/libs/guest/xg_dom_core.c
+++ b/tools/libs/guest/xg_dom_core.c
@@ -601,7 +601,7 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
     memset(ptr, 0, pages * page_size);
 
     seg->vstart = start;
-    seg->vend = dom->virt_alloc_end;
+    seg->vend = start + size;
 
     DOMPRINTF("%-20s:   %-12s : 0x%" PRIx64 " -> 0x%" PRIx64
               "  (pfn 0x%" PRIpfn " + 0x%" PRIpfn " pages)",
-- 
2.39.2

Re: [PATCH for-4.19] tools/dombuilder: Correct the length calculation in xc_dom_alloc_segment()

[Anthony PERARD]

On Thu, Jun 27, 2024 at 02:01:34PM +0100, Andrew Cooper wrote:
> xc_dom_alloc_segment() is passed a size in bytes, calculates a size in pages
> from it, then fills in the new segment information with a bytes value
> re-calculated from the number of pages.
> 
> This causes the module information given to the guest (MB, or PVH) to have
> incorrect sizes; specifically, sizes rounded up to the next page.
> 
> This in turn is problematic for Xen.  When Xen finds a gzipped module, it
> peeks at the end metadata to judge the decompressed size, which is a -4
> backreference from the reported end of the module.
> 
> Fill in seg->vend using the correct number of bytes.
> 
> Fixes: ea7c8a3d0e82 ("libxc: reorganize domain builder guest memory allocator")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> 
> For 4.19: This was discovered when trying to test Daniel's gzip cleanup for
> Hyperlaunch.  It's a subtle bug, hidden inside a second bug which isn't
> appropriate content for 4.20.

Acked-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH for-4.19] tools/dombuilder: Correct the length calculation in xc_dom_alloc_segment()

[oleksii.kurochko]

On Thu, 2024-06-27 at 14:01 +0100, Andrew Cooper wrote:
> xc_dom_alloc_segment() is passed a size in bytes, calculates a size
> in pages
> from it, then fills in the new segment information with a bytes value
> re-calculated from the number of pages.
> 
> This causes the module information given to the guest (MB, or PVH) to
> have
> incorrect sizes; specifically, sizes rounded up to the next page.
> 
> This in turn is problematic for Xen.  When Xen finds a gzipped
> module, it
> peeks at the end metadata to judge the decompressed size, which is a
> -4
> backreference from the reported end of the module.
> 
> Fill in seg->vend using the correct number of bytes.
> 
> Fixes: ea7c8a3d0e82 ("libxc: reorganize domain builder guest memory
> allocator")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Anthony PERARD <anthony@xenproject.org>
> CC: Juergen Gross <jgross@suse.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> For 4.19: This was discovered when trying to test Daniel's gzip
> cleanup for
> Hyperlaunch.  It's a subtle bug, hidden inside a second bug which
> isn't
> appropriate content for 4.20.
> ---
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii

>  tools/libs/guest/xg_dom_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libs/guest/xg_dom_core.c
> b/tools/libs/guest/xg_dom_core.c
> index c4f4e7f3e27a..f5521d528be1 100644
> --- a/tools/libs/guest/xg_dom_core.c
> +++ b/tools/libs/guest/xg_dom_core.c
> @@ -601,7 +601,7 @@ int xc_dom_alloc_segment(struct xc_dom_image
> *dom,
>      memset(ptr, 0, pages * page_size);
>  
>      seg->vstart = start;
> -    seg->vend = dom->virt_alloc_end;
> +    seg->vend = start + size;
>  
>      DOMPRINTF("%-20s:   %-12s : 0x%" PRIx64 " -> 0x%" PRIx64
>                "  (pfn 0x%" PRIpfn " + 0x%" PRIpfn " pages)",