linux-kernel - Re: [PATCH v4 00/10] Function Granular KASLR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202008061052.DA6F3AA2@keescook>
Date:   Thu, 6 Aug 2020 12:27:50 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Kristen Carlson Accardi <kristen@...ux.intel.com>,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        arjan@...ux.intel.com, x86@...nel.org,
        linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
        rick.p.edgecombe@...el.com
Subject: Re: [PATCH v4 00/10] Function Granular KASLR

On Thu, Aug 06, 2020 at 05:32:58PM +0200, Ingo Molnar wrote:
> * Kristen Carlson Accardi <kristen@...ux.intel.com> wrote:
> > [...]
> > Performance Impact
> > ------------------
> 
> > * Run time
> > The performance impact at run-time of function reordering varies by workload.
> > Using kcbench, a kernel compilation benchmark, the performance of a kernel
> > build with finer grained KASLR was about 1% slower than a kernel with standard
> > KASLR. Analysis with perf showed a slightly higher percentage of 
> > L1-icache-load-misses. Other workloads were examined as well, with varied
> > results. Some workloads performed significantly worse under FGKASLR, while
> > others stayed the same or were mysteriously better. In general, it will
> > depend on the code flow whether or not finer grained KASLR will impact
> > your workload, and how the underlying code was designed. Because the layout
> > changes per boot, each time a system is rebooted the performance of a workload
> > may change.
> 
> I'd guess that the biggest performance impact comes from tearing apart 
> 'groups' of functions that particular workloads are using.
> 
> In that sense it might be worthwile to add a '__kaslr_group' function 
> tag to key functions, which would keep certain performance critical 
> functions next to each other.

We kind of already do this manually for things like the scheduler, etc,
using macros like ".whatever.text", so we might be able to create a more
generalized approach for those. Right now they require a "section" macro
usage and a linker script __start* and __end* marker, etc:

#define SCHED_TEXT						\
                ALIGN_FUNCTION();				\
                __sched_text_start = .;				\
                *(.sched.text)					\
                __sched_text_end = .;

Manually collected each whatever_TEXT define and building out each
__whatever_start, etc is annoying. It'd be really cool to have linker
script have wildcard replacements for build a syntax like this, based
on the presences of matching input sections:

	.%.text : {
		__%_start = .;
		*(.%.text.hot)
		*(.%.text)
		*(.%.text.*)
		*(.%.text.unlikely)
		__%_end = .;
		}

> I'd also suggest allowing the passing in of a boot-time pseudo-random 
> generator seed number, which would allow the creation of a 
> pseudo-randomized but repeatable layout across reboots.

This was present in earlier versions of the series.

-- 
Kees Cook