From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Fri, 5 Feb 2016 12:39:56 -0800 Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs In-Reply-To: References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org> <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org> <20160204151303.GB6076@e104818-lin.cambridge.arm.com> <20160205154234.GF6076@e104818-lin.cambridge.arm.com> <20160205160054.GG6076@e104818-lin.cambridge.arm.com> <20160205164648.GH6076@e104818-lin.cambridge.arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Feb 5, 2016 at 8:54 AM, Ard Biesheuvel wrote: > On 5 February 2016 at 17:46, Catalin Marinas wrote: >> On Fri, Feb 05, 2016 at 05:20:14PM +0100, Ard Biesheuvel wrote: >>> On 5 February 2016 at 17:00, Catalin Marinas wrote: >>> > On Fri, Feb 05, 2016 at 04:53:10PM +0100, Ard Biesheuvel wrote: >>> >> On 5 February 2016 at 16:42, Catalin Marinas wrote: >>> >> > On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote: >>> >> >> On 4 February 2016 at 16:13, Catalin Marinas 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