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: <1425308310-2318-1-git-send-email-bhe@redhat.com>
Date:	Mon,  2 Mar 2015 22:58:21 +0800
From:	Baoquan He <bhe@...hat.com>
To:	hpa@...or.com, yinghai@...nel.org, keescook@...omium.org,
	vgoyal@...hat.com, luto@...capital.net, akpm@...ux-foundation.org,
	tglx@...utronix.de, mingo@...hat.com
Cc:	linux-kernel@...r.kernel.org, Baoquan He <bhe@...hat.com>
Subject: [PATCH v2 0/9] 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 the behavior is changed. Randomize both the physical
address where kernel is decompressed and the virtual address where kernel text is mapped.
And physical address can be randomized from where vmlinux was linked to load to maximum
physical memory, possibly near 64T. While virtual address can get a random offset from load
address to CONFIG_RANDOMIZE_BASE_MAX_OFFSET, then added to __START_KERNEL_map. And
relocation handling only depends on virtual address randomization. Means if and only if
virtual address is randomized to a different value, we add the delta to the offset of
kernel relocs.

v1->v2:
    Thanks to Yinghai's patch which make kernel be able to load above 4G in boot stage,
    physical address can be randomized to anywhere, even near 64T.


    Thank Andy Lutomirski for his adding idt patch, finally it's not used in this patchset
    since I didn't make the #PF handler work well. I believe it does work, but I didn't
    make it. Will check why later. Thanks anyway.

Baoquan He (8):
  remove a unused function parameter
  a bug that relocation can not be handled when kernel is loaded above
    2G
  introduce struct slot_area to manage randomization slot info
  add mem_min_overlap to find the first avoid region within a memory
    region
  change process_e820_entry to store slot info into slot_area
  get the random phy addr according to slot_area info
  introduce fetch_random_virt_offset to randomize the kernel text
    mapping address
  change the relocations behavior for kaslr on x86_64

Yinghai Lu (1):
  make kernel be able to load above 4G in boot stage

 arch/x86/boot/compressed/aslr.c     | 194 +++++++++++++++++++++++++++---------
 arch/x86/boot/compressed/misc.c     |  46 ++++++---
 arch/x86/boot/compressed/misc.h     |  22 ++--
 arch/x86/boot/compressed/misc_pgt.c |  61 ++++++++++++
 arch/x86/include/asm/page.h         |   5 +
 arch/x86/mm/ident_map.c             |  74 ++++++++++++++
 arch/x86/mm/init_64.c               |  74 +-------------
 7 files changed, 333 insertions(+), 143 deletions(-)
 create mode 100644 arch/x86/boot/compressed/misc_pgt.c
 create mode 100644 arch/x86/mm/ident_map.c

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