Re: [PATCH 1/2] libxl/ACPI: don't hard-code guest page size

["Anthony PERARD" <anthony.perard@vates.tech>]

On Mon, Nov 25, 2024 at 04:15:28PM +0100, Jan Beulich wrote:
> We have libxl_ctxt.page_size for this purpose; use it to eliminate a
> latent buffer overrun.

The 4096 here might actually refer to the size used to allocate
`config.infop`, which is `libxl_ctxt.page_size`. So I don't if the
explanation is correct, but at least now the same value is used for both
zmalloc() and .lenght.

> Fixes: 14c0d328da2b ("libxl/acpi: Build ACPI tables for HVMlite guests")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

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

> ---
> Yet better might be to limit the size to what's actually used (libacpi's
> struct acpi_info). That would then also have avoided the respective part
> of XSA-???.

It's kind of hard to tell here how `infop` is going to be used from this
function, so changing the lenght just here might not do the right thing.

> --- a/tools/libs/light/libxl_x86_acpi.c
> +++ b/tools/libs/light/libxl_x86_acpi.c
> @@ -218,7 +218,7 @@ int libxl__dom_load_acpi(libxl__gc *gc,
>          dom->acpi_modules[0].guest_addr_out = 0x100000 - 64;
>  
>      dom->acpi_modules[1].data = (void *)config.infop;
> -    dom->acpi_modules[1].length = 4096;
> +    dom->acpi_modules[1].length = libxl_ctxt.page_size;
>      dom->acpi_modules[1].guest_addr_out = ACPI_INFO_PHYSICAL_ADDRESS;
>  
>      dom->acpi_modules[2].data = libxl_ctxt.buf;

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech