From patchwork Mon Jul 22 20:26:35 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ben Dooks X-Patchwork-Id: 2831568 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 5E40A9F7D6 for ; Mon, 22 Jul 2013 20:27:19 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 62F81202E9 for ; Mon, 22 Jul 2013 20:27:18 +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 32297202BA for ; Mon, 22 Jul 2013 20:27:17 +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 1V1MhH-00081u-Fr; Mon, 22 Jul 2013 20:27:07 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1V1MhF-0005Q8-A7; Mon, 22 Jul 2013 20:27:05 +0000 Received: from ducie-dc1.codethink.co.uk ([37.128.190.40]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1V1MhC-0005PX-De for linux-arm-kernel@lists.infradead.org; Mon, 22 Jul 2013 20:27:03 +0000 Received: from localhost (localhost [127.0.0.1]) by ducie-dc1.codethink.co.uk (Postfix) with ESMTP id 9B84D46067A; Mon, 22 Jul 2013 21:26:39 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at ducie-dc1.codethink.co.uk Received: from ducie-dc1.codethink.co.uk ([127.0.0.1]) by localhost (ducie-dc1.codethink.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZBLZSSYreks; Mon, 22 Jul 2013 21:26:36 +0100 (BST) Received: from [192.168.24.134] (rainbowdash.dyn.ducie.codethink.co.uk [192.168.24.134]) by ducie-dc1.codethink.co.uk (Postfix) with ESMTPSA id B53FB460592; Mon, 22 Jul 2013 21:26:35 +0100 (BST) Message-ID: <51ED957B.80105@codethink.co.uk> Date: Mon, 22 Jul 2013 21:26:35 +0100 From: Ben Dooks Organization: Codethink Limited. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Nicolas Pitre Subject: Re: [PATCH 4/4] ARM: set --be8 when linking modules References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk> <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk> <20130722170500.GC19639@codeaurora.org> <51ED69CA.3030501@codethink.co.uk> In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130722_162702_563396_C5518DDC X-CRM114-Status: GOOD ( 20.11 ) X-Spam-Score: -3.4 (---) Cc: ian.molton@codethink.co.uk, Stephen Boyd , paul.sherwood@codethink.co.uk, linux-arm-kernel@lists.infradead.org, rob.taylor@codethink.co.uk 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, 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 On 22/07/13 19:53, Nicolas Pitre wrote: > On Mon, 22 Jul 2013, Ben Dooks wrote: > >> On 22/07/13 18:05, Stephen Boyd wrote: >>> On 07/22, Ben Dooks wrote: >>>> To avoid having to make every text section swap the instruction order >>>> of all instructions, make sure modules are built also built with --be8 >>>> (as is the current kernel final link). >>>> >>>> If we do not do this, we would end up having to swap all instructions >>>> when loading a module, instead of just the instructions that we are >>>> applying ELF relocations to. >>>> >>> >>> If someone tries to load a be8 module on a non-be8 kernel will it >>> still work? Or should we add an extra version magic string in >>> asm/module.h to prevent that? >> >> The ELF header changes the EI_DATA field in the ei_ident from >> ELFDATA2LSB to ELFDATA2MSB when compiling so we should be able >> to detect these when loading. >> >> I have not checked to see if the kernel correctly checks for this. >> >> I do not think it currently checks the ei_flags field for the >> EF_ARM_BE8 in ABI 4 and 5. I am not sure if this is really important? > > If the information is already there and easily accessible, then it > should be used. I added this, which seems to actually work unlike my last effort. I do not think it actually gets triggered, the ELF format contains the endian-ness of the system it was built for and therefore fails somewhere else. Senior Engineer Codethink - Providing Genius diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c index d0d1e83..37c8e66 100644 --- a/arch/arm/kernel/elf.c +++ b/arch/arm/kernel/elf.c @@ -34,6 +34,17 @@ int elf_check_arch(const struct elf32_hdr *x) if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP)) return 0; } + + if ((eflags & EF_ARM_EABI_MASK) >= EF_ARM_EABI_VER4) { + bool is_be8 = IS_ENABLED(CONFIG_CPU_ENDIAN_BE8); + + /* do some simple endian-ness verifications */ + if (eflags & EF_ARM_BE8 && !is_be8) + return 0; + if (eflags & EF_ARM_LE8 && is_be8) + return 0; + } + -- Ben Dooks http://www.codethink.co.uk/