|
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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.