kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Jason Yan <yanaijie@huawei.com>,
	linuxppc-dev@lists.ozlabs.org, diana.craciun@nxp.com,
	christophe.leroy@c-s.fr, benh@kernel.crashing.org,
	paulus@samba.org, npiggin@gmail.com, keescook@chromium.org,
	kernel-hardening@lists.openwall.com
Cc: linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com,
	yebin10@huawei.com, thunder.leizhen@huawei.com,
	jingxiangfeng@huawei.com, fanchengyang@huawei.com,
	zhaohongjiang@huawei.com, Jason Yan <yanaijie@huawei.com>
Subject: Re: [PATCH v5 07/10] powerpc/fsl_booke/32: randomize the kernel image offset
Date: Wed, 07 Aug 2019 23:03:27 +1000	[thread overview]
Message-ID: <871rxxunz4.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190807065706.11411-8-yanaijie@huawei.com>

Jason Yan <yanaijie@huawei.com> writes:
> After we have the basic support of relocate the kernel in some
> appropriate place, we can start to randomize the offset now.
>
> Entropy is derived from the banner and timer, 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.
>
> 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.
>
>     KERNELBASE
>
>         |-->   64M   <--|
>         |               |
>         +---------------+    +----------------+---------------+
>         |               |....|    |kernel|    |               |
>         +---------------+    +----------------+---------------+
>         |                         |
>         |----->   offset    <-----|
>
>                               kimage_vaddr

Can you drop this description / diagram and any other relevant design
details in eg. Documentation/powerpc/kaslr-booke32.rst please?

See cpu_families.rst for an example of how to incorporate the ASCII
diagram.

> diff --git a/arch/powerpc/kernel/kaslr_booke.c b/arch/powerpc/kernel/kaslr_booke.c
> index 30f84c0321b2..52b59b05f906 100644
> --- a/arch/powerpc/kernel/kaslr_booke.c
> +++ b/arch/powerpc/kernel/kaslr_booke.c
> @@ -34,15 +36,329 @@
>  #include <asm/machdep.h>
>  #include <asm/setup.h>
>  #include <asm/paca.h>
> +#include <asm/kdump.h>
>  #include <mm/mmu_decl.h>
> +#include <generated/compile.h>
> +#include <generated/utsrelease.h>
> +
> +#ifdef DEBUG
> +#define DBG(fmt...) pr_info(fmt)
> +#else
> +#define DBG(fmt...)
> +#endif

Just use pr_debug()?

> +struct regions {
> +	unsigned long pa_start;
> +	unsigned long pa_end;
> +	unsigned long kernel_size;
> +	unsigned long dtb_start;
> +	unsigned long dtb_end;
> +	unsigned long initrd_start;
> +	unsigned long initrd_end;
> +	unsigned long crash_start;
> +	unsigned long crash_end;
> +	int reserved_mem;
> +	int reserved_mem_addr_cells;
> +	int reserved_mem_size_cells;
> +};
>  
>  extern int is_second_reloc;
>  
> +/* Simplified build-specific string for starting entropy. */
> +static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
> +		LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
> +
> +static __init void kaslr_get_cmdline(void *fdt)
> +{
> +	int node = fdt_path_offset(fdt, "/chosen");
> +
> +	early_init_dt_scan_chosen(node, "chosen", 1, boot_command_line);
> +}
> +
> +static unsigned long __init rotate_xor(unsigned long hash, const void *area,
> +				       size_t size)
> +{
> +	size_t i;
> +	const unsigned long *ptr = area;
> +
> +	for (i = 0; i < size / sizeof(hash); i++) {
> +		/* Rotate by odd number of bits and XOR. */
> +		hash = (hash << ((sizeof(hash) * 8) - 7)) | (hash >> 7);
> +		hash ^= ptr[i];
> +	}
> +
> +	return hash;
> +}

That looks suspiciously like the version Kees wrote in 2013 in
arch/x86/boot/compressed/kaslr.c ?

You should mention that in the change log at least.

> +
> +/* Attempt to create a simple but unpredictable starting entropy. */

It's simple, but I would argue unpredictable is not really true. A local
attacker can probably fingerprint the kernel version, and also has
access to the unflattened device tree, which means they can make
educated guesses about the flattened tree size.

