[PATCH v6sub1 00/11] arm64: split linear and kernel mappings

[Ard Biesheuvel]

On 19 February 2016 at 15:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 19 February 2016 at 15:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
>>> On 18 February 2016 at 20:38, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>>> > On 18 February 2016 at 19:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>>> >> On 18 February 2016 at 19:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>> >>> On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
>>> >>>> Ard Biesheuvel (11):
>>> >>>>   of/fdt: make memblock minimum physical address arch configurable
>>> >>>>   of/fdt: factor out assignment of initrd_start/initrd_end
>>> >>>>   arm64: prevent potential circular header dependencies in asm/bug.h
>>> >>>>   arm64: add support for ioremap() block mappings
>>> >>>>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>>> >>>>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>> >>>>   arm64: decouple early fixmap init from linear mapping
>>> >>>>   arm64: kvm: deal with kernel symbols outside of linear mapping
>>> >>>>   arm64: move kernel image to base of vmalloc area
>>> >>>>   arm64: defer __va translation of initrd_start and initrd_end
>>> >>>>   arm64: allow kernel Image to be loaded anywhere in physical memory
>>> >>>
>>> >>> I queued this patches (again) for 4.6. I'll wait a few days with the
>>> >>> rest of KASLR until these get a bit more coverage in -next.
>>> >>>
>>> >
>>> > I rebased the remaining patches onto for-next/core, and pushed it here:
>>> > https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
>>> >
>>> > I need to check if everything still works, and if it does, I will send
>>> > them out as v6sub2
>>> > Note that I have included the arm64 extable patch plus its generic
>>> > dependency, and the kallsyms patches as well. We can decide later how
>>> > to proceed with those, but for now, I included them for completeness.
>>>
>>> OK, as it turns out, my arm64/extable patch conflicts with the UAO
>>> patches that are now in for-next/core, not textually, but those
>>> patches add additional absolute extable entries that need to be
>>> updated to relative as well.
>>
>> I noticed this as well while testing KASLR.
>>
>>> So it appears that akpm will need to drop that patch anyway, as he
>>> won't be able to carry an updated version since he does not have the
>>> UAO patches. That means it probably makes even more sense to take
>>> those through the arm64 tree as well (minus the x86 one, which has a
>>> conflict now as well). In fact, perhaps it makes sense to only take
>>> the base patch and the arm64 patch, and I can send the remaining ones
>>> to the various maintainers (or akpm) for v4.7
>>
>> Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
>> sort out the extable patches.
>>
>
> That would still result in breakage once the current version queued by
> akpm hits mainline.

... or in other words, the breakage is already in -next. This is
completely unrelated to the sorting, btw, but due to the difference
between relative/absolute