From patchwork Fri Oct 18 16:12:56 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Mack X-Patchwork-Id: 3068921 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 F0B61BF924 for ; Fri, 18 Oct 2013 16:14:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BFD6D204E1 for ; Fri, 18 Oct 2013 16:14:38 +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 72CAE203E9 for ; Fri, 18 Oct 2013 16:14:37 +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 1VXCge-0001Ux-St; Fri, 18 Oct 2013 16:14:06 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VXCgC-0000j6-Bm; Fri, 18 Oct 2013 16:13:36 +0000 Received: from mail-ee0-x231.google.com ([2a00:1450:4013:c00::231]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VXCg8-0000hJ-4F; Fri, 18 Oct 2013 16:13:33 +0000 Received: by mail-ee0-f49.google.com with SMTP id d41so2115582eek.22 for ; Fri, 18 Oct 2013 09:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=Bf1LPk8lMZPsbKK1fRCUpZdc5S06kYd/uwVUiKcjh9E=; b=mSmMUIx/5FRezBLmCmE1y1Oo7cBZZ3omO4UEjCSEon/DstGEfc4thmk7wBeH4FPwPE MYIWw6dgVHkZg/tbEfZdcVShITEfTs5g5IXucw/O5bTD6mt2FBBN3lD92QB0xsD180dZ v40v1O2/LrAndHUJlMKqjx3ekPfJ1HzJdIEEA2fO52p5cruGlzC54cOChm7RTZXmmb8P 9nv765CF8dqfaT5MQO6zabINYdPfSSuECIGlfiJxyKWHRg+XCeYMbZLM1QVDJE5s2bak hxdHRf8C+DYtzBVEffm8T2lvMLyEQonciHOvHQgR4l5UQ4UY+oVo86etHMDXwDSXt+KB Rnhw== X-Received: by 10.14.210.8 with SMTP id t8mr5510227eeo.39.1382112789821; Fri, 18 Oct 2013 09:13:09 -0700 (PDT) Received: from localhost.localdomain (business-178-015-253-194.static.arcor-ip.net. [178.15.253.194]) by mx.google.com with ESMTPSA id b42sm6263603eem.9.2013.10.18.09.13.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Oct 2013 09:13:09 -0700 (PDT) From: Daniel Mack To: linux@arm.linux.org.uk Subject: [PATCH v2] ARM: head-common.S: relocate atags area if necessary Date: Fri, 18 Oct 2013 18:12:56 +0200 Message-Id: <1382112776-20300-1-git-send-email-zonque@gmail.com> X-Mailer: git-send-email 1.8.3.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20131018_121332_340540_8BAE1345 X-CRM114-Status: GOOD ( 17.94 ) X-Spam-Score: -2.0 (--) 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.5 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, 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 --- v2: move the relocation destination to '.end + atags_size' instead of '.end', because the atags area could actually overlap the .end pointer, which then would cause the relocation to fail. 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..5434767 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 + + add r3, r6, r5 @ relocate start = .end + length + add r6, r3, r5 @ relocate end = .end + length * 2 +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,