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

[Ard Biesheuvel]

On 19 February 2016 at 18:34, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 19, 2016 at 03:40:32PM +0100, Ard Biesheuvel wrote:
>> On 19 February 2016 at 15:37, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Fri, Feb 19, 2016 at 03:29:13PM +0100, Ard Biesheuvel wrote:
>> >> 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:
>> >> >>> 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
>> >
>> > Ah, I now realised that it was only working fine for me before merging
>> > the EFI patches to actually do the base randomisation. Once we fully
>> > randomise the load address, we must have relative extable.
>> >
>> > Is your branch updated with the patches needed for arm64 (against
>> > for-next/core)?
>>
>> Yes. I dropped the kallsyms patches, and included only the base and
>> arm64 extable patches, with the UAO issue fixed.
>>
>> https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
>> git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-kaslr-v6
>
> I pushed these patches to the arm64 for-next/kaslr for now, rebased
> against the latest for-next/core branch. There was one commit
> (e9ee71275034 arm64: add support for module PLTs) which inadvertently
> got some extra information in the log but I found it useful, so I kept
> it. If nothing else falls, I'll push them into -next on Monday.
>

OK

> I noticed that we still have MODULES_VADDR around and used in couple of
> places (printing the kernel memory layout during init, debugfs
> kernel_page_tables and KASAN). Shouldn't we use module_alloc_base
> instead?
>

For KASAN, I updated the patches so that the modules are always
allocated in the original module region, to prevent issues with the
zero shadow that backs the vmalloc region.

For the other purposes, it is really a matter of taste. The reserved
region still exists, KASLR or not, so if you omit it, you will have a
hole in the memory map. For the page table dumper, i did not add a
special section for the kernel either.

I'm happy to propose a patch that changes that, once we (you) decide
what you want to see.

-- 
Ard.