Re: [PATCH 1/1] arm: do not copy magic 4 bytes of appended DTB in zImage

From: Simon Horman <horms@verge.net.au>
To: Alexander Egorenkov <egorenar@posteo.net>
Cc: Alexander Egorenkov <egorenar-dev@posteo.net>,
	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: Sat, 17 Apr 2021 09:19:05 +0200	[thread overview]
Message-ID: <20210417071905.GB2573@vergenet.net> (raw)
In-Reply-To: <874kgb3fq8.fsf@posteo.net>

On Mon, Apr 12, 2021 at 01:27:27PM +0200, Alexander Egorenkov wrote:
> Simon Horman <horms@verge.net.au> writes:
> 
> > 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?
> >
> 
> Hi,
> 
> if i understood it right, then len expresses not the length of the
> kernel image in the zImage but the length of the kernel memory segment
> into which the kernel image is being loaded. And on this line of code
> it is adjusted to account for stack and heap, i think.

Thanks, I think that answers my question.

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