Function Granular KASLR
Subsystems (6)
v5 cover Function Granular KASLR
Function Granular Kernel Address Space Layout Randomization (fgkaslr)
---------------------------------------------------------------------
This patch set is an implementation of finer grained kernel address space randomization. It rearranges your kernel code at load time
on a per-function level granularity, with only around a second added to boot time.
Changes in v5:
--------------
* fixed a bug in the code which increases boot heap size for CONFIG_FG_KASLR which prevented the boot heap from being increased for CONFIG_FG_KASLR when using bzip2 compression. Thanks to Andy Lavr for finding the problem and identifying the solution.
* changed the adjustment of the orc_unwind_ip table at boot time to disregard relocs associated with this table, and instead inspect the entries separately. Relocs are not able to be used since they are no longer correct once the table is resorted at buildtime.
* changed how orc_unwind_ip addresses in randomized sections are identified to include the byte immediately after the end of the section.
* updated module code to use kvmalloc/kvfree based on suggestions from Evgenii Shatokhin <[email protected]>.
* changed kernel commandline to disable fgkaslr to simply "nofgkaslr" to match the nokaslr option. fgkaslr="X" can be added at a later date if it is needed.
* Added a patch to force livepatch to require symbols to be unique if using while fgkaslr either for core or modules.
Changes in v4:
-------------
* dropped the patch to split out change to STATIC definition in x86/boot/compressed/misc.c and replaced with a patch authored by Kees Cook to avoid the duplicate malloc definitions
* Added a section to Documentation/admin-guide/kernel-parameters.txt to document the fgkaslr boot option.
* redesigned the patch to hide the new layout when reading /proc/kallsyms. The previous implementation utilized a dynamically allocated linked list to display the kernel and module symbols in alphabetical order. The new implementation uses a randomly shuffled index array to display the kernel and module symbols in a random order.
Changes in v3:
-------------
* Makefile changes to accommodate CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
* removal of extraneous ALIGN_PAGE from _etext changes
* changed variable names in x86/tools/relocs to be less confusing
* split out change to STATIC definition in x86/boot/compressed/misc.c
* Updates to Documentation to make it more clear what is preserved in .text
* much more detailed commit message for function granular KASLR patch
* minor tweaks and changes that make for more readable code
* this cover letter updated slightly to add additional details
Changes in v2:
--------------
* Fix to address i386 build failure
* Allow module reordering patch to be configured separately so that arm (or other non-x86_64 arches) can take advantage of module function reordering. This support has not be tested by me, but smoke tested by Ard Biesheuvel <[email protected]> on arm.
* Fix build issue when building on arm as reported by
Ard Biesheuvel <[email protected]>
Patches to objtool are included because they are dependencies for this patchset, however they have been submitted by their maintainer separately.
Background
----------
KASLR was merged into the kernel with the objective of increasing the difficulty of code reuse attacks. Code reuse attacks reused existing code snippets to get around existing memory protections. They exploit software bugs which expose addresses of useful code snippets to control the flow of execution for their own nefarious purposes. KASLR moves the entire kernel code text as a unit at boot time in order to make addresses less predictable. The order of the code within the segment is unchanged - only the base address is shifted. There are a few shortcomings to this algorithm.
1. Low Entropy - there are only so many locations the kernel can fit in. This means an attacker could guess without too much trouble.
2. Knowledge of a single address can reveal the offset of the base address, exposing all other locations for a published/known kernel image.
3. Info leaks abound.
Finer grained ASLR has been proposed as a way to make ASLR more resistant to info leaks. It is not a new concept at all, and there are many variations possible. Function reordering is an implementation of finer grained ASLR which randomizes the layout of an address space on a function level granularity. We use the term "fgkaslr" in this document to refer to the technique of function reordering when used with KASLR, as well as finer grained KASLR in general.
Proposed Improvement
--------------------
This patch set proposes adding function reordering on top of the existing KASLR base address randomization. The over-arching objective is incremental improvement over what we already have. It is designed to work in combination with the existing solution. The implementation is really pretty simple, and there are 2 main area where changes occur:
* Build time
GCC has had an option to place functions into individual .text sections for many years now. This option can be used to implement function reordering at load time. The final compiled vmlinux retains all the section headers, which can be used to help find the address ranges of each function. Using this information and an expanded table of relocation addresses, individual text sections can be suffled immediately after decompression. Some data tables inside the kernel that have assumptions about order require re-sorting after being updated when applying relocations. In order to modify these tables, a few key symbols are excluded from the objcopy symbol stripping process for use after shuffling the text segments.
Some highlights from the build time changes to look for:
The top level kernel Makefile was modified to add the gcc flag if it is supported. Currently, I am applying this flag to everything it is possible to randomize. Anything that is written in C and not present in a special input section is randomized. The final binary segment 0 retains a consolidated .text section, as well as all the individual .text.* sections. Future work could turn off this flags for selected files or even entire subsystems, although obviously at the cost of security.
The relocs tool is updated to add relative relocations. This information previously wasn't included because it wasn't necessary when moving the entire .text segment as a unit.
A new file was created to contain a list of symbols that objcopy should keep. We use those symbols at load time as described below.
* Load time
The boot kernel was modified to parse the vmlinux elf file after decompression to check for our interesting symbols that we kept, and to look for any .text.* sections to randomize. The consolidated .text section is skipped and not moved. The sections are shuffled randomly, and copied into memory following the .text section in a new random order. The existing code which updated relocation addresses was modified to account for not just a fixed delta from the load address, but the offset that the function section was moved to. This requires inspection of each address to see if it was impacted by a randomization. We use a bsearch to make this less horrible on performance. Any tables that need to be modified with new addresses or resorted are updated using the symbol addresses parsed from the elf symbol table.
In order to hide our new layout, symbols reported through /proc/kallsyms will be displayed in a random order.
Security Considerations
-----------------------
The objective of this patch set is to improve a technology that is already merged into the kernel (KASLR). This code will not prevent all attacks, but should instead be considered as one of several tools that can be used. In particular, this code is meant to make KASLR more effective in the presence of info leaks.
How much entropy we are adding to the existing entropy of standard KASLR will depend on a few variables. Firstly and most obviously, the number of functions that are randomized matters. This implementation keeps the existing .text section for code that cannot be randomized - for example, because it was assembly code. The less sections to randomize, the less entropy. In addition, due to alignment (16 bytes for x86_64), the number of bits in a address that the attacker needs to guess is reduced, as the lower bits are identical.
Performance Impact
------------------
There are two areas where function reordering can impact performance: boot time latency, and run time performance.
* Boot time latency
This implementation of finer grained KASLR impacts the boot time of the kernel in several places. It requires additional parsing of the kernel ELF file to obtain the section headers of the sections to be randomized. It calls the random number generator for each section to be randomized to determine that section's new memory location. It copies the decompressed kernel into a new area of memory to avoid corruption when laying out the newly randomized sections. It increases the number of relocations the kernel has to perform at boot time vs. standard KASLR, and it also requires a lookup on each address that needs to be relocated to see if it was in a randomized section and needs to be adjusted by a new offset. Finally, it re-sorts a few data tables that are required to be sorted by address.
Booting a test VM on a modern, well appointed system showed an increase in latency of approximately 1 second.
* 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.
Future work could identify hot areas that may not be randomized and either leave them in the .text section or group them together into a single section that may be randomized. If grouping things together helps, one other thing to consider is that if we could identify text blobs that should be grouped together to benefit a particular code flow, it could be interesting to explore whether this security feature could be also be used as a performance feature if you are interested in optimizing your kernel layout for a particular workload at boot time. Optimizing function layout for a particular workload has been researched and proven effective - for more information read the Facebook paper "Optimizing Function Placement for Large-Scale Data-Center Applications" (see references section below).
Image Size
----------
Adding additional section headers as a result of compiling with -ffunction-sections will increase the size of the vmlinux ELF file. With a standard distro config, the resulting vmlinux was increased by about 3%. The compressed image is also increased due to the header files, as well as the extra relocations that must be added. You can expect fgkaslr to increase the size of the compressed image by about 15%.
Memory Usage
------------
fgkaslr increases the amount of heap that is required at boot time, although this extra memory is released when the kernel has finished decompression. As a result, it may not be appropriate to use this feature on systems without much memory.
Building
--------
To enable fine grained KASLR, you need to have the following config options set (including all the ones you would use to build normal KASLR)
CONFIG_FG_KASLR=y
In addition, fgkaslr is only supported for the X86_64 architecture.
Modules
-------
Modules are randomized similarly to the rest of the kernel by shuffling the sections at load time prior to moving them into memory. The module must also have been build with the -ffunction-sections compiler option.
Although fgkaslr for the kernel is only supported for the X86_64 architecture, it is possible to use fgkaslr with modules on other architectures. To enable this feature, select
CONFIG_MODULE_FG_KASLR=y
This option is selected automatically for X86_64 when CONFIG_FG_KASLR is set.
Disabling
---------
Disabling normal KASLR using the nokaslr command line option also disables fgkaslr. It is also possible to disable fgkaslr separately by booting with nofgkaslr on the commandline.
References
----------
There are a lot of academic papers which explore finer grained ASLR. This paper in particular contributed the most to my implementation design as well as my overall understanding of the problem space:
Selfrando: Securing the Tor Browser against De-anonymization Exploits, M. Conti, S. Crane, T. Frassetto, et al.
For more information on how function layout impacts performance, see:
Optimizing Function Placement for Large-Scale Data-Center Applications, G. Ottoni, B. Maher
Kees Cook (2):
x86/boot: Allow a "silent" kaslr random byte fetch x86/boot/compressed: Avoid duplicate malloc() implementations
Kristen Carlson Accardi (8):
x86: tools/relocs: Support >64K section headers
x86: Makefile: Add build and config option for CONFIG_FG_KASLR
x86: Make sure _etext includes function sections x86/tools: Add relative relocs for randomized functions
x86: Add support for function granular KASLR
kallsyms: Hide layout
module: Reorder functions
livepatch: only match unique symbols when using fgkaslr
.../admin-guide/kernel-parameters.txt | 6 + Documentation/security/fgkaslr.rst | 172 ++++ Documentation/security/index.rst | 1 + Makefile | 6 +- arch/x86/Kconfig | 4 + arch/x86/Makefile | 9 + arch/x86/boot/compressed/Makefile | 9 +- arch/x86/boot/compressed/fgkaslr.c | 898 ++++++++++++++++++ arch/x86/boot/compressed/kaslr.c | 4 - arch/x86/boot/compressed/misc.c | 157 ++- arch/x86/boot/compressed/misc.h | 30 + arch/x86/boot/compressed/utils.c | 11 + arch/x86/boot/compressed/vmlinux.symbols | 17 + arch/x86/include/asm/boot.h | 17 +- arch/x86/kernel/vmlinux.lds.S | 17 +- arch/x86/lib/kaslr.c | 18 +- arch/x86/tools/relocs.c | 143 ++- arch/x86/tools/relocs.h | 4 +- arch/x86/tools/relocs_common.c | 15 +- include/asm-generic/vmlinux.lds.h | 18 +- include/linux/decompress/mm.h | 12 +- include/uapi/linux/elf.h | 1 + init/Kconfig | 26 + kernel/kallsyms.c | 163 +++- kernel/livepatch/core.c | 11 + kernel/module.c | 85 +- 26 files changed, 1768 insertions(+), 86 deletions(-) create mode 100644 Documentation/security/fgkaslr.rst create mode 100644 arch/x86/boot/compressed/fgkaslr.c create mode 100644 arch/x86/boot/compressed/utils.c create mode 100644 arch/x86/boot/compressed/vmlinux.symbols
base-commit: ba4f184e126b751d1bffad5897f263108befc780
Signature · 1 line
2.20.1
PATCH v5 1/10 x86: tools/relocs: Support >64K section headers
While the relocs tool already supports finding the total number of section headers if vmlinux exceeds 64K sections, it fails to read the extended symbol table to get section header indexes for symbols, causing incorrect symbol table indexes to be used when there are > 64K symbols.
Parse the elf file to read the extended symbol table info, and then replace all direct references to st_shndx with calls to sym_index(), which will determine whether the value can be read directly or whether the value should be pulled out of the extended table.
--- arch/x86/tools/relocs.c | 104 ++++++++++++++++++++++++++++++---------- 1 file changed, 78 insertions(+), 26 deletions(-)
arch/x86/tools/relocs.c +78 -26
@@ -14,6 +14,10 @@static Elf_Ehdr ehdr;static unsigned long shnum;static unsigned int shstrndx; +static unsigned int shsymtabndx; +static unsigned int shxsymtabndx; + +static int sym_index (Elf_Sym *sym);struct relocs {uint32_t *offset;
@@ -32,6 +36,7 @@ struct section {Elf_Shdr shdr;struct section *link;Elf_Sym *symtab; +Elf32_Word *xsymtab;Elf_Rel *reltab;char *strtab; };
@@ -265,7 +270,7 @@ static const char *sym_name(const char *sym_strtab, Elf_Sym *sym) name = sym_strtab + sym->st_name; }else { - name =sec_name (sym->st_shndx); + name =sec_name (sym_index (sym)); }return name; }
@@ -335,6 +340,23 @@ static uint64_t elf64_to_cpu(uint64_t val)#define elf_xword_to_cpu (x) elf32_to_cpu(x)#endif +static int sym_index (Elf_Sym *sym) +{ +Elf_Sym *symtab = secs[shsymtabndx].symtab; +Elf32_Word *xsymtab = secs[shxsymtabndx].xsymtab; +unsigned long offset; +int index; + +if (sym->st_shndx !=SHN_XINDEX ) +return sym->st_shndx; + +/* calculate offset of sym from head of table. */ + offset = (unsigned long )sym - (unsigned long )symtab; + index = offset /sizeof (*sym); + +return elf32_to_cpu (xsymtab[index]); +} +static void read_ehdr (FILE *fp) {if (fread (&ehdr,sizeof (ehdr),1 , fp) !=1 ) {
@@ -468,31 +490,60 @@ static void read_strtabs(FILE *fp)static void read_symtabs (FILE *fp) {int i,j; +for (i =0 ; i < shnum; i++) {struct section *sec = &secs[i]; -if (sec->shdr.sh_type !=SHT_SYMTAB ) { +int num_syms; + +switch (sec->shdr.sh_type) { +case SHT_SYMTAB_SHNDX : + sec->xsymtab =malloc (sec->shdr.sh_size); +if (!sec->xsymtab) { +die ("malloc of %d bytes for xsymtab failed\n" , + sec->shdr.sh_size); + } +if (fseek (fp, sec->shdr.sh_offset,SEEK_SET ) <0 ) { +die ("Seek to %d failed: %s\n" , + sec->shdr.sh_offset,strerror (errno)); + } +if (fread (sec->xsymtab,1 , sec->shdr.sh_size, fp) + != sec->shdr.sh_size) { +die ("Cannot read extended symbol table: %s\n" , +strerror (errno)); + } + shxsymtabndx = i; +continue ; + +case SHT_SYMTAB : + num_syms = sec->shdr.sh_size /sizeof (Elf_Sym); + + sec->symtab =malloc (sec->shdr.sh_size); +if (!sec->symtab) { +die ("malloc of %d bytes for symtab failed\n" , + sec->shdr.sh_size); + } +if (fseek (fp, sec->shdr.sh_offset,SEEK_SET ) <0 ) { +die ("Seek to %d failed: %s\n" , + sec->shdr.sh_offset,strerror (errno)); + } +if (fread (sec->symtab,1 , sec->shdr.sh_size, fp) + != sec->shdr.sh_size) { +die ("Cannot read symbol table: %s\n" , +strerror (errno)); + } +for (j =0 ; j < num_syms; j++) { +Elf_Sym *sym = &sec->symtab[j]; + + sym->st_name =elf_word_to_cpu (sym->st_name); + sym->st_value =elf_addr_to_cpu (sym->st_value); + sym->st_size =elf_xword_to_cpu (sym->st_size); + sym->st_shndx =elf_half_to_cpu (sym->st_shndx); + } + shsymtabndx = i; +continue ; + +default :continue ; - } - sec->symtab =malloc (sec->shdr.sh_size); -if (!sec->symtab) { -die ("malloc of %d bytes for symtab failed\n" , - sec->shdr.sh_size); - } -if (fseek (fp, sec->shdr.sh_offset,SEEK_SET ) <0 ) { -die ("Seek to %d failed: %s\n" , - sec->shdr.sh_offset,strerror (errno)); - } -if (fread (sec->symtab,1 , sec->shdr.sh_size, fp) - != sec->shdr.sh_size) { -die ("Cannot read symbol table: %s\n" , -strerror (errno)); - } -for (j =0 ; j < sec->shdr.sh_size/sizeof (Elf_Sym); j++) { -Elf_Sym *sym = &sec->symtab[j]; - sym->st_name =elf_word_to_cpu (sym->st_name); - sym->st_value =elf_addr_to_cpu (sym->st_value); - sym->st_size =elf_xword_to_cpu (sym->st_size); - sym->st_shndx =elf_half_to_cpu (sym->st_shndx); } } }
@@ -759,13 +810,14 @@ static void percpu_init(void)*/ static int is_percpu_sym (ElfW (Sym) *sym,const char *symname) { -return (sym->st_shndx == per_cpu_shndx) && +int shndx =sym_index (sym); + +return (shndx == per_cpu_shndx) &&strcmp (symname,"__init_begin" ) &&strcmp (symname,"__per_cpu_load" ) &&strncmp (symname,"init_per_cpu_" ,13 ); } -static int do_reloc64 (struct section *sec,Elf_Rel *rel,ElfW (Sym) *sym,const char *symname) {
@@ -1088,7 +1140,7 @@ static int do_reloc_info(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,sec_name (sec->shdr.sh_info),rel_type (ELF_R_TYPE (rel->r_info)), symname, - sec_name(sym->st_shndx)); + sec_name(sym_index(sym)));return 0 ; }
Signature · 1 line
2.20.1
PATCH v5 2/10 x86/boot: Allow a "silent" kaslr random byte fetch
In reply to Kristen Carlson AccardiFrom: Kees Cook <[email protected]>
Under earlyprintk, each RNG call produces a debug report line. When shuffling hundreds of functions, this is not useful information (each line is identical and tells us nothing new). Instead, allow for a NULL "purpose" to suppress the debug reporting.
--- arch/x86/lib/kaslr.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
arch/x86/lib/kaslr.c +12 -6
@@ -56,11 +56,14 @@ unsigned long kaslr_get_random_long(const char *purpose)unsigned long raw, random =get_boot_seed ();bool use_i8254 = true; -debug_putstr (purpose); -debug_putstr (" KASLR using" ); +if (purpose) { +debug_putstr (purpose); +debug_putstr (" KASLR using" ); + }if (has_cpuflag (X86_FEATURE_RDRAND )) { -debug_putstr (" RDRAND" ); +if (purpose) +debug_putstr (" RDRAND" );if (rdrand_long (&raw)) { random ^= raw; use_i8254 = false;
@@ -68,7 +71,8 @@ unsigned long kaslr_get_random_long(const char *purpose) }if (has_cpuflag (X86_FEATURE_TSC )) { -debug_putstr (" RDTSC" ); +if (purpose) +debug_putstr (" RDTSC" ); raw =rdtsc (); random ^= raw;
@@ -76,7 +80,8 @@ unsigned long kaslr_get_random_long(const char *purpose) }if (use_i8254) { -debug_putstr (" i8254" ); +if (purpose) +debug_putstr (" i8254" ); random ^=i8254 (); }
@@ -86,7 +91,8 @@ unsigned long kaslr_get_random_long(const char *purpose) : "a" (random), "rm" (mix_const)); random += raw; -debug_putstr ("...\n" ); +if (purpose) +debug_putstr ("...\n" );return random; }
Signature · 1 line
2.20.1
PATCH v5 3/10 x86: Makefile: Add build and config option for CONFIG_FG_KASLR
In reply to Kristen Carlson AccardiAllow user to select CONFIG_FG_KASLR if dependencies are met. Change the make file to build with -ffunction-sections if CONFIG_FG_KASLR.
While the only architecture that supports CONFIG_FG_KASLR does not currently enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION, make sure these 2 features play nicely together for the future by ensuring that if CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is selected when used with CONFIG_FG_KASLR the function sections will not be consolidated back into .text. Thanks to Kees Cook for the dead code elimination changes.
--- Makefile | 6 +++++- arch/x86/Kconfig | 4 ++++ include/asm-generic/vmlinux.lds.h | 16 ++++++++++++++-- init/Kconfig | 14 ++++++++++++++ 4 files changed, 37 insertions(+), 3 deletions(-)
Makefile +5 -1
@@ -878,10 +878,14 @@ KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once) endif ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION -KBUILD_CFLAGS_KERNEL += -ffunction-sections -fdata-sections +KBUILD_CFLAGS_KERNEL += -fdata-sections LDFLAGS_vmlinux += --gc-sections endif +ifneq ($(CONFIG_LD_DEAD_CODE_DATA_ELIMINATION)$(CONFIG_FG_KASLR),) +KBUILD_CFLAGS += -ffunction-sections +endif + ifdef CONFIG_SHADOW_CALL_STACK CC_FLAGS_SCS := -fsanitize=shadow-call-stack KBUILD_CFLAGS += $(CC_FLAGS_SCS)
arch/x86/Kconfig +4 -0
@@ -374,6 +374,10 @@ config CC_HAS_SANE_STACKPROTECTOR We have to make sure stack protector is unconditionally disabled if the compiler produces broken code. +config ARCH_HAS_FG_KASLR + def_bool y + depends on RANDOMIZE_BASE && X86_64 + menu "Processor type and features" config ZONE_DMA
include/asm-generic/vmlinux.lds.h +14 -2
@@ -93,14 +93,12 @@* sections to be brought in with rodata. */ #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION -#define TEXT_MAIN .text .text.[0-9a-zA-Z_]*#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..LPBX*#define SDATA_MAIN .sdata .sdata.[0-9a-zA-Z_]*#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]*#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]*#define SBSS_MAIN .sbss .sbss.[0-9a-zA-Z_]*#else -#define TEXT_MAIN .text#define DATA_MAIN .data#define SDATA_MAIN .sdata#define RODATA_MAIN .rodata
@@ -108,6 +106,20 @@#define SBSS_MAIN .sbss#endif +/* +* Both LD_DEAD_CODE_DATA_ELIMINATION and CONFIG_FG_KASLR options enable +* -ffunction-sections, which produces separately named .text sections. In +* the case of CONFIG_FG_KASLR, they need to stay distict so they can be +* separately randomized. Without CONFIG_FG_KASLR, the separate .text +* sections can be collected back into a common section, which makes the +* resulting image slightly smaller +*/ +#if defined(CONFIG_LD_DEAD_CODE_DATA_ELIMINATION ) && !defined(CONFIG_FG_KASLR ) +#define TEXT_MAIN .text .text.[0-9a-zA-Z_]* +#else +#define TEXT_MAIN .text +#endif +/* * GCC 4.5 and later have a 32 bytes section alignment for structures. * Except GCC 4.9, that feels the need to align on 64 bytes.
init/Kconfig +14 -0
@@ -2019,6 +2019,20 @@ config PROFILING config TRACEPOINTS bool +config FG_KASLR + bool "Function Granular Kernel Address Space Layout Randomization" + depends on $(cc-option, -ffunction-sections) + depends on ARCH_HAS_FG_KASLR + default n + help + This option improves the randomness of the kernel text + over basic Kernel Address Space Layout Randomization (KASLR) + by reordering the kernel text at boot time. This feature + uses information generated at compile time to re-layout the + kernel text section at boot time at function level granularity. + + If unsure, say N. + endmenu # General setup source "arch/Kconfig"
Signature · 1 line
2.20.1
PATCH v5 4/10 x86: Make sure _etext includes function sections
In reply to Kristen Carlson AccardiWhen using -ffunction-sections to place each function in it's own text section so it can be randomized at load time, the linker considers these .text.* sections "orphaned sections", and will place them after the first similar section (.text). In order to accurately represent the end of the text section and the orphaned sections, _etext must be moved so that it is after both .text and .text.* The text size must also be calculated to include .text AND .text.*
--- arch/x86/kernel/vmlinux.lds.S | 17 +++++++++++++++-- include/asm-generic/vmlinux.lds.h | 2 +- 2 files changed, 16 insertions(+), 3 deletions(-)
arch/x86/kernel/vmlinux.lds.S +15 -2
@@ -146,9 +146,22 @@ SECTIONS #endif } :text =0xcccc - /* End of text section, which should occupy whole number of pages */ - _etext = .; + /* + * -ffunction-sections creates .text.* sections, which are considered + * "orphan sections" and added after the first similar section (.text). + * Placing this ALIGN statement before _etext causes the address of + * _etext to be below that of all the .text.* orphaned sections + */ . = ALIGN(PAGE_SIZE); + _etext = .; + + /* + * the size of the .text section is used to calculate the address + * range for orc lookups. If we just use SIZEOF(.text), we will + * miss all the .text.* sections. Calculate the size using _etext + * and _stext and save the value for later. + */ + text_size = _etext - _stext; X86_ALIGN_RODATA_BEGIN RO_DATA(PAGE_SIZE)
include/asm-generic/vmlinux.lds.h +1 -1
@@ -863,7 +863,7 @@ . = ALIGN(4); \ .orc_lookup : AT(ADDR(.orc_lookup) - LOAD_OFFSET) { \ orc_lookup = .; \ - . += (((SIZEOF(.text) + LOOKUP_BLOCK_SIZE - 1) / \ + . += (((text_size + LOOKUP_BLOCK_SIZE - 1) / \LOOKUP_BLOCK_SIZE ) +1 ) *4 ; \ orc_lookup_end = .; \ }
Signature · 1 line
2.20.1
PATCH v5 5/10 x86/tools: Add relative relocs for randomized functions
In reply to Kristen Carlson AccardiWhen reordering functions, the relative offsets for relocs that are either in the randomized sections, or refer to the randomized sections will need to be adjusted. Add code to detect whether a reloc satisfies these cases, and if so, add them to the appropriate reloc list.
--- arch/x86/boot/compressed/Makefile | 7 +++++- arch/x86/tools/relocs.c | 41 ++++++++++++++++++++++++++++--- arch/x86/tools/relocs.h | 4 +-- arch/x86/tools/relocs_common.c | 15 +++++++---- 4 files changed, 55 insertions(+), 12 deletions(-)
arch/x86/boot/compressed/Makefile +6 -1
@@ -122,6 +122,11 @@ $(obj)/vmlinux: $(vmlinux-objs-y) $(efi-obj-y) FORCE $(call if_changed,check-and-link-vmlinux) OBJCOPYFLAGS_vmlinux.bin := -R .comment -S + +ifdef CONFIG_FG_KASLR + RELOCS_ARGS += --fg-kaslr +endif + $(obj)/vmlinux.bin: vmlinux FORCE $(call if_changed,objcopy)
@@ -129,7 +134,7 @@ targets += $(patsubst $(obj)/%,%,$(vmlinux-objs-y)) vmlinux.bin.all vmlinux.relo CMD_RELOCS = arch/x86/tools/relocs quiet_cmd_relocs = RELOCS $@ - cmd_relocs = $(CMD_RELOCS) $< > $@;$(CMD_RELOCS) --abs-relocs $< + cmd_relocs = $(CMD_RELOCS) $(RELOCS_ARGS) $< > $@;$(CMD_RELOCS) $(RELOCS_ARGS) --abs-relocs $< $(obj)/vmlinux.relocs: vmlinux FORCE $(call if_changed,relocs)
arch/x86/tools/relocs.c +37 -4
70 lines not on this page · raw message
arch/x86/tools/relocs.h +2 -2
@@ -31,8 +31,8 @@ enum symtype {void process_32 (FILE *fp,int use_real_mode,int as_text,int show_absolute_syms,int show_absolute_relocs, -int show_reloc_info); +int show_reloc_info,int fgkaslr);void process_64 (FILE *fp,int use_real_mode,int as_text,int show_absolute_syms,int show_absolute_relocs, -int show_reloc_info); +int show_reloc_info,int fgkaslr);#endif /* RELOCS_H */
arch/x86/tools/relocs_common.c +10 -5
@@ -12,14 +12,14 @@ void die(char *fmt, ...)static void usage (void ) { -die ("relocs [--abs-syms|--abs-relocs|--reloc-info|--text|--realmode]" \ -" vmlinux\n" ); +die ("relocs [--abs-syms|--abs-relocs|--reloc-info|--text|--realmode|" \ +"--fg-kaslr] vmlinux\n" ); }int main (int argc,char **argv) {int show_absolute_syms, show_absolute_relocs, show_reloc_info; -int as_text, use_real_mode; +int as_text, use_real_mode, fgkaslr_opt;const char *fname;FILE *fp;int i;
@@ -30,6 +30,7 @@ int main(int argc, char **argv) show_reloc_info =0 ; as_text =0 ; use_real_mode =0 ; + fgkaslr_opt =0 ; fname =NULL ;for (i =1 ; i < argc; i++) {char *arg = argv[i];
@@ -54,6 +55,10 @@ int main(int argc, char **argv) use_real_mode =1 ;continue ; } +if (strcmp (arg,"--fg-kaslr" ) ==0 ) { + fgkaslr_opt =1 ; +continue ; + } }else if (!fname) { fname = arg;
@@ -75,11 +80,11 @@ int main(int argc, char **argv)if (e_ident[EI_CLASS ] ==ELFCLASS64 )process_64 (fp, use_real_mode, as_text, show_absolute_syms, show_absolute_relocs, - show_reloc_info); + show_reloc_info, fgkaslr_opt);else process_32 (fp, use_real_mode, as_text, show_absolute_syms, show_absolute_relocs, - show_reloc_info); + show_reloc_info, fgkaslr_opt);fclose (fp);return 0 ; }
Signature · 1 line
2.20.1
PATCH v5 6/10 x86/boot/compressed: Avoid duplicate malloc() implementations
In reply to Kristen Carlson AccardiFrom: Kees Cook <[email protected]>
The preboot malloc() (and free()) implementation in include/linux/decompress/mm.h (which is also included by the static decompressors) is static. This is fine when the only thing interested in using malloc() is the decompression code, but the x86 preboot environment uses malloc() in a couple places, leading to a potential collision when the static copies of the available memory region ("malloc_ptr") gets reset to the global "free_mem_ptr" value. As it happens, the existing usage pattern happened to be safe because each user did 1 malloc() and 1 free() before returning and were not nested:
extract_kernel() (misc.c)
choose_random_location() (kaslr.c) mem_avoid_init() handle_mem_options() malloc() ... free() ... parse_elf() (misc.c) malloc() ... free()
Adding FGKASLR, however, will insert additional malloc() calls local to fgkaslr.c in the middle of parse_elf()'s malloc()/free() pair:
parse_elf() (misc.c)
malloc()
if (...) {
layout_randomized_image(output, &ehdr, phdrs);
malloc() <- boom
...
else
layout_image(output, &ehdr, phdrs);
free()To avoid collisions, there must be a single implementation of malloc(). Adjust include/linux/decompress/mm.h so that visibility can be controlled, provide prototypes in misc.h, and implement the functions in misc.c. This also results in a small size savings:
$ size vmlinux.before vmlinux.after text data bss dec hex filename 8842314 468 178320 9021102 89a6ae vmlinux.before 8842240 468 178320 9021028 89a664 vmlinux.after
--- arch/x86/boot/compressed/kaslr.c | 4 ---- arch/x86/boot/compressed/misc.c | 3 +++ arch/x86/boot/compressed/misc.h | 2 ++ include/linux/decompress/mm.h | 12 ++++++++++-- 4 files changed, 15 insertions(+), 6 deletions(-)
arch/x86/boot/compressed/kaslr.c +0 -4
@@ -32,10 +32,6 @@#include <generated/utsrelease.h> #include <asm/efi.h> -/* Macros used by the included decompressor code below. */ -#define STATIC -#include <linux/decompress/mm.h> -#ifdef CONFIG_X86_5LEVEL unsigned int __pgtable_l5_enabled;unsigned int pgdir_shift__ro_after_init =39 ;
arch/x86/boot/compressed/misc.c +3 -0
@@ -28,6 +28,9 @@/* Macros used by the included decompressor code below. */ #define STATIC static +/* Define an externally visible malloc()/free(). */ +#define MALLOC_VISIBLE +#include <linux/decompress/mm.h> /* * Provide definitions of memzero and memmove as some of the decompressors will
arch/x86/boot/compressed/misc.h +2 -0
@@ -39,6 +39,8 @@/* misc.c */ extern memptr free_mem_ptr;extern memptr free_mem_end_ptr; +extern void *malloc (int size); +extern void free (void *where);extern struct boot_params *boot_params;void __putstr (const char *s);void __puthex (unsigned long value);
include/linux/decompress/mm.h +10 -2
@@ -25,13 +25,21 @@#define STATIC_RW_DATA static#endif +/* +* When an architecture needs to share the malloc()/free() implementation +* between compilation units, it needs to have non-local visibility. +*/ +#ifndef MALLOC_VISIBLE +#define MALLOC_VISIBLE static +#endif +/* A trivial malloc implementation, adapted from * malloc by Hannu Savolainen 1993 and Matthias Urlichs 1994 */ STATIC_RW_DATA unsigned long malloc_ptr; STATIC_RW_DATA int malloc_count; -static void *malloc (int size) +MALLOC_VISIBLE void *malloc(int size) {void *p;
@@ -52,7 +60,7 @@ static void *malloc(int size)return p; } -static void free (void *where) +MALLOC_VISIBLE void free(void *where) { malloc_count--;if (!malloc_count)
Signature · 1 line
2.20.1
PATCH v5 7/10 x86: Add support for function granular KASLR
In reply to Kristen Carlson AccardiThis commit contains the changes required to re-layout the kernel text sections generated by -ffunction-sections shortly after decompression. Documentation of the feature is also added.
After decompression, the decompressed image's elf headers are parsed. In order to manually update certain data structures that are built with relative offsets during the kernel build process, certain symbols are not stripped by objdump and their location is retained in the elf symbol tables. These addresses are saved.
If the image was built with -ffunction-sections, there will be ELF section headers present which contain information about the address range of each section. Anything that is not broken out into function sections (i.e. is consolidated into .text) is left in it's original location, but any other executable section which begins with ".text." is located and shuffled randomly within the remaining text segment address range.
After the sections have been copied to their new locations, but before relocations have been applied, the kallsyms tables must be updated to reflect the new symbol locations. Because it is expected that these tables will be sorted by address, the kallsyms tables will need to be sorted after the update.
When applying relocations, the address of the relocation needs to be adjusted by the offset from the original location of the section that was randomized to it's new location. In addition, if a value at that relocation was a location in the text segment that was randomized, it's value will be adjusted to a new location.
After relocations have been applied, the exception table must be updated with with new symbol locations, and then re-sorted by the new address. The orc table will have been updated as part of applying relocations, but since it is expected to be sorted by address, it will need to be resorted.
--- .../admin-guide/kernel-parameters.txt | 6 + Documentation/security/fgkaslr.rst | 172 ++++ Documentation/security/index.rst | 1 + arch/x86/boot/compressed/Makefile | 2 + arch/x86/boot/compressed/fgkaslr.c | 898 ++++++++++++++++++ arch/x86/boot/compressed/misc.c | 154 ++- arch/x86/boot/compressed/misc.h | 28 + arch/x86/boot/compressed/utils.c | 11 + arch/x86/boot/compressed/vmlinux.symbols | 17 + arch/x86/include/asm/boot.h | 17 +- include/uapi/linux/elf.h | 1 + 11 files changed, 1279 insertions(+), 28 deletions(-) create mode 100644 Documentation/security/fgkaslr.rst create mode 100644 arch/x86/boot/compressed/fgkaslr.c create mode 100644 arch/x86/boot/compressed/utils.c create mode 100644 arch/x86/boot/compressed/vmlinux.symbols
Documentation/admin-guide/kernel-parameters.txt +6 -0
@@ -2105,6 +2105,12 @@ kernel and module base offset ASLR (Address Space Layout Randomization). + nofgkaslr [KNL] + When CONFIG_FG_KASLR is set, this parameter + disables kernel function granular ASLR + (Address Space Layout Randomization). + See Documentation/security/fgkaslr.rst. + kasan_multi_shot [KNL] Enforce KASAN (Kernel Address Sanitizer) to print report on every invalid memory access. Without this
Documentation/security/fgkaslr.rst new file +172 -0
172 lines not on this page · raw message
Documentation/security/index.rst +1 -0
@@ -7,6 +7,7 @@ Security Documentation credentials IMA-templates + fgkaslr keys/index lsm lsm-development
arch/x86/boot/compressed/Makefile +2 -0
@@ -85,6 +85,7 @@ vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/kernel_info.o $(obj)/head_$(BITS).o vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $(obj)/early_serial_console.o vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/kaslr.o +vmlinux-objs-$(CONFIG_FG_KASLR) += $(obj)/utils.o $(obj)/fgkaslr.o ifdef CONFIG_X86_64 vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/kaslr_64.o vmlinux-objs-y += $(obj)/mem_encrypt.o
@@ -125,6 +126,7 @@ OBJCOPYFLAGS_vmlinux.bin := -R .comment -S ifdef CONFIG_FG_KASLR RELOCS_ARGS += --fg-kaslr + OBJCOPYFLAGS += --keep-symbols=$(srctree)/$(src)/vmlinux.symbols endif $(obj)/vmlinux.bin: vmlinux FORCE
arch/x86/boot/compressed/fgkaslr.c new file +898 -0
898 lines not on this page · raw message
arch/x86/boot/compressed/misc.c +128 -26
217 lines not on this page · raw message
arch/x86/boot/compressed/misc.h +28 -0
@@ -76,6 +76,34 @@ struct mem_vector {unsigned long long size; }; +#ifdef CONFIG_X86_64 +#define Elf_Ehdr Elf64_Ehdr +#define Elf_Phdr Elf64_Phdr +#define Elf_Shdr Elf64_Shdr +#else +#define Elf_Ehdr Elf32_Ehdr +#define Elf_Phdr Elf32_Phdr +#define Elf_Shdr Elf32_Shdr +#endif + +#if CONFIG_FG_KASLR +void layout_randomized_image (void *output,Elf_Ehdr *ehdr,Elf_Phdr *phdrs); +void pre_relocations_cleanup (unsigned long map); +void post_relocations_cleanup (unsigned long map); +Elf_Shdr *adjust_address (long *address); +void adjust_relative_offset (long pc,long *value,Elf_Shdr *section); +bool is_percpu_addr (long pc,long offset); +#else +static inline void layout_randomized_image (void *output,Elf_Ehdr *ehdr, +Elf_Phdr *phdrs) { } +static inline void pre_relocations_cleanup (unsigned long map) { } +static inline void post_relocations_cleanup (unsigned long map) { } +static inline Elf_Shdr *adjust_address (long *address) {return NULL ; } +static inline void adjust_relative_offset (long pc,long *value, +Elf_Shdr *section) { } +static inline bool is_percpu_addr (long pc,long offset) {return true; } +#endif /* CONFIG_FG_KASLR */ +#if CONFIG_RANDOMIZE_BASE /* kaslr.c */ void choose_random_location(unsigned long input,
arch/x86/boot/compressed/utils.c new file +11 -0
@@ -0,0 +1,11 @@ +// SPDX-License-Identifier: GPL-2.0 +/* +* utils.c +* +* This contains various libraries that are needed for fgkaslr +*/ +#define __DISABLE_EXPORTS +#define _LINUX_KPROBES_H +#define NOKPROBE_SYMBOL (fname) +#include "../../../../lib/sort.c" +#include "../../../../lib/bsearch.c"
arch/x86/boot/compressed/vmlinux.symbols new file +17 -0
@@ -0,0 +1,17 @@ +kallsyms_offsets +kallsyms_addresses +kallsyms_num_syms +kallsyms_relative_base +kallsyms_names +kallsyms_token_table +kallsyms_token_index +kallsyms_markers +__start___ex_table +__stop___ex_table +_sinittext +_einittext +_stext +_etext +__start_orc_unwind_ip +__stop_orc_unwind_ip +__start_orc_unwind
arch/x86/include/asm/boot.h +15 -2
@@ -24,6 +24,18 @@# error "Invalid value for CONFIG_PHYSICAL_ALIGN"#endif +#ifdef CONFIG_FG_KASLR +/* +* We need extra boot heap when using fgkaslr because we make a copy +* of the original decompressed kernel to avoid issues with writing +* over ourselves when shuffling the sections. We also need extra +* space for resorting kallsyms after shuffling. This value could +* be decreased if free() would release memory properly, or if we +* could avoid the kernel copy. It would need to be increased if we +* find additional tables that need to be resorted. +*/ +# define BOOT_HEAP_SIZE 0x4000000 +#else /* !CONFIG_FG_KASLR */ #if defined(CONFIG_KERNEL_BZIP2 )# define BOOT_HEAP_SIZE 0x400000#elif defined(CONFIG_KERNEL_ZSTD )
@@ -34,8 +46,9 @@*/ # define BOOT_HEAP_SIZE 0x30000#else -# define BOOT_HEAP_SIZE 0x10000 -#endif +# define BOOT_HEAP_SIZE 0x10000 +#endif /* CONFIG_KERNEL_BZIP2 */ +#endif /* CONFIG_FG_KASLR */ #ifdef CONFIG_X86_64 # define BOOT_STACK_SIZE 0x4000
include/uapi/linux/elf.h +1 -0
@@ -299,6 +299,7 @@ typedef struct elf64_phdr {#define SHN_LIVEPATCH 0xff20#define SHN_ABS 0xfff1#define SHN_COMMON 0xfff2 +#define SHN_XINDEX 0xffff#define SHN_HIRESERVE 0xffff typedef struct elf32_shdr {
Signature · 1 line
2.20.1
PATCH v5 8/10 kallsyms: Hide layout
In reply to Kristen Carlson AccardiThis patch makes /proc/kallsyms display in a random order, rather than sorted by address in order to hide the newly randomized address layout.
--- kernel/kallsyms.c | 163 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 162 insertions(+), 1 deletion(-)
kernel/kallsyms.c +162 -1
@@ -448,6 +448,12 @@ struct kallsym_iter {int show_value; }; +struct kallsyms_shuffled_iter { +struct kallsym_iter iter; +loff_t total_syms; +loff_t shuffled_index[]; +}; +int __weak arch_get_kallsym (unsigned int symnum,unsigned long *value,char *type,char *name) {
@@ -695,7 +701,7 @@ bool kallsyms_show_value(const struct cred *cred) } } -static int kallsyms_open (struct inode *inode,struct file *file) +static int __kallsyms_open (struct inode *inode,struct file *file) {/* * We keep iterator in m->private, since normal case is to
@@ -716,6 +722,161 @@ static int kallsyms_open(struct inode *inode, struct file *file)return 0 ; } +/* +* When function granular kaslr is enabled, we need to print out the symbols +* at random so we don't reveal the new layout. +*/ +#if defined(CONFIG_FG_KASLR ) +static int update_random_pos (struct kallsyms_shuffled_iter *s_iter, +loff_t pos,loff_t *new_pos) +{ +loff_t new; + +if (pos >= s_iter->total_syms) +return 0 ; + + new = s_iter->shuffled_index[pos]; + +/* +* normally this would be done as part of update_iter, however, +* we want to avoid triggering this in the event that new is +* zero since we don't want to blow away our pos end indicators. +*/ +if (new ==0 ) { + s_iter->iter.name[0 ] ='\0' ; + s_iter->iter.nameoff =get_symbol_offset (new); + s_iter->iter.pos = new; + } + + *new_pos = new; +return 1 ; +} + +static void *shuffled_start (struct seq_file *m,loff_t *pos) +{ +struct kallsyms_shuffled_iter *s_iter = m->private; +loff_t new_pos; + +if (!update_random_pos (s_iter, *pos, &new_pos)) +return NULL ; + +return s_start (m, &new_pos); +} + +static void *shuffled_next (struct seq_file *m,void *p,loff_t *pos) +{ +struct kallsyms_shuffled_iter *s_iter = m->private; +loff_t new_pos; + + (*pos)++; + +if (!update_random_pos (s_iter, *pos, &new_pos)) +return NULL ; + +if (!update_iter (m->private, new_pos)) +return NULL ; + +return p; +} + +/* +* shuffle_index_list() +* Use a Fisher Yates algorithm to shuffle a list of text sections. +*/ +static void shuffle_index_list (loff_t *indexes,loff_t size) +{ +int i; +unsigned int j; +loff_t temp; + +for (i = size -1 ; i >0 ; i--) { +/* pick a random index from 0 to i */ +get_random_bytes (&j,sizeof (j)); + j = j % (i +1 ); + + temp = indexes[i]; + indexes[i] = indexes[j]; + indexes[j] = temp; + } +} + +static const struct seq_operations kallsyms_shuffled_op = { + .start = shuffled_start, + .next = shuffled_next, + .stop = s_stop, + .show = s_show +}; + +static int kallsyms_random_open (struct inode *inode,struct file *file) +{ +loff_t pos; +struct kallsyms_shuffled_iter *shuffled_iter; +struct kallsym_iter iter; +bool show_value; + +/* +* If privileged, go ahead and use the normal algorithm for +* displaying symbols +*/ + show_value =kallsyms_show_value (file->f_cred); +if (show_value) +return __kallsyms_open (inode, file); + +/* +* we need to figure out how many extra symbols there are +* to print out past kallsyms_num_syms +*/ + pos = kallsyms_num_syms; +reset_iter (&iter,0 ); +do { +if (!update_iter (&iter, pos)) +break ; + pos++; + }while (1 ); + +/* +* add storage space for an array of loff_t equal to the size +* of the total number of symbols we need to print +*/ + shuffled_iter =__seq_open_private (file, &kallsyms_shuffled_op, +sizeof (*shuffled_iter) + + (sizeof (pos) * pos)); +if (!shuffled_iter) +return -ENOMEM ; + +reset_iter (&shuffled_iter->iter,0 ); + shuffled_iter->iter.show_value = show_value; + shuffled_iter->total_syms = pos; + +/* +* the existing update_iter algorithm requires that we +* are either moving along increasing pos sequentially, +* or that these values are correct. Since these values +* were discovered above, initialize our new iter so we +* can use update_iter non-sequentially. +*/ + shuffled_iter->iter.pos_arch_end = iter.pos_arch_end; + shuffled_iter->iter.pos_mod_end = iter.pos_mod_end; + shuffled_iter->iter.pos_ftrace_mod_end = iter.pos_ftrace_mod_end; + +/* +* initialize the array with all possible pos values, then +* shuffle the array so that the values will display in a random +* order. +*/ +for (pos =0 ; pos < shuffled_iter->total_syms; pos++) + shuffled_iter->shuffled_index[pos] = pos; + +shuffle_index_list (shuffled_iter->shuffled_index, shuffled_iter->total_syms); + +return 0 ; +} + +#define kallsyms_open kallsyms_random_open +#else +#define kallsyms_open __kallsyms_open +#endif /* CONFIG_FG_KASLR */ +#ifdef CONFIG_KGDB_KDB const char *kdb_walk_kallsyms (loff_t *pos) {
Signature · 1 line
2.20.1
PATCH v5 9/10 module: Reorder functions
In reply to Kristen Carlson AccardiIntroduce a new config option to allow modules to be re-ordered by function. This option can be enabled independently of the kernel text KASLR or FG_KASLR settings so that it can be used by architectures that do not support either of these features. This option will be selected by default if CONFIG_FG_KASLR is selected.
If a module has functions split out into separate text sections (i.e. compiled with the -ffunction-sections flag), reorder the functions to provide some code diversification to modules.
--- arch/x86/Makefile | 9 +++++ init/Kconfig | 12 +++++++ kernel/kallsyms.c | 2 +- kernel/module.c | 85 +++++++++++++++++++++++++++++++++++++++++++++-- 4 files changed, 105 insertions(+), 3 deletions(-)
arch/x86/Makefile +9 -0
@@ -47,6 +47,15 @@ export REALMODE_CFLAGS # e.g.: obj-y += foo_$(BITS).o export BITS +ifdef CONFIG_X86_NEED_RELOCS + LDFLAGS_vmlinux := --emit-relocs --discard-none +endif + +ifndef CONFIG_FG_KASLR + ifdef CONFIG_MODULE_FG_KASLR + KBUILD_CFLAGS_MODULE += -ffunction-sections + endif +endif # # Prevent GCC from generating any FP code by mistake. #
init/Kconfig +12 -0
@@ -2023,6 +2023,7 @@ config FG_KASLR bool "Function Granular Kernel Address Space Layout Randomization" depends on $(cc-option, -ffunction-sections) depends on ARCH_HAS_FG_KASLR + select MODULE_FG_KASLR default n help This option improves the randomness of the kernel text
@@ -2307,6 +2308,17 @@ config UNUSED_KSYMS_WHITELIST one per line. The path can be absolute, or relative to the kernel source tree. +config MODULE_FG_KASLR + depends on $(cc-option, -ffunction-sections) + bool "Module Function Granular Layout Randomization" + help + This option randomizes the module text section by reordering the text + section by function at module load time. In order to use this + feature, the module must have been compiled with the + -ffunction-sections compiler flag. + + If unsure, say N. + endif # MODULES config MODULES_TREE_LOOKUP
kernel/kallsyms.c +1 -1
@@ -726,7 +726,7 @@ static int __kallsyms_open(struct inode *inode, struct file *file)* When function granular kaslr is enabled, we need to print out the symbols * at random so we don't reveal the new layout. */ -#if defined(CONFIG_FG_KASLR ) +#if defined(CONFIG_FG_KASLR ) || defined(CONFIG_MODULE_FG_KASLR )static int update_random_pos (struct kallsyms_shuffled_iter *s_iter,loff_t pos,loff_t *new_pos) {
kernel/module.c +83 -2
115 lines not on this page · raw message
Signature · 1 line
2.20.1
PATCH v5 10/10 livepatch: only match unique symbols when using fgkaslr
In reply to Kristen Carlson AccardiIf any type of function granular randomization is enabled, the sympos algorithm will fail, as it will be impossible to resolve symbols when there are duplicates using the previous symbol position.
Override the value of sympos to always be zero if fgkaslr is enabled for either the core kernel or modules, forcing the algorithm
to require that only unique symbols are allowed to be patched.
--- kernel/livepatch/core.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
kernel/livepatch/core.c +11 -0
@@ -170,6 +170,17 @@ static int klp_find_object_symbol(const char *objname, const char *name,kallsyms_on_each_symbol (klp_find_callback, &args);mutex_unlock (&module_mutex); +/* +* If any type of function granular randomization is enabled, it +* will be impossible to resolve symbols when there are duplicates +* using the previous symbol position (i.e. sympos != 0). Override +* the value of sympos to always be zero in this case. This will +* force the algorithm to require that only unique symbols are +* allowed to be patched. +*/ +if (IS_ENABLED (CONFIG_FG_KASLR ) ||IS_ENABLED (CONFIG_MODULE_FG_KASLR )) + sympos =0 ; +/* * Ensure an address was found. If sympos is 0, ensure symbol is unique; * otherwise ensure the symbol position count matches sympos.
Signature · 1 line
2.20.1
Miroslav Benes
maintainerRe: [PATCH v5 10/10] livepatch: only match unique symbols when using fgkaslr
Hi,
Quoted 21 lines · Kristen Carlson Accardi
If any type of function granular randomization is enabled, the sympos algorithm will fail, as it will be impossible to resolve symbols when there are duplicates using the previous symbol position.
Override the value of sympos to always be zero if fgkaslr is enabled for either the core kernel or modules, forcing the algorithm
to require that only unique symbols are allowed to be patched.Signed-off-by Kristen Carlson Accardi <[email protected]>--- kernel/livepatch/core.c | 11 +++++++++++ 1 file changed, 11 insertions(+)kernel/livepatch/core.c +0
-0@@ -170,6 +170,17 @@ static int klp_find_object_symbol(const char *objname, const char *name,kallsyms_on_each_symbol (klp_find_callback, &args);mutex_unlock (&module_mutex);
kernel/livepatch/core.c static int klp_find_object_symbol(const char *objname, const char *name, · line 182
Quoted 10 lines
kernel/livepatch/core.c +10
-0+/* +* If any type of function granular randomization is enabled, it +* will be impossible to resolve symbols when there are duplicates +* using the previous symbol position (i.e. sympos != 0). Override +* the value of sympos to always be zero in this case. This will +* force the algorithm to require that only unique symbols are +* allowed to be patched. +*/ +if (IS_ENABLED (CONFIG_FG_KASLR ) ||IS_ENABLED (CONFIG_MODULE_FG_KASLR )) + sympos =0 ;
This should work, but I wonder if we should make it more explicit. With the change the user will get the error with "unresolvable ambiguity for symbol..." if they specify sympos and the symbol is not unique. It could confuse them.
So, how about it making it something like
if (IS_ENABLED(CONFIG_FG_KASLR) || IS_ENABLED(CONFIG_MODULE_FG_KASLR))
if (sympos) {
pr_err("fgkaslr is enabled, specifying sympos for symbol '%s' in object '%s' does not work.\n",
name, objname);
*addr = 0;
return -EINVAL;
}? (there could be goto to the error out at the end of the function).
In that case, if sympos is not specified, the user will get the message which matches the reality. If the user specifies it, they will get the error in case of fgkaslr.
Thanks for dealing with it
Miroslav
Miroslav Benes
maintainerHi Kristen,
Quoted 7 lines · Kristen Carlson Accardi
Function Granular Kernel Address Space Layout Randomization (fgkaslr)
---------------------------------------------------------------------This patch set is an implementation of finer grained kernel address space randomization. It rearranges your kernel code at load time
on a per-function level granularity, with only around a second added to boot time.
I ran live patching kernel selftests on the patch set and everything passed fine.
However, we also use not-yet-upstream set of tests at SUSE for testing live patching [1] and one of them, klp_tc_12.sh, is failing. You should be able to run the set on upstream as is.
The test uninterruptedly sleeps in a kretprobed function called by a patched one. The current master without fgkaslr patch set reports the stack of the sleeping task as unreliable and live patching fails. The situation is different with fgkaslr (even with nofgkaslr on the command line). The stack is returned as reliable. It looks something like
[<0>] __schedule+0x465/0xa40 [<0>] schedule+0x55/0xd0 [<0>] orig_do_sleep+0xb1/0x110 [klp_test_support_mod] [<0>] swap_pages+0x7f/0x7f
where the last entry is not reliable. I've seen kretprobe_trampoline+0x0/0x4a and some other symbols there too. Since the patched function (orig_sleep_uninterruptible_set) is not on the stack, live patching succeeds, which is not intended.
With kprobe setting removed, all works as expected.
So I wonder if there is still some issue with ORC somewhere as you mentioned in v4 thread. I'll investigate more next week, but wanted to report early.
Regards
Miroslav
Hi,
Quoted 53 lines · Miroslav Benes
Hi Kristen,
Quoted 11 lines · Kristen Carlson Accardi
Function Granular Kernel Address Space Layout Randomization (fgkaslr)
-----------------------------------------------------------------
----This patch set is an implementation of finer grained kernel address space
randomization. It rearranges your kernel code at load time on a per-function level granularity, with only around a second added to
boot time.I ran live patching kernel selftests on the patch set and everything passed fine.
However, we also use not-yet-upstream set of tests at SUSE for testing
live patching [1] and one of them,klp_tc_12.sh, is failing. You should be
able to run the set on upstream as is.The test uninterruptedly sleeps in a kretprobed function called by a patched one. The current master without fgkaslr patch set reports the
stack of the sleeping task as unreliable and live patching fails. The
situation is different with fgkaslr (even with nofgkaslr on the command
line). The stack is returned as reliable. It looks something like[<0>] __schedule+0x465/0xa40 [<0>] schedule+0x55/0xd0 [<0>] orig_do_sleep+0xb1/0x110 [klp_test_support_mod] [<0>] swap_pages+0x7f/0x7fwhere the last entry is not reliable. I've seen
kretprobe_trampoline+0x0/0x4aand some other symbols there too. Since the
patched function (orig_sleep_uninterruptible_set) is not on the stack,
live patching succeeds, which is not intended.With kprobe setting removed, all works as expected.
So I wonder if there is still some issue with ORC somewhere as you mentioned in v4 thread. I'll investigate more next week, but wanted to
report early.
Quoted 4 lines
Regards
Miroslav
Thanks for testing and reporting. I will grab your test and see what I can find.
Quoted 8 lines · Kristen Carlson Accardi
This patch set is an implementation of finer grained kernel address space randomization. It rearranges your kernel code at load time
on a per-function level granularity, with only around a second added to boot time.Changes in v5:
--------------
[...]
Builds and boots; looks happy. Hopefully this can go into -tip after the coming v5.10 merge window, for v5.11? Thoughts?
Signature · 1 line
Kees Cook