| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 5 Dec 2018 12:45:19 -0700
From: Nathan Chancellor <natechancellor@...il.com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Arnd Bergmann <arnd@...db.de>,
Russell King <linux@...linux.org.uk>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Stefan Agner <stefan@...er.ch>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 05, 2018 at 07:39:55PM +0100, Ard Biesheuvel wrote:
> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor <natechancellor@...il.com> wrote:
> >
> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > > (+ Arnd)
> > >
> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor <natechancellor@...il.com> wrote:
> > > >
> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor <natechancellor@...il.com> wrote:
> > > > > >
> > > > > > This flag is not supported by lld:
> > > > > >
> > > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > > >
> > > > > > Signed-off-by: Nathan Chancellor <natechancellor@...il.com>
> > > > >
> > > > > Hi Nate,
> > > > >
> > > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > > veneers if you build kernels that are bigger than the typical range of
> > > > > a relative branch?
> > > > >
> > > >
> > > > Hi Ard,
> > > >
> > > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > > flag and I wasn't quite sure what to make of it for lld. What
> > > > configuration would I use to verify and what would I check for?
> > > >
> > >
> > > Try building allyesconfig, and check the resulting binary for veneers
> > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > > them). These veneers should not take the [virtual] address of the
> > > branch target directly, but take a PC relative offset (as in the
> > > example in the commit log of that patch you are referring to)
> > >
> >
> > Alright, compiling with allyesconfig is a little rough at the moment
> > (bug reports I will file in due time) but I was able to do it. Here's
> > the disassembly specifically for the functions you had in your commit,
> > my assembly knowledge is pretty much non-existent unfortunately so I am
> > not sure what to make of it (it doesn't look like there is a virtual
> > address for pc in that mix?). I am happy to provide any more information
> > that is needed.
> >
> > c03030cc <__enable_mmu>:
> > c03030cc: e3c00002 bic r0, r0, #2
> > c03030d0: e3c00b02 bic r0, r0, #2048 ; 0x800
> > c03030d4: e3c00a01 bic r0, r0, #4096 ; 0x1000
> > c03030d8: e3a05051 mov r5, #81 ; 0x51
> > c03030dc: ee035f10 mcr 15, 0, r5, cr3, cr0, {0}
> > c03030e0: ee024f10 mcr 15, 0, r4, cr2, cr0, {0}
> > c03030e4: eafff3c5 b c0300000 <__turn_mmu_on>
> > c03030e8: e320f000 nop {0}
> > c03030ec: e320f000 nop {0}
> > c03030f0: e320f000 nop {0}
> > c03030f4: e320f000 nop {0}
> > c03030f8: e320f000 nop {0}
> > c03030fc: e320f000 nop {0}
> >
> > c0300000 <__turn_mmu_on>:
> > c0300000: e1a00000 nop ; (mov r0, r0)
> > c0300004: ee070f95 mcr 15, 0, r0, cr7, cr5, {4}
> > c0300008: ee010f10 mcr 15, 0, r0, cr1, cr0, {0}
> > c030000c: ee103f10 mrc 15, 0, r3, cr0, cr0, {0}
> > c0300010: ee070f95 mcr 15, 0, r0, cr7, cr5, {4}
> > c0300014: e1a03003 mov r3, r3
> > c0300018: e1a0300d mov r3, sp
> > c030001c: e1a0f003 mov pc, r3
> >
>
> Thanks Nate.
>
> So these functions no longer appear to reside far away from each
> other, so there no veneer has been emitted.
>
> What we're looking for are veneers, i.e., snippets inserted by the
> linker that serve as a trampoline so a branch target that is far away
> can be reached.
>
> If no symbols exist with 'veneer' in their name *, it might make sense
> to rebuild the kernel as Thumb2, which has a branching range of only 8
> MB (as opposed to 16 MB for ARM mode)
>
> * I have no idea whether lld names its veneers like this, or even at all
Thanks Ard, I understand now, I appreciate that.
I compiled with CONFIG_THUMB2_KERNEL (config attached) and I am still
not seeing any veneers or thunks as Peter said they would be called for
lld in the LLVM bug report linked earlier in the thread. Peter did note
that the branch ranges were 32MB and 16MB for ARM and Thumb2
respectively, which could be playing into this.
c03028d0 <__enable_mmu>:
c03028d0: f020 0002 bic.w r0, r0, #2
c03028d4: f420 6000 bic.w r0, r0, #2048 ; 0x800
c03028d8: f420 5080 bic.w r0, r0, #4096 ; 0x1000
c03028dc: f04f 0551 mov.w r5, #81 ; 0x51
c03028e0: ee03 5f10 mcr 15, 0, r5, cr3, cr0, {0}
c03028e4: ee02 4f10 mcr 15, 0, r4, cr2, cr0, {0}
c03028e8: f7fd bb8a b.w c0300000 <__turn_mmu_on>
c03028ec: f3af 8000 nop.w
c03028f0: f3af 8000 nop.w
c03028f4: f3af 8000 nop.w
c03028f8: f3af 8000 nop.w
c03028fc: f3af 8000 nop.w
c0300000 <__turn_mmu_on>:
c0300000: 4600 mov r0, r0
c0300002: f3bf 8f6f isb sy
c0300006: ee01 0f10 mcr 15, 0, r0, cr1, cr0, {0}
c030000a: ee10 3f10 mrc 15, 0, r3, cr0, cr0, {0}
c030000e: f3bf 8f6f isb sy
c0300012: 461b mov r3, r3
c0300014: 466b mov r3, sp
c0300016: 469f mov pc, r3
Thanks for all the insight you've given!
Nathan
View attachment ".config" of type "text/plain" (279535 bytes)
Powered by blists - more mailing lists