On Wed, Mar 4, 2020 at 10:45 AM H. Peter Anvin <hpa@xxxxxxxxx> wrote: > > 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? I have never seen a significant performance impact. Performance and size is better on more recent versions of gcc as it has better generation of PIE code (for example generation of switches). > > > > 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. I agree that it would add GOT references and I can explore that more in terms of performance impact and size. This patchset makes the GOT readonly too so I don't think the attack vector applies. > > The huge memory model, required for arbitrary placement, has a very > significant performance impact. I assume you mean mcmodel=large, it doesn't use it. It uses -fPIE and removes -mcmodel=kernel. It favors relative references whenever possible. > > The assembly code is *very* different across memory models. > > -hpa
