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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
