All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] arm64: enforce x1|x2|x3 == 0 upon kernel entry as per boot protocol
Date: Thu, 19 Mar 2015 13:36:12 +0000	[thread overview]
Message-ID: <20150319133612.GD18473@leverpostej> (raw)
In-Reply-To: <1426762852-13699-1-git-send-email-ard.biesheuvel@linaro.org>

On Thu, Mar 19, 2015 at 11:00:52AM +0000, Ard Biesheuvel wrote:
> According to the arm64 boot protocol, registers x1 to x3 should be
> zero upon kernel entry, and non-zero values are reserved for future
> use. This future use is going to be problematic if we never enforce
> the current rules, so start enforcing them now, by emitting a warning
> if non-zero values are detected.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/arm64/kernel/head.S  | 19 ++++++++++++++++++-
>  arch/arm64/kernel/setup.c | 10 ++++++++++
>  2 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index f5ac337f9598..1fdf42041f42 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -233,7 +233,7 @@ section_table:
>  #endif
>  
>  ENTRY(stext)
> -	mov	x21, x0				// x21=FDT
> +	bl	preserve_boot_args
>  	bl	el2_setup			// Drop to EL1, w20=cpu_boot_mode
>  	adrp	x24, __PHYS_OFFSET
>  	bl	set_cpu_boot_mode_flag
> @@ -253,6 +253,23 @@ ENTRY(stext)
>  ENDPROC(stext)
>  
>  /*
> + * Preserve the arguments passed by the bootloader in x0 .. x3
> + */
> +preserve_boot_args:
> +	mov	x21, x0				// x21=FDT
> +
> +	adr_l	x0, boot_args			// record the contents of
> +	stp	x21, x1, [x0]			// x0 .. x3 at kernel entry
> +	stp	x2, x3, [x0, #16]
> +
> +	dmb	sy				// needed before dc ivac with
> +						// MMU off
> +
> +	add	x1, x0, #0x20			// 4 x 8 bytes
> +	b	__inval_cache_range		// tail call
> +ENDPROC(preserve_boot_args)
> +
> +/*
>   * Determine validity of the x21 FDT pointer.
>   * The dtb must be 8-byte aligned and live in the first 512M of memory.
>   */
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 1783b38cf4c0..2f384019b201 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -115,6 +115,11 @@ void __init early_print(const char *str, ...)
>  	printk("%s", buf);
>  }
>  
> +/*
> + * The recorded values of x0 .. x3 upon kernel entry.
> + */
> +u64 __cacheline_aligned boot_args[4];

All the above looks correct to me.

> +
>  void __init smp_setup_processor_id(void)
>  {
>  	u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> @@ -412,6 +417,11 @@ void __init setup_arch(char **cmdline_p)
>  	conswitchp = &dummy_con;
>  #endif
>  #endif
> +	if (boot_args[1] || boot_args[2] || boot_args[3]) {
> +		pr_err("WARNING: boot protocol violation detected (x1 == %llx, x2 == %llx, x3 == %llx)\n",
> +			boot_args[1], boot_args[2], boot_args[3]);
> +		pr_err("WARNING: your bootloader may fail to load newer kernels\n");

If we ever decide to use x1-x3 for something, and try to boot an older
kernel, that warning is going to be a bit misleading. That could matter
for VMs where we're going to see old kernel images for a long time.

I would like the warning to mention that could be the case.

It would also be nice if the message were consistently spaced regardless
of the values of x1-x3, so we should zero-pad them (and as that takes a
resonable amount of space, let's give them a line each).

So could we change the warning to be something like:

	pr_err("WARNING: x1-x3 nonzero in violation of boot protocol:\n"
	       "\tx1: %016llx\n\tx2: %016llx\n\tx3: %016llx\n"
	       "This indicates a broken bootloader or old kernel\n",
	       boot_args[1], boot_args[2], boot_args[3]);

With that,

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks,
Mark.

  reply	other threads:[~2015-03-19 13:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 14:55 [PATCH v5 0/8] arm64: head.S cleanup Ard Biesheuvel
2015-03-18 14:55 ` [PATCH v5 1/8] arm64: Get rid of struct cpu_table Ard Biesheuvel
2015-03-18 16:11   ` Mark Rutland
2015-03-23 17:11   ` Suzuki K. Poulose
2015-03-23 17:38     ` Will Deacon
2015-03-23 17:41       ` Suzuki K. Poulose
2015-03-18 14:55 ` [PATCH v5 2/8] arm64: add macros for common adrp usages Ard Biesheuvel
2015-03-18 17:54   ` Mark Rutland
2015-03-18 17:56     ` Ard Biesheuvel
2015-03-18 18:05       ` Mark Rutland
2015-03-18 18:06         ` Ard Biesheuvel
2015-03-18 14:55 ` [PATCH v5 3/8] arm64: remove processor_id Ard Biesheuvel
2015-03-18 14:55 ` [PATCH v5 4/8] arm64: remove __switch_data object from head.S Ard Biesheuvel
2015-03-18 14:55 ` [PATCH v5 5/8] arm64: use PC-relative reference for secondary_holding_pen_release Ard Biesheuvel
2015-03-18 14:55 ` [PATCH v5 6/8] arm64: merge __enable_mmu and __turn_mmu_on Ard Biesheuvel
2015-03-18 14:55 ` [PATCH v5 7/8] arm64: remove __calc_phys_offset Ard Biesheuvel
2015-03-18 14:55 ` [PATCH v5 8/8] arm64: enforce x1|x2|x3 == 0 upon kernel entry as per boot protocol Ard Biesheuvel
2015-03-18 18:13   ` Mark Rutland
2015-03-18 18:16     ` Ard Biesheuvel
2015-03-18 18:46       ` Ard Biesheuvel
2015-03-18 18:57         ` Mark Rutland
2015-03-18 19:55           ` Ard Biesheuvel
2015-03-18 20:24             ` Mark Rutland
2015-03-19  7:30               ` Ard Biesheuvel
2015-03-19 10:35                 ` Mark Rutland
2015-03-19 10:38                   ` Ard Biesheuvel
2015-03-19 10:41                     ` Mark Rutland
2015-03-19 11:00                       ` [PATCH v3] " Ard Biesheuvel
2015-03-19 13:36                         ` Mark Rutland [this message]
2015-03-20 11:31                           ` Ard Biesheuvel
2015-03-20 11:41                             ` Mark Rutland
2015-03-20 11:45                               ` Ard Biesheuvel
2015-03-20 12:25                                 ` Will Deacon
2015-03-20 12:50                                   ` Ard Biesheuvel
2015-03-18 22:26           ` [PATCH v5 8/8] " Peter Maydell
2015-03-18 18:23 ` [PATCH v5 0/8] arm64: head.S cleanup Mark Rutland
2015-03-18 18:28   ` Ard Biesheuvel

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=20150319133612.GD18473@leverpostej \
    --to=mark.rutland@arm.com \
    --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.