[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Feb 2020 11:30:55 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Kristen Carlson Accardi <kristen@...ux.intel.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
arjan@...ux.intel.com, keescook@...omium.org,
rick.p.edgecombe@...el.com, x86@...nel.org,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [RFC PATCH 05/11] x86: Makefile: Add build and config option for
CONFIG_FG_KASLR
On Wed, Feb 05, 2020 at 02:39:44PM -0800, Kristen Carlson Accardi wrote:
> Allow user to select CONFIG_FG_KASLR if dependencies are met. Change
> the make file to build with -ffunction-sections if CONFIG_FG_KASLR
>
> Signed-off-by: Kristen Carlson Accardi <kristen@...ux.intel.com>
> ---
> Makefile | 4 ++++
> arch/x86/Kconfig | 13 +++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index c50ef91f6136..41438a921666 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -846,6 +846,10 @@ ifdef CONFIG_LIVEPATCH
> KBUILD_CFLAGS += $(call cc-option, -flive-patching=inline-clone)
> endif
>
> +ifdef CONFIG_FG_KASLR
> +KBUILD_CFLAGS += -ffunction-sections
> +endif
The GCC manual has:
-ffunction-sections
-fdata-sections
Place each function or data item into its own section in the output
file if the target supports arbitrary sections. The name of the
function or the name of the data item determines the section’s name
in the output file.
Use these options on systems where the linker can perform
optimizations to improve locality of reference in the instruction
space. Most systems using the ELF object format have linkers with
such optimizations. On AIX, the linker rearranges sections (CSECTs)
based on the call graph. The performance impact varies.
Together with a linker garbage collection (linker --gc-sections
option) these options may lead to smaller statically-linked
executables (after stripping).
On ELF/DWARF systems these options do not degenerate the quality of
the debug information. There could be issues with other object
files/debug info formats.
Only use these options when there are significant benefits from
doing so. When you specify these options, the assembler and linker
create larger object and executable files and are also slower. These
options affect code generation. They prevent optimizations by the
compiler and assembler using relative locations inside a translation
unit since the locations are unknown until link time. An example of
such an optimization is relaxing calls to short call instructions.
In particular:
"They prevent optimizations by the compiler and assembler using
relative locations inside a translation unit since the locations are
unknown until link time."
I suppose in practise this only means tail-calls are affected and will
no longer use JMP.d8. Or are more things affected?
(Also, should not the next patch come before this one?)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
