public inbox for linux-arm-kernel@lists.infradead.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: Fri, 20 Mar 2015 11:41:42 +0000	[thread overview]
Message-ID: <20150320114142.GF14766@leverpostej> (raw)
In-Reply-To: <CAKv+Gu-=n8fbdFeZX=EEpLypOdu0xXePzXH4-gOn6SqufA6CGg@mail.gmail.com>

> >> +     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]);
> >
> 
> OK, I have applied this change.
> 
> But I would like to note that we should probably only extend the boot
> protocol in a way that would not trigger this on older kernels in the
> first place.
> I.e., assign a bit in the flags field in the header, which indicates
> whether some boot protocol enhancement is supported by the kernel
> being loaded, and only allow x1/x2/x3 to be non-zero if said
> enhancement defines that.

Good point.

Given that, if you want to restore your original last line, that would
be fine with me (and my Ack still applies).

Mark.

  reply	other threads:[~2015-03-20 11:41 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
2015-03-20 11:31                           ` Ard Biesheuvel
2015-03-20 11:41                             ` Mark Rutland [this message]
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=20150320114142.GF14766@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