All of lore.kernel.org
 help / color / mirror / Atom feed
From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] ARM: zImage: Allow the appending of a device tree binary
Date: Wed, 14 Sep 2011 14:32:44 +0100	[thread overview]
Message-ID: <20110914133244.GE2104@arm.com> (raw)
In-Reply-To: <1315978906-15829-3-git-send-email-nico@fluxnic.net>

On Wed, Sep 14, 2011 at 01:41:42AM -0400, Nicolas Pitre wrote:
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
> 
> This patch provides the ability to boot using a device tree that is appended
> to the raw binary zImage (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
> 
> Signed-off-by: John Bonesio <bones@secretlab.ca>
> [nico: adjusted to latest zImage changes plus additional cleanups]
> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> Acked-by: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/Kconfig                |    8 ++++
>  arch/arm/boot/compressed/head.S |   70 +++++++++++++++++++++++++++++++++++++--
>  2 files changed, 75 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5ebc5d922e..83323c2b1f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1781,6 +1781,14 @@ config ZBOOT_ROM_SH_MOBILE_SDHI
>  
>  endchoice
>  
> +config ARM_APPENDED_DTB
> +	bool "Use appended device tree blob to zImage"
> +	depends on OF && !ZBOOT_ROM
> +	help
> +	  With this option, the boot code will look for a device tree binary
> +	  (dtb) appended to zImage
> +	  (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
> +
>  config CMDLINE
>  	string "Default kernel command string"
>  	default ""
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index e95a598960..3ce5738ddb 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -216,6 +216,59 @@ restart:	adr	r0, LC0
>  		mov	r10, r6
>  #endif
>  
> +		mov	r5, #0			@ init dtb size to 0
> +#ifdef CONFIG_ARM_APPENDED_DTB
> +/*
> + *   r0  = delta
> + *   r2  = BSS start
> + *   r3  = BSS end
> + *   r4  = final kernel address
> + *   r5  = appended dtb size (still unknown)
> + *   r6  = _edata
> + *   r7  = architecture ID
> + *   r8  = atags/device tree pointer
> + *   r9  = size of decompressed image
> + *   r10 = end of this image, including  bss/stack/malloc space if non XIP
> + *   r11 = GOT start
> + *   r12 = GOT end
> + *   sp  = stack pointer
> + *
> + * if there are device trees (dtb) appended to zImage, advance r10 so that the
> + * dtb data will get relocated along with the kernel if necessary.
> + */
> +
> +		ldr	lr, [r6, #0]
> +#ifndef __ARMEB__
> +		ldr	r1, =0xedfe0dd0		@ sig is 0xd00dfeed big endian
> +#else
> +		ldr	r1, =0xd00dfeed
> +#endif

Do we worry that garbage in memory after the zImage might match this
magic number?

For example, if an ordinary userspace program allocates a huge number
of pages and fills them with bogus device tree headers, is there a chance
that the those headers could remain in memory across a reboot?

In principle this could lead to a security hole on platforms where the
boot images don't append a device tree, by allowing an attacker to
override the bootargs etc.

I don't know whether this is exploitable in practice, but it's worth
thinking about (apologies if it's already been discussed)


A possible workaround is to put a relative pointer or a flag at the
start of the zImage, which we can poke with a non-zero value when
the device tree is appended.

This makes appending the device tree non-trivial, but it's still pretty
simple to do; something like:

$ echo 'boo' | dd bs=4 count=1 seek=4 conv=notrunc of=zImage
$ cat dtb >>zImage

(Where I assume that the affected word in the zImage is initially not
'boo').

Cheers
---Dave

  reply	other threads:[~2011-09-14 13:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-14  5:41 [PATCH 0/6] zImage improvements with DTB append and ATAG compatibility Nicolas Pitre
2011-09-14  5:41 ` [PATCH 1/6] ARM: zImage: ensure it is always a multiple of 64 bits in size Nicolas Pitre
2011-09-14  5:41 ` [PATCH 2/6] ARM: zImage: Allow the appending of a device tree binary Nicolas Pitre
2011-09-14 13:32   ` Dave Martin [this message]
2011-09-14 14:04     ` Nicolas Pitre
2011-09-14 14:20       ` Dave Martin
2011-09-14 15:10         ` Nicolas Pitre
2011-09-14 16:10           ` Dave Martin
2011-09-14  5:41 ` [PATCH 3/6] ARM: zImage: make sure appended DTB doesn't get overwritten by kernel .bss Nicolas Pitre
2011-09-14  5:41 ` [PATCH 4/6] ARM: zImage: gather some string functions into string.c Nicolas Pitre
2011-09-14 13:13   ` Dave Martin
2011-09-14 13:45     ` Nicolas Pitre
2011-09-14 14:23       ` Dave Martin
2011-09-14 14:43         ` Nicolas Pitre
2011-09-14  5:41 ` [PATCH 5/6] ARM: zImage: allow supplementing appended DTB with traditional ATAG data Nicolas Pitre
2011-09-14  5:41 ` [PATCH 6/6] ARM: zImage: prevent constant copy+rebuild of lib1funcs.S Nicolas Pitre
2011-09-16  3:58   ` Stephen Boyd
2011-09-16  4:48     ` Nicolas Pitre
2011-09-16  7:15     ` Russell King - ARM Linux
2011-09-16 17:20       ` Stephen Boyd
2011-09-14  8:54 ` [PATCH 0/6] zImage improvements with DTB append and ATAG compatibility Shawn Guo
2011-09-14 13:19 ` Dave Martin
2011-09-14 15:26 ` Thomas Abraham
2011-09-14 22:56 ` David Brown

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=20110914133244.GE2104@arm.com \
    --to=dave.martin@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.