linux-kernel - [PATCH 0/6] randomize kernel physical address and virtual address separately

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-next>] [day] [month] [year] [list]

Message-Id: <1421811437-2787-1-git-send-email-bhe@redhat.com>
Date:	Wed, 21 Jan 2015 11:37:11 +0800
From:	Baoquan He <bhe@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	hpa@...or.com, tglx@...utronix.de, mingo@...hat.com,
	x86@...nel.org, keescook@...omium.org, vgoyal@...hat.com,
	whissi@...ssi.de, Baoquan He <bhe@...hat.com>
Subject: [PATCH 0/6] randomize kernel physical address and virtual address separately

Currently kaslr only randomize physical address of kernel loading, then add the delta
to virtual address of kernel text mapping. Because kernel virtual address can only be
from __START_KERNEL_map to LOAD_PHYSICAL_ADDR+CONFIG_RANDOMIZE_BASE_MAX_OFFSET, namely
[0xffffffff80000000, 0xffffffffc0000000], so physical address can only be randomized
in region [LOAD_PHYSICAL_ADDR, CONFIG_RANDOMIZE_BASE_MAX_OFFSET], namely [16M, 1G].

So hpa and Vivek suggested the randomization should be done separately for both physical
and virtual address. In this patchset I tried it. And after randomization, relocation
handling only depends on virtual address changing, means I only check whether virtual
address is randomized to other position, if yes relocation need be handled, if no just
skip the relocation handling though physical address is randomized to different place.
Now physical address can be randomized from 16M to 4G, virtual address offset can be
from 16M to 1G.

Leftover problem:
    hpa want to see the physical randomization can cover the whole physical memory. I
checked code and found it's hard to do. Because in arch/x86/boot/compressed/head_64.S
an identity mapping of 4G is built and then kaslr and decompressing are done. The #PF
handler solution which he suggested is only available after jump into decompressed
kernel, namely in arch/x86/kernel/head_64.S. I didn't think of a way to do the whole
memory covering for physical address randomization, any suggestion or idea?

Baoquan He (6):
  remove a unused function parameter
  a bug that relocation can not be handled when kernel is loaded above
    2G
  Introduce a function to randomize the kernel text mapping address
  adapt choose_kernel_location to add the kernel virtual address
    randomzation
  change the relocations behavior for kaslr on x86_64
  extend the upper limit of kernel physical address randomization to 4G

 arch/x86/boot/compressed/aslr.c | 69 ++++++++++++++++++++++++++++-------------
 arch/x86/boot/compressed/misc.c | 34 +++++++++++++-------
 arch/x86/boot/compressed/misc.h | 20 ++++++------
 3 files changed, 82 insertions(+), 41 deletions(-)

-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/