All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Egorenkov <egorenar-dev@posteo.net>
To: rmk@armlinux.org.uk, horms@verge.net.au
Cc: kexec@lists.infradead.org, Alexander Egorenkov <egorenar-dev@posteo.net>
Subject: [PATCH v2 1/1] arm: do not copy magic 4 bytes of appended DTB in zImage
Date: Mon, 12 Apr 2021 13:18:05 +0200	[thread overview]
Message-ID: <20210412111805.31643-1-egorenar-dev@posteo.net> (raw)

If the passed zImage happens to have a DTB appended, then the magic 4 bytes
of the DTB are copied together with the kernel image. This leads to
failed kexec boots because the decompressor finds the aforementioned
DTB magic and falsely tries to replace the DTB passed in the register r2
with the non-existent appended one.

Signed-off-by: Alexander Egorenkov <egorenar-dev@posteo.net>
---

v1 -> v2:
  * Add a comment explaining the reason for introducing kernel_buf_size 

 kexec/arch/arm/kexec-zImage-arm.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
index 925a9be..f4c23bf 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -382,6 +382,7 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
 	unsigned int atag_offset = 0x1000; /* 4k offset from memory start */
 	unsigned int extra_size = 0x8000; /* TEXT_OFFSET */
 	const struct zimage_tag *tag;
+	size_t kernel_buf_size;
 	size_t kernel_mem_size;
 	const char *command_line;
 	char *modified_cmdline = NULL;
@@ -537,6 +538,15 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
 		}
 	}
 
+	/*
+	 * Save the length of the compressed kernel image w/o the appended DTB.
+	 * This will be required later on when the kernel image contained
+	 * in the zImage will be loaded into a kernel memory segment.
+	 * And we want to load ONLY the compressed kernel image from the zImage
+	 * and discard the appended DTB.
+	 */
+	kernel_buf_size = len;
+
 	/*
 	 * Always extend the zImage by four bytes to ensure that an appended
 	 * DTB image always sees an initialised value after _edata.
@@ -759,7 +769,7 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
 		add_segment(info, dtb_buf, dtb_length, dtb_offset, dtb_length);
 	}
 
-	add_segment(info, buf, len, kernel_base, kernel_mem_size);
+	add_segment(info, buf, kernel_buf_size, kernel_base, kernel_mem_size);
 
 	info->entry = (void*)kernel_base;
 
-- 
2.31.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

             reply	other threads:[~2021-04-12 11:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12 11:18 Alexander Egorenkov [this message]
2021-04-17  7:21 ` [PATCH v2 1/1] arm: do not copy magic 4 bytes of appended DTB in zImage Simon Horman

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=20210412111805.31643-1-egorenar-dev@posteo.net \
    --to=egorenar-dev@posteo.net \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=rmk@armlinux.org.uk \
    /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.