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

[ard.biesheuvel@linaro.org (Ard Biesheuvel)]

On 8 February 2016 at 17:19, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Feb 08, 2016 at 03:30:47PM +0100, Ard Biesheuvel wrote:
>> On 8 February 2016 at 13:14, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > On Fri, Feb 05, 2016 at 12:42:30PM -0800, Kees Cook wrote:
>> >> On Fri, Feb 5, 2016 at 9:38 AM, Ard Biesheuvel
>> >> <ard.biesheuvel@linaro.org> wrote:
>> >> > On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> >> >> 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?
>> >>
>> >> Traditionally akpm will de-duplicate patches he's carrying that appear
>> >> in another tree. I think it should be okay to carry them in both
>> >> places. (Though I'm CCing akpm just to see if I'm talking crazy.)
>> >
>> > For now, I'll merge this series in the arm64 tree and push it to next:
>> >
>> > http://lkml.kernel.org/r/1452007180-27411-1-git-send-email-ard.biesheuvel at linaro.org
>> >
>> > If there are any objections, I can drop the patches and do the
>> > BUILDTIME_EXTABLE_SORT disabling trick until they end up in mainline.
>>
>> Latest version is here:
>> http://lkml.kernel.org/r/1453892123-17973-1-git-send-email-ard.biesheuvel at linaro.org
>> (only difference is an ack from that Alpha maintainter/supporter to
>> patches #1 and #2)
>
> I applied the acks manually but I'll double-check to make sure I haven't
> missed anything.
>
>> However, the arm64 patch (#6) now conflicts with futex.h in -rc3 after
>> the PAN fix, not sure how to best address that ...
>
> I'll have a look.
>

Note that the fix is trivial, but I don't know who should be carrying
the fix is all