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

Re: [PATCH] xen: consider alloc-only segments when loading PV dom0 kernel


  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 23 Jun 2022 11:04:11 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lJ4QXewQvgXnvx0V4pxYg7RGzttLNZQvSM0/FQi9rjI=; b=VwQlGuOq6gQAtun9brq5ba2dU6/xHsqZXl7IazQvydqahwjziXsqbeYQ3RKwCKHssBUMLNUy7bjs6L72vXMtmjoJF1tX7JgmVK66ShGJEc6U9v4FANQ6Dki4Ems4V0hEHJy6vNqBIvnEMWO22gxnQs0kZxYffzmv0CjEAKlyhGqg7I3/8GeqJnfMFxvzVUXHAVIflyRXDdb8CKapo3bDv5d/AONjRurr8EAsVzQmx09hXBozmNexLp0s3mU2Qhsex8u7jPjUd/Gs5gds/UQBQmiPigZLutz2pZmFwzz3QxUHL32IQ44eW0k1fTo17M9oDKMjimDpFQvYhvwg0WqhoQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OYlwdNt3AD501LUmfD8sDAW9l+EFYTvJWoGHTDT+sYwtfTkfhPEsc4XKg3iGbH/eHLzKRvG5tTfpMVdg750mCtaAilK1ruA1+9+qQdFUPNpy/VRMfrr1msMQlJhR2CSIfidTCqKQiSxS9MlP5yDHs++PKBaFQ4Mx0EdcBLOi4ZZ4RNVs3FUGn9ij/B9dxA5zcIUTeDLYPtiHvOJdOfEqQnMUpes9ssbr77fQOr74Z0eZSNjozYlNz9nlST3chvSbqJmahX/7o617fYdo/+oCJz3XCVWQEUoXP55oQqjozm3an4k5yNyRgLNCUX1EzWo1+06KlmforEcJgrfkuHKGdw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 23 Jun 2022 09:04:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.06.2022 10:02, Juergen Gross wrote:
> When loading the dom0 kernel for PV mode, the first free usable memory
> location after the kernel needs to take segments into account, which
> have only the ALLOC flag set, but are not specified to be loaded in
> the program headers of the ELF file.
> 
> This is e.g. a problem for Linux kernels from 5.19 onwards, as those
> can have a final NOLOAD section at the end, which must not be used by
> e.g. the start_info structure or the initial page tables allocated by
> the hypervisor.
> 
> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> ---
>  xen/common/libelf/libelf-loader.c | 33 +++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/xen/common/libelf/libelf-loader.c 
> b/xen/common/libelf/libelf-loader.c
> index 629cc0d3e6..4b0e3ced55 100644
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -467,7 +467,9 @@ do {                                                      
>           \
>  void elf_parse_binary(struct elf_binary *elf)
>  {
>      ELF_HANDLE_DECL(elf_phdr) phdr;
> +    ELF_HANDLE_DECL(elf_shdr) shdr;
>      uint64_t low = -1, high = 0, paddr, memsz;
> +    uint64_t vlow = -1, vhigh = 0, vaddr, voff;
>      unsigned i, count;
>  
>      count = elf_phdr_count(elf);
> @@ -480,6 +482,7 @@ void elf_parse_binary(struct elf_binary *elf)
>          if ( !elf_phdr_is_loadable(elf, phdr) )
>              continue;
>          paddr = elf_uval(elf, phdr, p_paddr);
> +        vaddr = elf_uval(elf, phdr, p_vaddr);
>          memsz = elf_uval(elf, phdr, p_memsz);
>          elf_msg(elf, "ELF: phdr: paddr=%#" PRIx64 " memsz=%#" PRIx64 "\n",
>                  paddr, memsz);
> @@ -487,7 +490,37 @@ void elf_parse_binary(struct elf_binary *elf)
>              low = paddr;
>          if ( high < paddr + memsz )
>              high = paddr + memsz;
> +        if ( vlow > vaddr )
> +            vlow = vaddr;
> +        if ( vhigh < vaddr + memsz )
> +            vhigh = vaddr + memsz;
>      }
> +
> +    voff = vhigh - high;
> +
> +    count = elf_shdr_count(elf);
> +    for ( i = 0; i < count; i++ )
> +    {
> +        shdr = elf_shdr_by_index(elf, i);
> +        if ( !elf_access_ok(elf, ELF_HANDLE_PTRVAL(shdr), 1) )
> +            /* input has an insane section header count field */
> +            break;
> +        if ( !(elf_uval(elf, shdr, sh_flags) & SHF_ALLOC) )
> +            continue;
> +        vaddr = elf_uval(elf, shdr, sh_addr);
> +        memsz = elf_uval(elf, shdr, sh_size);
> +        if ( vlow > vaddr )
> +        {
> +            vlow = vaddr;
> +            low = vaddr - voff;
> +        }
> +        if ( vhigh < vaddr + memsz )
> +        {
> +            vhigh = vaddr + memsz;
> +            high = vaddr + memsz - voff;
> +        }
> +    }

As said in the reply to your problem report: The set of PHDRs doesn't
cover all sections. For loading one should never need to resort to
parsing section headers - in a loadable binary it is no error if
there's no section table in the first place. (The title is also
misleading, as you really mean sections there, not segments. Afaik
there's no concept of "alloc" for segments, which are what program
headers describe.)

Also: Needing to fix this in the hypervisor would mean that Linux
5.19 and onwards cannot be booted on Xen without whichever fix
backported.

Finally, you changing libelf but referring to only Dom0 in the title
looks inconsistent to me.

Jan



 


Rackspace

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