Be careful when copying comments :)

> +static unsigned long __init get_boot_seed(void *fdt)
> +{
> +	unsigned long hash = 0;
> +
> +	hash = rotate_xor(hash, build_str, sizeof(build_str));
> +	hash = rotate_xor(hash, fdt, fdt_totalsize(fdt));
> +
> +	return hash;
> +}
> +
> +static __init u64 get_kaslr_seed(void *fdt)
> +{
> +	int node, len;
> +	fdt64_t *prop;
> +	u64 ret;
> +
> +	node = fdt_path_offset(fdt, "/chosen");
> +	if (node < 0)
> +		return 0;
> +
> +	prop = fdt_getprop_w(fdt, node, "kaslr-seed", &len);
> +	if (!prop || len != sizeof(u64))
> +		return 0;
> +
> +	ret = fdt64_to_cpu(*prop);
> +	*prop = 0;
> +	return ret;
> +}
> +
> +static __init bool regions_overlap(u32 s1, u32 e1, u32 s2, u32 e2)
> +{
> +	return e1 >= s2 && e2 >= s1;
> +}

There's a generic helper called memory_intersects(), though it takes
void*. Might not be worth using, not sure.

...
>  static unsigned long __init kaslr_choose_location(void *dt_ptr, phys_addr_t size,
>  						  unsigned long kernel_sz)
>  {
> -	/* return a fixed offset of 64M for now */
> -	return SZ_64M;
> +	unsigned long offset, random;
> +	unsigned long ram, linear_sz;
> +	unsigned long kaslr_offset;
> +	u64 seed;
> +	struct regions regions;

You pass that around to a lot of the functions, would it be simpler just
to make it static global and __initdata ?

cheers


  reply	other threads:[~2019-08-07 13:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07  6:56 [PATCH v5 00/10] implement KASLR for powerpc/fsl_booke/32 Jason Yan
2019-08-07  6:56 ` [PATCH v5 01/10] powerpc: unify definition of M_IF_NEEDED Jason Yan
2019-08-07 13:13   ` Michael Ellerman
2019-08-08  3:25     ` Jason Yan
2019-08-07  6:56 ` [PATCH v5 02/10] powerpc: move memstart_addr and kernstart_addr to init-common.c Jason Yan
2019-08-07 13:02   ` Michael Ellerman
2019-08-08  3:32     ` Jason Yan
2019-08-07  6:56 ` [PATCH v5 03/10] powerpc: introduce kimage_vaddr to store the kernel base Jason Yan
2019-08-07 13:03   ` Michael Ellerman
2019-08-08  4:29     ` Jason Yan
2019-08-07  6:57 ` [PATCH v5 04/10] powerpc/fsl_booke/32: introduce create_tlb_entry() helper Jason Yan
2019-08-07  6:57 ` [PATCH v5 05/10] powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper Jason Yan
2019-08-07  6:57 ` [PATCH v5 06/10] powerpc/fsl_booke/32: implement KASLR infrastructure Jason Yan
2019-08-07 13:04   ` Michael Ellerman
2019-08-08  6:19     ` Jason Yan
2019-08-07  6:57 ` [PATCH v5 07/10] powerpc/fsl_booke/32: randomize the kernel image offset Jason Yan
2019-08-07 13:03   ` Michael Ellerman [this message]
2019-08-08  7:08     ` Jason Yan
2019-08-07  6:57 ` [PATCH v5 08/10] powerpc/fsl_booke/kaslr: clear the original kernel if randomized Jason Yan
2019-08-07  6:57 ` [PATCH v5 09/10] powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter Jason Yan
2019-08-07 13:03   ` Michael Ellerman
2019-08-08  8:19     ` Jason Yan
2019-08-07  6:57 ` [PATCH v5 10/10] powerpc/fsl_booke/kaslr: dump out kernel offset information on panic Jason Yan
2019-08-07 13:03   ` Michael Ellerman
2019-08-08  8:39     ` Jason Yan
2019-08-07 13:12 ` [PATCH v5 00/10] implement KASLR for powerpc/fsl_booke/32 Michael Ellerman
2019-08-08  3:19   ` Jason Yan

Reply instructions:

You may reply publicly 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=871rxxunz4.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --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=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --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 \
    --cc=zhaohongjiang@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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).