From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <kexec-bounces+dwmw2=infradead.org@lists.infradead.org>
Received: from mout02.posteo.de ([185.67.36.66])
 by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux))
 id 1lVujN-006Atz-5j
 for kexec@lists.infradead.org; Mon, 12 Apr 2021 11:27:50 +0000
Received: from submission (posteo.de [89.146.220.130]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 5BB9E240101
 for <kexec@lists.infradead.org>; Mon, 12 Apr 2021 13:27:33 +0200 (CEST)
From: Alexander Egorenkov <egorenar@posteo.net>
Subject: Re: [PATCH 1/1] arm: do not copy magic 4 bytes of appended DTB in
 zImage
In-Reply-To: <20210412103853.GA28946@vergenet.net>
References: <20210408200644.19724-1-egorenar-dev@posteo.net>
 <20210412103853.GA28946@vergenet.net>
Date: Mon, 12 Apr 2021 13:27:27 +0200
Message-ID: <874kgb3fq8.fsf@posteo.net>
MIME-Version: 1.0
List-Id: <kexec.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/kexec>,
 <mailto:kexec-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/kexec/>
List-Post: <mailto:kexec@lists.infradead.org>
List-Help: <mailto:kexec-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/kexec>,
 <mailto:kexec-request@lists.infradead.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "kexec" <kexec-bounces@lists.infradead.org>
Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org
To: Simon Horman <horms@verge.net.au>, Alexander Egorenkov <egorenar-dev@posteo.net>
Cc: rmk@armlinux.org.uk, kexec@lists.infradead.org

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.

Regards
Alex

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