linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] arm64: enforce x1|x2|x3 == 0 upon kernel entry as per boot protocol
Date: Tue, 17 Mar 2015 13:25:31 +0000	[thread overview]
Message-ID: <20150317132531.GD23340@leverpostej> (raw)
In-Reply-To: <1426587074-22390-4-git-send-email-ard.biesheuvel@linaro.org>

On Tue, Mar 17, 2015 at 10:11:14AM +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  |  8 ++++++++
>  arch/arm64/kernel/setup.c | 13 +++++++++++++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 1651c0fd50e6..fe5354eae069 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -231,6 +231,10 @@ section_table:
>  #endif
>  
>  ENTRY(stext)
> +	adr	x8, boot_regs			// record the contents of
> +	stp	x0, x1, [x8]			// x0 .. x3 at kernel entry
> +	stp	x2, x3, [x8, #16]

These accesses will be non-cacheable, but the caches could have clean
entries for this PA range.

Without an invalidate between the writes and reads, we might see stale
values (the other option is to preserve the registers across enabling
the MMU).

> +
>  	mov	x21, x0				// x21=FDT
>  	bl	el2_setup			// Drop to EL1, w20=cpu_boot_mode
>  	adrp	x24, KERNEL_START - TEXT_OFFSET	// x24=PHYS_OFFSET
> @@ -251,6 +255,10 @@ ENTRY(stext)
>  	b	__cpu_setup			// initialise processor
>  ENDPROC(stext)
>  
> +	.align	3
> +ENTRY(boot_regs)
> +	.skip	4 * 8				// x0 .. x3

Can't we can drop this here...

> +
>  /*
>   * 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 6c5fb5aff325..2b81d0a907ce 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -532,3 +532,16 @@ const struct seq_operations cpuinfo_op = {
>  	.stop	= c_stop,
>  	.show	= c_show
>  };

... and here have

u64 boot_regs[4];

Using adrp + lo12 to address the symbol?

> +
> +static int verify_boot_protocol(void)
> +{
> +	extern u64 boot_regs[];
> +
> +	if (boot_regs[1] || boot_regs[2] || boot_regs[3]) {
> +		pr_err("WARNING: boot protocol violation detected (x1 == %llx, x2 == %llx, x3 == %llx)\n",
> +			boot_regs[1], boot_regs[2], boot_regs[3]);
> +		pr_err("WARNING: your bootloader may fail to load newer kernels\n");
> +	}
> +	return 0;
> +}
> +late_initcall(verify_boot_protocol);

I think it would be nicer to plumb this into setup_arch rather than an
initcall. That way the warning will be at a consistent, prominent
location in the log.

Thanks,
Mark.

  reply	other threads:[~2015-03-17 13:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17 10:11 [PATCH 0/3] more arm64 early boot stuff Ard Biesheuvel
2015-03-17 10:11 ` [PATCH 1/3] arm64: merge __enable_mmu and __turn_mmu_on Ard Biesheuvel
2015-03-17 13:51   ` Mark Rutland
2015-03-17 17:39   ` Christopher Covington
2015-03-18  7:47     ` Ard Biesheuvel
2015-03-18 12:09       ` Mark Rutland
2015-03-17 10:11 ` [PATCH 2/3] arm64: remove __calc_phys_offset Ard Biesheuvel
2015-03-17 14:46   ` Mark Rutland
2015-03-18  7:49     ` Ard Biesheuvel
2015-03-18 12:08       ` Mark Rutland
2015-03-17 10:11 ` [PATCH 3/3] arm64: enforce x1|x2|x3 == 0 upon kernel entry as per boot protocol Ard Biesheuvel
2015-03-17 13:25   ` Mark Rutland [this message]
2015-03-17 17:47   ` Christopher Covington
2015-03-18  7:49     ` 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=20150317132531.GD23340@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 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).