diff mbox

[v5sub2,0/8] arm64: implement virtual KASLR

Message ID 20160205174649.GK6076@e104818-lin.cambridge.arm.com
State New
Headers show

Commit Message

Catalin Marinas Feb. 5, 2016, 5:46 p.m. UTC 
On Fri, Feb 05, 2016 at 06:38:33PM +0100, Ard Biesheuvel wrote:
> On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas@arm.com> wrote:

> > On Mon, Feb 01, 2016 at 02:35:03PM +0100, Ard Biesheuvel wrote:

> >> On 1 February 2016 at 14:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> >> > At the request of Catalin, this series has been split off from my series

> >> > 'arm64: implement support for KASLR v4' [1]. This sub-series deals with

> >> > creating a relocatable binary, and randomizing the virtual placement of

> >> > the kernel itself, the modules and the linear region based on entropy

> >> > supplied by the bootloader in the /chosen/kaslr-seed DT property.

> >> >

> >> > Changes since v4:

> >> > - add randomization of the linear region, i.e., if the linear region is

> >> >   substantially larger than the space spanned by RAM, the mapping of RAM

> >> >   is moved to a random offset inside the linear region.

> >> > - dropped the CRC check in kaslr_early_init(), since the only code that may

> >> >   modify .data through __fixmap_remap_fdt() is instrumentation that should

> >> >   deal with that correctly (For instance, the branch profiling records taken

> >> >   branches in structs allocated in .data, and these counts will not be reset

> >> >   to 0 between the first and the second call to __mmap_switched())

> >> > - add Mark's ack to patch #4

> >> >

> >>

> >> NOTE: I have omitted the relative kallsyms and relative extable

> >> patches, since they already queued in akpm's tree. However, while the

> >> kallsyms patch is merely an optimization, the extable patches are in

> >> fact required for correct operation, since the build time sorting does

> >> not work on absolute extables (this is due to the fact that the

> >> resolution of the relocations is deferred until runtime, and so the

> >> extable addresses are all zero at sorting time)

> >>

> >> http://ozlabs.org/~akpm/mmotm/broken-out/extable-add-support-for-relative-extables-to-search-and-sort-routines.patch

> >> http://ozlabs.org/~akpm/mmotm/broken-out/arm64-switch-to-relative-exception-tables.patch

> >

> > I'm still trying to get my head around how we merge those. Since I

> > assume akpm will push them during the merging window, part of your code

> > cannot be tested before.

> 

> Actually, my original idea was for akpm to take them as a late merge

> after rebasing to -rc1, since they touch a variety of architectures,

> but I am not sure if that came across.

> 

> You could always take the series through your tree instead, I guess?


They all have acks from maintainers, so that's an option.

> > Can we deselect CONFIG_BUILDTIME_EXTABLE_SORT temporarily while we use

> > absolute extable addresses? We patch them at boot-time and sort them

> > at run-time. Once the above patches go in, we can revert to build-time

> > extable sorting.

> 

> I suppose that would be possible, but I simply haven't tried. I

> noticed that ppc does not use build time extable sorting, that is why

> they don't need to scripts/extable patch while they do use PIE

> binaries.


I did a quick check with:


and it seems that extable entries end up in the relocation symbols but I
haven't fully checked the patching/sorting yet (it will probably be on
Monday).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff mbox

Patch

--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -22,7 +22,7 @@  config ARM64
 	select ARM_GIC_V3
 	select ARM_GIC_V3_ITS if PCI_MSI
 	select ARM_PSCI_FW
-	select BUILDTIME_EXTABLE_SORT
+	select BUILDTIME_EXTABLE_SORT if !RELOCATABLE
 	select CLONE_BACKWARDS
 	select COMMON_CLK
 	select CPU_PM if (SUSPEND || CPU_IDLE)