From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D684C433E0 for ; Fri, 26 Jun 2020 21:37:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4EFCD2137B for ; Fri, 26 Jun 2020 21:37:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PuYNfoCy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725861AbgFZVg6 (ORCPT ); Fri, 26 Jun 2020 17:36:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725816AbgFZVg5 (ORCPT ); Fri, 26 Jun 2020 17:36:57 -0400 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FE16C03E979 for ; Fri, 26 Jun 2020 14:36:57 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id e9so5483768pgo.9 for ; Fri, 26 Jun 2020 14:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nOBEqR855rhbveUnTuLRVA8ObPjWG2Dhr4Uq2zMSwAY=; b=PuYNfoCyPSJ5Ee12cr1CtUbfE7ZlRGryAVARIshAUVXzmAnVWRFHzikYNNfSyo7a7F a06g/eRMdwxj9OXD7QRHNxSF7eKxvk1j1lPH9PmdRDDg6kx4ZLd+rlLkMX+stfkvFRSo 3uYlvf2dcAbiq0b0Zur+XdSPJAOs7pyrko97x1g/OZZE5SAbKoR5//4HR0kMgybCUEcJ qH5fO1qNpQUu5shtcqTXZ6i3vFopLDbDxc6vz9okSZ89qSoU9m5SXNS+uZg1J+VAhXel mr1ancCaFIkK6ML+TUbpPKLFTOYu+NWJSaza3sWtRul6uvMdRWqHryQVHiXRHQ42JOKB D6sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nOBEqR855rhbveUnTuLRVA8ObPjWG2Dhr4Uq2zMSwAY=; b=EZfWuCI78RcWgnsMLvUk9vxb+R1tRznRke6aXUDQZ4fKZnbQ/q0lADejGSB1C8z8tD riY8GmTwi6jFMuUoi4ilTtpBw3HuAj/coyuOeFe9SFrl2OJVTYq99YvC1GQSUz7239R7 ctvp6wLYFBCFReWAm2p5Vxu9sx0LIzo8mH1VwcRGAC182eU2x7Lmvziv172nFg7fwvZH jYVLYZ1UvjkI6vmMrPjXiYB1GZ/AONq9sD0ztfCcIRM5GVa67/9sWvhudpsQl6QbTu5w /2pmZkyo6kDiEqL43A3CdMe5Hs/8bdGTPsg1ZNNYQ92YE4X1xoJtrItyTZn2tQwKN1T1 zHjA== X-Gm-Message-State: AOAM5338ZZXlrOTvZBNXSNfVWJ8Y+qyF8c/mQ5gbFzF8fY577s/HhZnt Mh6jYQW3cCqIWBVCEg4GUUI9WhAGCAr+Tu9UPgk7NQ== X-Google-Smtp-Source: ABdhPJzhTb+JgbH2pUdHbU3Lcn5mzANDYeWl9ZkkpeEFXuFi9qIgBYbbGiM0JwDKX1RI84GCkYbTlow0BnrH3GGtPow= X-Received: by 2002:a62:7e95:: with SMTP id z143mr4569412pfc.108.1593207416783; Fri, 26 Jun 2020 14:36:56 -0700 (PDT) MIME-Version: 1.0 References: <20200622204915.2987555-1-keescook@chromium.org> <20200622204915.2987555-2-keescook@chromium.org> In-Reply-To: From: Nick Desaulniers Date: Fri, 26 Jun 2020 14:36:44 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] arm/build: Warn on orphan section placement To: Kees Cook Cc: Russell King , Masahiro Yamada , Nathan Chancellor , Will Deacon , Ard Biesheuvel , Arnd Bergmann , Linux ARM , LKML , Eli Friedman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 23, 2020 at 5:03 PM Nick Desaulniers wrote: > > On Mon, Jun 22, 2020 at 1:49 PM Kees Cook wrote: > > > > --- a/arch/arm/kernel/vmlinux.lds.h > > +++ b/arch/arm/include/asm/vmlinux.lds.h > > @@ -1,4 +1,5 @@ > > /* SPDX-License-Identifier: GPL-2.0 */ > > +#include > > > > #ifdef CONFIG_HOTPLUG_CPU > > #define ARM_CPU_DISCARD(x) > > @@ -37,6 +38,13 @@ > > *(.idmap.text) \ > > __idmap_text_end = .; \ > > > > +#define ARM_COMMON_DISCARD \ > > + *(.ARM.attributes) \ > > I could have sworn that someone (Eli?) once told me that this section > (.ARM.attributes) is used for disambiguating which ARM version or > which optional extensions were used when compiling, and that without > this section, one would not be able to disassemble 32b ARM precisely. > If that's the case, we might not want to discard it? Yep, looks like ELFObjectFileBase::getARMFeatures() in llvm/lib/Object/ELFObjectFile.cpp does exactly that and more. https://github.com/llvm/llvm-project/blob/8808574e7438c8768b78ae7dd0f029385c6df01d/llvm/lib/Object/ELFObjectFile.cpp#L359-L441 https://github.com/llvm/llvm-project/blob/8808574e7438c8768b78ae7dd0f029385c6df01d/llvm/lib/Object/ELFObjectFile.cpp#L159-L287 As a test, let's do: $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 defconfig (so armv7) $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 (then pick any random object file) $ llvm-readelf -S arch/arm/kernel/bugs.o | grep attri [15] .ARM.attributes ARM_ATTRIBUTES 00000000 0000f7 000037 00 0 0 1 $ llvm-readelf --arch-specific arch/arm/kernel/bugs.o | grep -A 2 CPU_arch TagName: CPU_arch Description: ARM v7 } And let's see if this actually has a difference on the disassembly. $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 (full build, since we're talking about linker script changes for vmlinux) $ llvm-objdump -d vmlinux > prepatch.txt (apply your patch) $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 clean $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 $ llvm-objdump -d vmlinux > postpatch.txt $ diff -u prepatch.txt postpatch.txt | less No difference. Eh. Checking again with arm-linux-gnueabihf-objdump, it seems some constants are slightly different for `movw`'s though. Not sure what's that about. If I enable CONFIG_THUMB2_KERNEL=y, is where things become interesting. llvm-objdump produces wildly different disassembly before vs after removing .ARM.attributes. There's also lots of decode errors in the disassembly. Repeating the thumb2 test with GNU objdump, I only see slight differences in constants values for operands to `movw`. So it looks like GNU objdump doesn't rely on .ARM.attributes to disambiguate between ARM vs THUMB2 instructions like llvm-objdump does. We can probably improve llvm-objdump, but I'd rather not discard this section for now. (also, I didn't test armv6, v5, etc, but those might be interesting tests, too, should we want to discard this section. Also, I think we can explicitly specify --triple=thumbv7-linux-gnueabihf to llvm-objdump, but I'd prefer it if my disassembler did the work for me, since I'm lazy) (oh man, the bytes are printed with different endianness between arm-linux-gnueabihf-objdump and llvm-objdump...guessing that's a bug in llvm). -- Thanks, ~Nick Desaulniers From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F55EC433DF for ; Fri, 26 Jun 2020 21:38:40 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5B08C2088E for ; Fri, 26 Jun 2020 21:38:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rJiCkhUA"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="PuYNfoCy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5B08C2088E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/XRmDGl4eR69u9JuOmXi7vCQRE5qcAFHOJlByQg+zJc=; b=rJiCkhUAaDZ0PNQDV19yKyMpP qw1/TdhmgesK9Pbi48XDKoa2ktE15tzHLxbii3u/usuxACUQA901VMW8JRnA49P1SXQFGhWv47p6T eWYRMvAbU30pOkAzVYkIlX39NuBM3JAO7c3EF28fcTaLHPJBpzJ93sS1Xx2FWP0KELdS3ZMp3l3rP xDfOjZsiSrzewHj5+x7HuMecFwBSFSBtRT2Ox7cZdkOqwdtWWQboXDraAJDBOUobDUGjUL6fLLjVO TwLboUkZQWdB3yc3AGHAkYre98qkNSTZ9p/lDQX1i65/mwdFonyjKM/M6Hw9InFBhoHS3QJ8SmIJs pFSr5N4iQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jow1t-0004fJ-Ne; Fri, 26 Jun 2020 21:37:01 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jow1r-0004ef-1x for linux-arm-kernel@lists.infradead.org; Fri, 26 Jun 2020 21:37:00 +0000 Received: by mail-pg1-x542.google.com with SMTP id f3so5507996pgr.2 for ; Fri, 26 Jun 2020 14:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nOBEqR855rhbveUnTuLRVA8ObPjWG2Dhr4Uq2zMSwAY=; b=PuYNfoCyPSJ5Ee12cr1CtUbfE7ZlRGryAVARIshAUVXzmAnVWRFHzikYNNfSyo7a7F a06g/eRMdwxj9OXD7QRHNxSF7eKxvk1j1lPH9PmdRDDg6kx4ZLd+rlLkMX+stfkvFRSo 3uYlvf2dcAbiq0b0Zur+XdSPJAOs7pyrko97x1g/OZZE5SAbKoR5//4HR0kMgybCUEcJ qH5fO1qNpQUu5shtcqTXZ6i3vFopLDbDxc6vz9okSZ89qSoU9m5SXNS+uZg1J+VAhXel mr1ancCaFIkK6ML+TUbpPKLFTOYu+NWJSaza3sWtRul6uvMdRWqHryQVHiXRHQ42JOKB D6sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nOBEqR855rhbveUnTuLRVA8ObPjWG2Dhr4Uq2zMSwAY=; b=W6KzDVgHKfFbJfGyOcFz69saz0pi7wjRBTvspfp4nodlCVVsSufwPSH0cOgOqhdW/l X6XEZdp8UZDqN56uEBiuN9yon/rcfKD7VkxG+BpN+hlLbb9nSsDD/6DNhn5ssUrcpz50 fqqgC6ccITCj76rw10dezOggYDo/F3vQpTeWqrnJCD7zZr7BeQTFkgs2KbOoBT6KO/zy c241CMtCQO0lSmLV4GX5agTTMqJAgiIZeUjxdrUsEPkGUEwn5xE9yceagVRgL6aA+yO8 Ii6jNiDY/JtK56j2wfRElne9Ftp8fJk9Pzp0bvleoldsfMywu1pTmJxaEA44boQBNlqv 5/YA== X-Gm-Message-State: AOAM531q4YNNbRBpTUxUljKi15LEtVbxTedcHPYBIkr9Qz/AoEvsoefg gS29OuywQQ2WJFv7MhU2aQMFEgxFsXjUkvhIPLuyyzDDCO4= X-Google-Smtp-Source: ABdhPJzhTb+JgbH2pUdHbU3Lcn5mzANDYeWl9ZkkpeEFXuFi9qIgBYbbGiM0JwDKX1RI84GCkYbTlow0BnrH3GGtPow= X-Received: by 2002:a62:7e95:: with SMTP id z143mr4569412pfc.108.1593207416783; Fri, 26 Jun 2020 14:36:56 -0700 (PDT) MIME-Version: 1.0 References: <20200622204915.2987555-1-keescook@chromium.org> <20200622204915.2987555-2-keescook@chromium.org> In-Reply-To: From: Nick Desaulniers Date: Fri, 26 Jun 2020 14:36:44 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] arm/build: Warn on orphan section placement To: Kees Cook X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Arnd Bergmann , Masahiro Yamada , Eli Friedman , Russell King , LKML , Nathan Chancellor , Will Deacon , Ard Biesheuvel , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 23, 2020 at 5:03 PM Nick Desaulniers wrote: > > On Mon, Jun 22, 2020 at 1:49 PM Kees Cook wrote: > > > > --- a/arch/arm/kernel/vmlinux.lds.h > > +++ b/arch/arm/include/asm/vmlinux.lds.h > > @@ -1,4 +1,5 @@ > > /* SPDX-License-Identifier: GPL-2.0 */ > > +#include > > > > #ifdef CONFIG_HOTPLUG_CPU > > #define ARM_CPU_DISCARD(x) > > @@ -37,6 +38,13 @@ > > *(.idmap.text) \ > > __idmap_text_end = .; \ > > > > +#define ARM_COMMON_DISCARD \ > > + *(.ARM.attributes) \ > > I could have sworn that someone (Eli?) once told me that this section > (.ARM.attributes) is used for disambiguating which ARM version or > which optional extensions were used when compiling, and that without > this section, one would not be able to disassemble 32b ARM precisely. > If that's the case, we might not want to discard it? Yep, looks like ELFObjectFileBase::getARMFeatures() in llvm/lib/Object/ELFObjectFile.cpp does exactly that and more. https://github.com/llvm/llvm-project/blob/8808574e7438c8768b78ae7dd0f029385c6df01d/llvm/lib/Object/ELFObjectFile.cpp#L359-L441 https://github.com/llvm/llvm-project/blob/8808574e7438c8768b78ae7dd0f029385c6df01d/llvm/lib/Object/ELFObjectFile.cpp#L159-L287 As a test, let's do: $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 defconfig (so armv7) $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 (then pick any random object file) $ llvm-readelf -S arch/arm/kernel/bugs.o | grep attri [15] .ARM.attributes ARM_ATTRIBUTES 00000000 0000f7 000037 00 0 0 1 $ llvm-readelf --arch-specific arch/arm/kernel/bugs.o | grep -A 2 CPU_arch TagName: CPU_arch Description: ARM v7 } And let's see if this actually has a difference on the disassembly. $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 (full build, since we're talking about linker script changes for vmlinux) $ llvm-objdump -d vmlinux > prepatch.txt (apply your patch) $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 clean $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make LLVM=1 -j71 $ llvm-objdump -d vmlinux > postpatch.txt $ diff -u prepatch.txt postpatch.txt | less No difference. Eh. Checking again with arm-linux-gnueabihf-objdump, it seems some constants are slightly different for `movw`'s though. Not sure what's that about. If I enable CONFIG_THUMB2_KERNEL=y, is where things become interesting. llvm-objdump produces wildly different disassembly before vs after removing .ARM.attributes. There's also lots of decode errors in the disassembly. Repeating the thumb2 test with GNU objdump, I only see slight differences in constants values for operands to `movw`. So it looks like GNU objdump doesn't rely on .ARM.attributes to disambiguate between ARM vs THUMB2 instructions like llvm-objdump does. We can probably improve llvm-objdump, but I'd rather not discard this section for now. (also, I didn't test armv6, v5, etc, but those might be interesting tests, too, should we want to discard this section. Also, I think we can explicitly specify --triple=thumbv7-linux-gnueabihf to llvm-objdump, but I'd prefer it if my disassembler did the work for me, since I'm lazy) (oh man, the bytes are printed with different endianness between arm-linux-gnueabihf-objdump and llvm-objdump...guessing that's a bug in llvm). -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel