Kernel-hardening archive on lore.kernel.org
 help / color / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Jason Yan <yanaijie@huawei.com>
Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
	diana.craciun@nxp.com, christophe.leroy@c-s.fr,
	benh@kernel.crashing.org, paulus@samba.org, npiggin@gmail.com,
	kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com,
	yebin10@huawei.com, thunder.leizhen@huawei.com,
	jingxiangfeng@huawei.com, fanchengyang@huawei.com
Subject: Re: [RFC PATCH 00/10] implement KASLR for powerpc/fsl_booke/32
Date: Thu, 25 Jul 2019 12:58:12 -0700
Message-ID: <201907251252.0C58037@keescook> (raw)
In-Reply-To: <e6ad41bc-5d5a-cf3f-b308-e1863b4fef99@huawei.com>

On Thu, Jul 25, 2019 at 03:16:28PM +0800, Jason Yan wrote:
> Hi all, any comments?

I'm a fan of it, but I don't know ppc internals well enough to sanely
review the code. :) Some comments below on design...

> 
> 
> On 2019/7/17 16:06, Jason Yan wrote:
> > This series implements KASLR for powerpc/fsl_booke/32, as a security
> > feature that deters exploit attempts relying on knowledge of the location
> > of kernel internals.
> > 
> > Since CONFIG_RELOCATABLE has already supported, what we need to do is
> > map or copy kernel to a proper place and relocate. Freescale Book-E
> > parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1
> > entries are not suitable to map the kernel directly in a randomized
> > region, so we chose to copy the kernel to a proper place and restart to
> > relocate.
> > 
> > Entropy is derived from the banner and timer base, which will change every
> > build and boot. This not so much safe so additionally the bootloader may
> > pass entropy via the /chosen/kaslr-seed node in device tree.

Good: adding kaslr-seed is a good step here. Are there any x86-like
RDRAND or RDTSC to use? (Or maybe timer base here is similar to x86
RDTSC here?)

> > 
> > We will use the first 512M of the low memory to randomize the kernel
> > image. The memory will be split in 64M zones. We will use the lower 8
> > bit of the entropy to decide the index of the 64M zone. Then we chose a
> > 16K aligned offset inside the 64M zone to put the kernel in.

Does this 16K granularity have any page table performance impact? My
understanding was that x86 needed to have 2M granularity due to its page
table layouts.

Why the 64M zones instead of just 16K granularity across the entire low
512M?

> > 
> >      KERNELBASE
> > 
> >          |-->   64M   <--|
> >          |               |
> >          +---------------+    +----------------+---------------+
> >          |               |....|    |kernel|    |               |
> >          +---------------+    +----------------+---------------+
> >          |                         |
> >          |----->   offset    <-----|
> > 
> >                                kimage_vaddr
> > 
> > We also check if we will overlap with some areas like the dtb area, the
> > initrd area or the crashkernel area. If we cannot find a proper area,
> > kaslr will be disabled and boot from the original kernel.
> > 
> > Jason Yan (10):
> >    powerpc: unify definition of M_IF_NEEDED
> >    powerpc: move memstart_addr and kernstart_addr to init-common.c
> >    powerpc: introduce kimage_vaddr to store the kernel base
> >    powerpc/fsl_booke/32: introduce create_tlb_entry() helper
> >    powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper
> >    powerpc/fsl_booke/32: implement KASLR infrastructure
> >    powerpc/fsl_booke/32: randomize the kernel image offset
> >    powerpc/fsl_booke/kaslr: clear the original kernel if randomized
> >    powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter
> >    powerpc/fsl_booke/kaslr: dump out kernel offset information on panic

Is there anything planned for other fixed-location things, like x86's
CONFIG_RANDOMIZE_MEMORY?

-- 
Kees Cook

  reply index

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17  8:06 Jason Yan
2019-07-17  8:06 ` [RFC PATCH 01/10] powerpc: unify definition of M_IF_NEEDED Jason Yan
2019-07-29 10:59   ` Christophe Leroy
2019-07-17  8:06 ` [RFC PATCH 02/10] powerpc: move memstart_addr and kernstart_addr to init-common.c Jason Yan
2019-07-29 11:00   ` Christophe Leroy
2019-07-29 14:31   ` Christoph Hellwig
2019-07-30  0:47     ` Jason Yan
2019-07-17  8:06 ` [RFC PATCH 03/10] powerpc: introduce kimage_vaddr to store the kernel base Jason Yan
2019-07-29 11:00   ` Christophe Leroy
2019-07-29 14:32   ` Christoph Hellwig
2019-07-17  8:06 ` [RFC PATCH 04/10] powerpc/fsl_booke/32: introduce create_tlb_entry() helper Jason Yan
2019-07-29 11:05   ` Christophe Leroy
2019-07-29 13:26     ` Jason Yan
2019-07-17  8:06 ` [RFC PATCH 05/10] powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper Jason Yan
2019-07-29 11:08   ` Christophe Leroy
2019-07-29 13:35     ` Jason Yan
2019-07-17  8:06 ` [RFC PATCH 06/10] powerpc/fsl_booke/32: implement KASLR infrastructure Jason Yan
2019-07-29 11:16   ` Christophe Leroy
2019-07-17  8:06 ` [RFC PATCH 07/10] powerpc/fsl_booke/32: randomize the kernel image offset Jason Yan
2019-07-29 11:33   ` Christophe Leroy
2019-07-29 13:53     ` Jason Yan
2019-07-17  8:06 ` [RFC PATCH 08/10] powerpc/fsl_booke/kaslr: clear the original kernel if randomized Jason Yan
2019-07-29 11:19   ` Christophe Leroy
2019-07-29 13:43     ` Jason Yan
2019-07-17  8:06 ` [RFC PATCH 09/10] powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter Jason Yan
2019-07-29 11:38   ` Christophe Leroy
2019-07-29 14:04     ` Jason Yan
2019-07-17  8:06 ` [RFC PATCH 10/10] powerpc/fsl_booke/kaslr: dump out kernel offset information on panic Jason Yan
2019-07-29 11:43   ` Christophe Leroy
2019-07-29 14:08     ` Jason Yan
2019-07-25  7:16 ` [RFC PATCH 00/10] implement KASLR for powerpc/fsl_booke/32 Jason Yan
2019-07-25 19:58   ` Kees Cook [this message]
2019-07-26  7:20     ` Jason Yan
2019-07-26 16:15       ` Kees Cook
2019-07-26  7:04   ` Diana Madalina Craciun
2019-07-26  7:26     ` Jason Yan
2019-07-29 14:30 ` Diana Madalina Craciun

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201907251252.0C58037@keescook \
    --to=keescook@chromium.org \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=diana.craciun@nxp.com \
    --cc=fanchengyang@huawei.com \
    --cc=jingxiangfeng@huawei.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    --cc=thunder.leizhen@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=yanaijie@huawei.com \
    --cc=yebin10@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Kernel-hardening archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernel-hardening/0 kernel-hardening/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernel-hardening kernel-hardening/ https://lore.kernel.org/kernel-hardening \
		kernel-hardening@lists.openwall.com kernel-hardening@archiver.kernel.org
	public-inbox-index kernel-hardening

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.openwall.lists.kernel-hardening


AGPL code for this site: git clone https://public-inbox.org/ public-inbox