From: Nick Desaulniers <ndesaulniers@google.com>
To: Kees Cook <keescook@chromium.org>
Cc: Russell King <linux@armlinux.org.uk>,
Masahiro Yamada <masahiroy@kernel.org>,
Nathan Chancellor <natechancellor@gmail.com>,
Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Eli Friedman <efriedma@quicinc.com>
Subject: Re: [PATCH v2 1/2] arm/build: Warn on orphan section placement
Date: Fri, 26 Jun 2020 14:36:44 -0700 [thread overview]
Message-ID: <CAKwvOdk-racgq5pxsoGS6Vtifbtrk5fmkmnoLxrQMaOvV0nPWw@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOdmYa6V=W2eupEmHcuF8+479F8XHxm1NAo0s2N=sawbKAw@mail.gmail.com>
On Tue, Jun 23, 2020 at 5:03 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Mon, Jun 22, 2020 at 1:49 PM Kees Cook <keescook@chromium.org> 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 <asm-generic/vmlinux.lds.h>
> >
> > #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
next prev parent reply other threads:[~2020-06-26 21:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 20:49 [PATCH v2 0/2] arm: Warn on orphan section placement Kees Cook
2020-06-22 20:49 ` [PATCH v2 1/2] arm/build: " Kees Cook
2020-06-24 0:03 ` Nick Desaulniers
2020-06-24 19:43 ` Kees Cook
2020-06-26 21:36 ` Nick Desaulniers [this message]
2020-06-26 21:55 ` Kees Cook
2020-06-22 20:49 ` [PATCH v2 2/2] arm/boot: " Kees Cook
2020-06-24 0:08 ` Nick Desaulniers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKwvOdk-racgq5pxsoGS6Vtifbtrk5fmkmnoLxrQMaOvV0nPWw@mail.gmail.com \
--to=ndesaulniers@google.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=efriedma@quicinc.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=masahiroy@kernel.org \
--cc=natechancellor@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).