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

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

 



On Mon, Apr 12, 2021 at 01:27:27PM +0200, Alexander Egorenkov wrote:
> Simon Horman <horms@xxxxxxxxxxxx> 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@xxxxxxxxxx>
> >
> > 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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux