Messages in this thread | | | Subject | Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization | From | "H. Peter Anvin" <> | Date | Wed, 4 Mar 2020 10:44:52 -0800 |
| |
On 2020-03-04 10:21, Kees Cook wrote: > On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote: >> But at what cost; it does unspeakable ugly to the asm. And didn't a >> kernel compiled with the extended PIE range produce a measurably slower >> kernel due to all the ugly? > > Was that true? I thought the final results were a wash and that earlier > benchmarks weren't accurate for some reason? I can't find the thread > now. Thomas, do you have numbers on that? > > BTW, I totally agree that fgkaslr is the way to go in the future. I > am mostly arguing for this under the assumption that it doesn't > have meaningful performance impact and that it gains the kernel some > flexibility in the kinds of things it can do in the future. If the former > is not true, then I'd agree, the benefit needs to be more clear. >
"Making the assembly really ugly" by itself is a reason not to do it, in my Not So Humble Opinion[TM]; but the reason the kernel and small memory models exist in the first place is because there is a nonzero performance impact of the small-PIC memory model. Having modules in separate regions would further add the cost of a GOT references all over the place (PLT is optional, useless and deprecated for eager binding) *plus* might introduce at least one new vector of attack: overwrite a random GOT slot, and just wait until it gets hit by whatever code path it happens to be in; the exact code path doesn't matter. From an kASLR perspective this is *very* bad, since you only need to guess the general region of a GOT rather than an exact address.
The huge memory model, required for arbitrary placement, has a very significant performance impact.
The assembly code is *very* different across memory models.
-hpa
| |