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

[Kees Cook]

On Fri, Feb 5, 2016 at 8:54 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> On 5 February 2016 at 17:46, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Fri, Feb 05, 2016 at 05:20:14PM +0100, Ard Biesheuvel wrote:
>>> 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
>>
>> If it's simpler, you can just add a config option but defaulting to the
>> full vmalloc space for modules.
>>
>
> What would be the simplest is to randomize the 128 MB module region as
> a whole, and either put it close to the kernel (which is what I am
> doing now), or put it at a random offset inside the vmalloc space, in
> which case all branches will be resolved via PLTs. My suggestion to
> randomize each module_alloc() call separately is actually not that
> straight-forward.

FWIW, it also turns out that this ends up not being very random in a
limited address range. It ends up turning into a greedy-allocation
hole-filling routine, and for a given system ends up being pretty
deterministic.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security