Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Apr 2016 12:46:29 -0700
From: Kees Cook <keescook@...omium.org>
To: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Cc: Ralf Baechle <ralf@...ux-mips.org>, 
	Linux MIPS Mailing List <linux-mips@...ux-mips.org>, Matt Redfearn <matt.redfearn@...tec.com>, 
	Aaro Koskinen <aaro.koskinen@...ia.com>, Masahiro Yamada <yamada.masahiro@...ionext.com>, 
	Alexander Sverdlin <alexander.sverdlin@...il.com>, LKML <linux-kernel@...r.kernel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, David Daney <ddaney@...iumnetworks.com>, 
	Jaedon Shin <jaedon.shin@...il.com>, James Hogan <james.hogan@...tec.com>, 
	Jonas Gorski <jogo@...nwrt.org>, Paul Burton <paul.burton@...tec.com>
Subject: Re: [PATCH v2 00/11] MIPS relocatable kernel & KASLR

On Thu, Mar 31, 2016 at 2:05 AM, Matt Redfearn <matt.redfearn@...tec.com> wrote:
>
> This series adds the ability for the MIPS kernel to relocate itself at
> runtime, optionally to an address determined at random each boot. This
> series is based on v4.4 and has been tested on the Malta, Boston and
> SEAD3 platforms.
>
> Here is a description of how relocation is achieved:
> * Kernel is compiled & statically linked as normal, with no position
>   independent code. MIPS before R6 only has limited relative jump
>   instructions so the vast majority of jumps are absolute. To compile
>   the kernel position independent would introduce a highly undesireable
>   overhead. Relocating the static binary gives a small startup time
>   penalty but the kernel otherwise perforns normally.
> * The linker flag --emit-relocs is added to the linker command line,
>   causing ld to include relocation sections in the output elf
> * A tool derived from the x86 relocs tool is used to parse the
>   relocation sections and create a binary table of relocations. Each
>   entry in the table is 32bits, comprised of a 24bit offset (in words)
>   from _text and an 8bit relocation type.
> * The table is inserted into the vmlinux elf, into some space reserved
>   for it in the linker script. Inserting the table into vmlinux means
>   all boot targets will automatically include the relocation code and
>   information.
> * At boot, the kernel memcpy()s itself elsewhere in memory, then goes
>   through the table performing each relocation on the new image.
> * If all goes well, control is passed to the entry point of the new
>   kernel.

This is great! Thanks for working on this! :)

Without actually reading the code yet, I wonder if the x86 and MIPS
relocs tool could be merged at all? Sounds like it might be more
difficult though -- the relocation output is different and its storage
location is different...

> Restrictions:
> * The new kernel is not allowed to overlap the old kernel, such that
>   the original kernel can still be booted if relocation fails.

This sounds like physical-only relocation then? Is the virtual offset
randomized as well (like arm64) or just physical (like x86 currently
-- though there is a series to fix this).

> * Relocation is supported only by multiples of 64k bytes. This
>   eliminates the need to handle R_MIPS_LO16 relocations as the bottom
>   16bits will remain the same at the relocated address.

IIUC, that's actually better than x86, which needs to be 2MB aligned.

> * In 64 bit kernels, relocation is supported only within the same 4Gb
>   memory segment as the kernel link address (CONFIG_PHYSICAL_START).
>   This eliminates the need to handle R_MIPS_HIGHEST and R_MIPS_HIGHER
>   relocations as the top 32bits will remain the same at the relocated
>   address.

Interesting. Could the relocation code be updated in the future to
bump the high addresses too?

> Changes in v2:
> - Added support  for MIPSr6
> - Accept the "nokaslr" command line option
> - Add a kernel panic notifier to print the relocation information
> - Accept entropy via the /chosen/kaslr-seed property in device tree
> - Tested on MIPS Malta, Boston and SEAD3 platforms
>
> Matt Redfearn (11):
>   MIPS: tools: Add relocs tool
>   MIPS: tools: Build relocs tool
>   MIPS: Reserve space for relocation table
>   MIPS: Generate relocation table when CONFIG_RELOCATABLE
>   MIPS: Kernel: Add relocate.c
>   MIPS: Call relocate_kernel if CONFIG_RELOCATABLE=y
>   MIPS: bootmem: When relocatable, free memory below kernel
>   MIPS: Add CONFIG_RELOCATABLE Kconfig option
>   MIPS: Introduce plat_get_fdt a platform API to retrieve the FDT
>   MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE
>   MIPS: KASLR: Print relocation Information on boot
>
>  arch/mips/Kconfig                  |  64 ++++
>  arch/mips/Makefile                 |  19 ++
>  arch/mips/boot/tools/Makefile      |   8 +
>  arch/mips/boot/tools/relocs.c      | 680 +++++++++++++++++++++++++++++++++++++
>  arch/mips/boot/tools/relocs.h      |  45 +++
>  arch/mips/boot/tools/relocs_32.c   |  17 +
>  arch/mips/boot/tools/relocs_64.c   |  27 ++
>  arch/mips/boot/tools/relocs_main.c |  84 +++++
>  arch/mips/include/asm/bootinfo.h   |  18 +
>  arch/mips/kernel/Makefile          |   2 +
>  arch/mips/kernel/head.S            |  20 ++
>  arch/mips/kernel/relocate.c        | 386 +++++++++++++++++++++
>  arch/mips/kernel/setup.c           |  23 ++
>  arch/mips/kernel/vmlinux.lds.S     |  21 ++
>  arch/mips/mti-malta/malta-setup.c  |   7 +-
>  arch/mips/mti-sead3/sead3-setup.c  |   5 +
>  16 files changed, 1425 insertions(+), 1 deletion(-)
>  create mode 100644 arch/mips/boot/tools/Makefile
>  create mode 100644 arch/mips/boot/tools/relocs.c
>  create mode 100644 arch/mips/boot/tools/relocs.h
>  create mode 100644 arch/mips/boot/tools/relocs_32.c
>  create mode 100644 arch/mips/boot/tools/relocs_64.c
>  create mode 100644 arch/mips/boot/tools/relocs_main.c
>  create mode 100644 arch/mips/kernel/relocate.c
>
> --
> 2.5.0
>

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.