[PATCH v5sub2 1/8] arm64: add support for module PLTs

[Ard Biesheuvel]

On 5 February 2016 at 17:00, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 05, 2016 at 04:53:10PM +0100, Ard Biesheuvel wrote:
>> On 5 February 2016 at 16:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
>> >> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>> >> >> This adds support for emitting PLTs at module load time for relative
>> >> >> branches that are out of range. This is a prerequisite for KASLR, which
>> >> >> may place the kernel and the modules anywhere in the vmalloc area,
>> >> >> making it more likely that branch target offsets exceed the maximum
>> >> >> range of +/- 128 MB.
>> >> >
>> >> > Any downside to trying to keep the kernel+modules coupled together so
>> >> > that we avoid the PLT?
>> >>
>> >> First of all, note that it is unlikely that the PLTs are ever required
>> >> in practice, considering that either
>> >> a) the kernel is loaded at the default location right at the base of
>> >> the vmalloc range, and in this case, the module space is reserved for
>> >> modules only, or
>> >> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
>> >> space, and it is unlikely that all VMA space around the kernel happens
>> >> to be given out to non-randomized vmalloc/ioremap allocations
>> >
>> > My worry is that we merge some code that's rarely tested.
>>
>> I understand. But unfortunately, having corner cases that are unlikely
>> but not impossible comes with the territory of randomization.
>>
>> Alternatively, we could take the performance hit if KASLR is in effect
>> and allocate each module completely randomly as well. This way, the
>> code is always exercised (for now), and we can always backpedal later
>> if the performance is measurably worse.
>
> I'm fine with this. You can post it as a separate patch that we can
> easily revert/modify later (like turning it into a config option).
>

OK, I will hack something up