Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Alexander Egorenkov <egorenar-dev@posteo.net>
Cc: rmk@armlinux.org.uk, kexec@lists.infradead.org
Subject: Re: [PATCH 1/1] arm: do not copy magic 4 bytes of appended DTB in zImage
Date: Mon, 12 Apr 2021 12:38:53 +0200	[thread overview]
Message-ID: <20210412103853.GA28946@vergenet.net> (raw)
In-Reply-To: <20210408200644.19724-1-egorenar-dev@posteo.net>

On Thu, Apr 08, 2021 at 10:06:44PM +0200, Alexander Egorenkov wrote:
> 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>

Hi,

I also see that, on line 558 len is further expanded as follows:

        /*
         * The zImage length does not include its stack (4k) or its
         * malloc space (64k).  Include this.
         */
        len += 0x11000;

Is it intentional that this patch also excludes this extra length
from the DTB? Or am I missing something?

> ---
>  kexec/arch/arm/kexec-zImage-arm.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
> index 925a9be..8ec289d 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,8 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
>  		}
>  	}
>  
> +	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 +762,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
> 

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

  reply	other threads:[~2021-04-12 10:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08 20:06 [PATCH 1/1] arm: do not copy magic 4 bytes of appended DTB in zImage Alexander Egorenkov
2021-04-12 10:38 ` Simon Horman [this message]
2021-04-12 11:27   ` Alexander Egorenkov
2021-04-17  7:19     ` Simon Horman
2021-04-12 10:52 ` Russell King - ARM Linux admin

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=20210412103853.GA28946@vergenet.net \
    --to=horms@verge.net.au \
    --cc=egorenar-dev@posteo.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox