All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Andryuk <jandryuk@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Jason Andryuk <jandryuk@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>
Subject: [PATCH] libelf: Handle PVH kernels lacking ENTRY elfnote
Date: Wed, 14 Oct 2020 11:31:50 -0400	[thread overview]
Message-ID: <20201014153150.83875-1-jandryuk@gmail.com> (raw)

Linux kernels only have an ENTRY elfnote when built with CONFIG_PV.  A
kernel build CONFIG_PVH=y CONFIG_PV=n lacks the note.  In this case,
virt_entry will be UNSET_ADDR, overwritten by the ELF header e_entry,
and fail the check against the virt address range.

Change the code to only check virt_entry against the virtual address
range if it was set upon entry to the function.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>

---
Maybe the overwriting of virt_entry could be removed, but I don't know
if there would be unintended consequences where (old?) kernels don't
have an elfnote, but do have an in-range e_entry?  The failing kernel I
just looked at has an e_entry of 0x1000000.

Oh, it looks like Mini-OS doesn't set the entry ELFNOTE and relies on
e_entry (of 0) to pass these checks.

---
 xen/common/libelf/libelf-dominfo.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index 508f08db42..1ecf35166b 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -416,6 +416,7 @@ static elf_errorstatus elf_xen_note_check(struct elf_binary *elf,
 static elf_errorstatus elf_xen_addr_calc_check(struct elf_binary *elf,
                                    struct elf_dom_parms *parms)
 {
+    bool check_virt_entry = true;
     uint64_t virt_offset;
 
     if ( (parms->elf_paddr_offset != UNSET_ADDR) &&
@@ -456,8 +457,10 @@ static elf_errorstatus elf_xen_addr_calc_check(struct elf_binary *elf,
     parms->virt_kstart = elf->pstart + virt_offset;
     parms->virt_kend   = elf->pend   + virt_offset;
 
-    if ( parms->virt_entry == UNSET_ADDR )
+    if ( parms->virt_entry == UNSET_ADDR ) {
         parms->virt_entry = elf_uval(elf, elf->ehdr, e_entry);
+        check_virt_entry = false;
+    }
 
     if ( parms->bsd_symtab )
     {
@@ -476,11 +479,17 @@ static elf_errorstatus elf_xen_addr_calc_check(struct elf_binary *elf,
     elf_msg(elf, "    p2m_base         = 0x%" PRIx64 "\n", parms->p2m_base);
 
     if ( (parms->virt_kstart > parms->virt_kend) ||
-         (parms->virt_entry < parms->virt_kstart) ||
-         (parms->virt_entry > parms->virt_kend) ||
          (parms->virt_base > parms->virt_kstart) )
     {
-        elf_err(elf, "ERROR: ELF start or entries are out of bounds\n");
+        elf_err(elf, "ERROR: ELF start is out of bounds\n");
+        return -1;
+    }
+
+    if ( check_virt_entry &&
+         ( (parms->virt_entry < parms->virt_kstart) ||
+           (parms->virt_entry > parms->virt_kend) ) )
+    {
+        elf_err(elf, "ERROR: ELF entry is out of bounds\n");
         return -1;
     }
 
-- 
2.26.2



             reply	other threads:[~2020-10-14 15:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-14 15:31 Jason Andryuk [this message]
2020-10-14 15:52 ` [PATCH] libelf: Handle PVH kernels lacking ENTRY elfnote Wei Liu
2020-10-14 16:02 ` Jan Beulich
2020-10-14 16:27   ` Jason Andryuk
2020-10-15  7:00     ` Jan Beulich
2020-10-15 14:50       ` Jason Andryuk
2020-10-15 15:14         ` Jan Beulich
2020-10-15 17:27           ` Andrew Cooper
2020-10-16 16:28           ` Jason Andryuk
2020-10-19  7:38             ` Jan Beulich
2020-10-19 15:26               ` Jason Andryuk
2020-10-19 15:36                 ` Jan Beulich
2020-10-15 15:03       ` Roger Pau Monné
2020-10-14 16:12 ` Jürgen Groß
2020-10-14 16:27   ` Jason Andryuk
2020-10-15  4:17     ` Jürgen Groß

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201014153150.83875-1-jandryuk@gmail.com \
    --to=jandryuk@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.