[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160108124055.GD3097@leverpostej>
Date: Fri, 8 Jan 2016 12:40:56 +0000
From: Mark Rutland <mark.rutland@....com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
kernel-hardening@...ts.openwall.com,
Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>,
Leif Lindholm <leif.lindholm@...aro.org>,
Kees Cook <keescook@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Stuart Yoder <stuart.yoder@...escale.com>,
Sharma Bhupesh <bhupesh.sharma@...escale.com>,
Arnd Bergmann <arnd@...db.de>,
Marc Zyngier <marc.zyngier@....com>,
Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v2 12/13] arm64: add support for relocatable kernel
On Fri, Jan 08, 2016 at 01:38:54PM +0100, Ard Biesheuvel wrote:
> On 8 January 2016 at 13:36, Mark Rutland <mark.rutland@....com> wrote:
> > On Wed, Dec 30, 2015 at 04:26:11PM +0100, Ard Biesheuvel wrote:
> >> +
> >> + /*
> >> + * Iterate over each entry in the relocation table, and apply the
> >> + * relocations in place.
> >> + */
> >> + adr_l x8, __dynsym_start // start of symbol table
> >> + adr_l x9, __reloc_start // start of reloc table
> >> + adr_l x10, __reloc_end // end of reloc table
> >> +
> >> +0: cmp x9, x10
> >> + b.hs 2f
> >> + ldp x11, x12, [x9], #24
> >> + ldr x13, [x9, #-8]
> >> + cmp w12, #R_AARCH64_RELATIVE
> >> + b.ne 1f
> >> + add x13, x13, x23 // relocate
> >> + str x13, [x11, x23]
> >> + b 0b
> >> +
> >> +1: cmp w12, #R_AARCH64_ABS64
> >> + b.ne 0b
> >> + add x12, x12, x12, lsl #1 // symtab offset: 24x top word
> >> + add x12, x8, x12, lsr #(32 - 3) // ... shifted into bottom word
> >> + ldrsh w14, [x12, #6] // Elf64_Sym::st_shndx
> >> + ldr x15, [x12, #8] // Elf64_Sym::st_value
> >> + cmp w14, #-0xf // SHN_ABS (0xfff1) ?
> >> + add x14, x15, x23 // relocate
> >> + csel x15, x14, x15, ne
> >> + add x15, x13, x15
> >> + str x15, [x11, x23]
> >> + b 0b
> >
> > We need to clean each of these relocated instructions to the PoU to be
> > visible for I-cache fetches.
> >
> > As this is normal-cacheable we can post the maintenance with a DC CVAU
> > immediately after the store (no barriers necessary), and rely on the DSB
> > at 2f to complete all of those.
> >
>
> Dynamic relocations never apply to instructions, so i don't think that
> is necessary here.
Ah, yes. I was being thick. Sorry for the noise!
Thanks,
Mark.
Powered by blists - more mailing lists