From patchwork Mon Oct 14 13:44:22 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Mack X-Patchwork-Id: 3036421 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 90755BF924 for ; Mon, 14 Oct 2013 13:46:07 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5BBEF20221 for ; Mon, 14 Oct 2013 13:46:06 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E716020219 for ; Mon, 14 Oct 2013 13:46:04 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VViSj-0005GB-Dn; Mon, 14 Oct 2013 13:45:33 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VViSX-0006RM-IS; Mon, 14 Oct 2013 13:45:21 +0000 Received: from svenfoo.org ([82.94.215.22] helo=mail.zonque.de) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VViSI-0006PB-Uu; Mon, 14 Oct 2013 13:45:08 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.zonque.de (Postfix) with ESMTP id 6D69EC13FF; Mon, 14 Oct 2013 15:44:42 +0200 (CEST) Received: from mail.zonque.de ([127.0.0.1]) by localhost (rambrand.bugwerft.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ie-g_qUeTNa; Mon, 14 Oct 2013 15:44:42 +0200 (CEST) Received: from tamtam.fritz.box (p5DDC4246.dip0.t-ipconnect.de [93.220.66.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.zonque.de (Postfix) with ESMTPSA id 01DF2C1769; Mon, 14 Oct 2013 15:44:41 +0200 (CEST) From: Daniel Mack To: linux@arm.linux.org.uk Subject: [PATCH RFC 1/1] ARM: head-common.S: relocate atags area if necessary Date: Mon, 14 Oct 2013 15:44:22 +0200 Message-Id: <1381758262-31159-2-git-send-email-zonque@gmail.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1381758262-31159-1-git-send-email-zonque@gmail.com> References: <1381758262-31159-1-git-send-email-zonque@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20131014_094507_321895_D1D23B41 X-CRM114-Status: GOOD ( 17.39 ) X-Spam-Score: -0.3 (/) Cc: kexec@lists.infradead.org, neumann@teufel.de, linux-arm-kernel@lists.infradead.org, Daniel Mack X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP If the supplied atags/dtb pointer is located at memory inside the bss section, it will be erased by __mmap_switched. The problem is that the code that sets up the pointer can't know about a safe value unless it examines the kernel's symbol tables, so we should care about that case and relocate the area if necessary. This patch does that from inside __vet_atags. In order to determine the size of the section in dtb cases, it reads the next word after the dtb binary magic, and also has to convert that value from big to CPU endianess. For the atags case, a total size of up to 4k is assumed for now. Signed-off-by: Daniel Mack --- arch/arm/kernel/head-common.S | 58 ++++++++++++++++++++++++++++++++++++++----- 1 file changed, 52 insertions(+), 6 deletions(-) diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S index 47cd974..36f0e7e 100644 --- a/arch/arm/kernel/head-common.S +++ b/arch/arm/kernel/head-common.S @@ -36,12 +36,18 @@ * that the pointer be aligned, in the first 16k of physical RAM and * that the ATAG_CORE marker is first and present. If CONFIG_OF_FLATTREE * is selected, then it will also accept a dtb pointer. Future revisions - * of this function may be more lenient with the physical address and - * may also be able to move the ATAGS block if necessary. + * of this function may be more lenient with the physical address. + * + * It is also checked whether the atags/dtb area is located before the + * end of the kernel's bss section and would hence be overridden by zeros + * later. In that case, the atags area is relocated to the '_end' symbol. + * + * r2 = atags or dtb + * r8 = phys_offset * * Returns: * r2 either valid atags pointer, valid dtb pointer, or zero - * r5, r6 corrupted + * r3, r5 - r7 corrupted */ __vet_atags: tst r2, #0x3 @ aligned? @@ -51,21 +57,61 @@ __vet_atags: #ifdef CONFIG_OF_FLATTREE ldr r6, =OF_DT_MAGIC @ is it a DTB? cmp r5, r6 - beq 2f -#endif - cmp r5, #ATAG_CORE_SIZE @ is first tag ATAG_CORE? + bne 5f + + ldreq r5, [r2, #4] @ fdt total size is at offset 4 ... +#ifndef CONFIG_CPU_BIG_ENDIAN + eor r6, r5, r5, ror #16 @ ... and stored in be32 order + mov r6, r6, lsr #8 + bic r6, r6, #0xff00 + eor r5, r6, r5, ror #8 +#endif /* !CONFIG_CPU_BIG_ENDIAN */ + + add r5, r5, #4 @ align the size to 32bit + bic r5, r5, #3 + b 4f +#endif /* CONFIG_OF_FLATTREE */ + +5: cmp r5, #ATAG_CORE_SIZE @ is first tag ATAG_CORE? cmpne r5, #ATAG_CORE_SIZE_EMPTY bne 1f ldr r5, [r2, #4] ldr r6, =ATAG_CORE cmp r5, r6 + movne r5, #4096 @ FIXME: we should walk the atags and + @ determine the real size. bne 1f +4: adr r3, 6f + ldmia r3!, {r6, r7} + + @ The kernel end address is stored in virtual address space, but we're + @ still in flat mapping. Hence, we have to do virt_to_phys() manually. + subs r6, r6, r7 @ r7 = PAGE_OFFSET + add r6, r6, r8 @ r8 = PHYS_OFFET + + cmp r2, r6 @ is the atags pointer inside the + @ kernel area? + bgt 2f + + mov r3, r6 @ relocate start + add r6, r6, r5 @ relocate end +3: cmp r3, r6 + ldrne fp, [r2], #4 + strne fp, [r3], #4 + bne 3b + + subs r2, r6, r5 @ rewind back to the new + @ atags/dtb image start + 2: mov pc, lr @ atag/dtb pointer is ok 1: mov r2, #0 mov pc, lr ENDPROC(__vet_atags) + .align +6: .long _end @ r6 + .long PAGE_OFFSET @ r7 /* * The following fragment of code is executed with the MMU on in MMU mode,