Linux Virtualization - Mar 2020 - [PATCH v11 00/11] x86: PIE support to extend KASLR randomization

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

On Wed, Mar 4, 2020 at 10:45 AM H. Peter Anvin <hpa at zytor.com>
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

On 2020-03-04 11:19, Thomas Garnier wrote:
>>
>> 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.
> 
I know... this was in reference to a comment of Kees'.

	-hpa