All of lore.kernel.org
 help / color / mirror / Atom feed
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 8/8] arm64: enforce x1|x2|x3 == 0 upon kernel entry as per boot protocol
Date: Wed, 18 Mar 2015 19:16:26 +0100	[thread overview]
Message-ID: <CAKv+Gu_Psdg1PGbW8mydKGGUvyW=F1D125VSTdABLQEOHMaTwQ@mail.gmail.com> (raw)
In-Reply-To: <20150318181315.GH19814@leverpostej>

On 18 March 2015 at 19:13, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Mar 18, 2015 at 02:55:27PM +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  |  4 ++++
>>  arch/arm64/kernel/setup.c | 15 +++++++++++++++
>>  2 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>> index a0fbd99efb89..8636c3cef006 100644
>> --- a/arch/arm64/kernel/head.S
>> +++ b/arch/arm64/kernel/head.S
>> @@ -233,6 +233,10 @@ section_table:
>>  #endif
>>
>>  ENTRY(stext)
>> +     adr_l   x8, boot_regs                   // record the contents of
>> +     stp     x0, x1, [x8]                    // x0 .. x3 at kernel entry
>> +     stp     x2, x3, [x8, #16]
>
> I think we should have a dc ivac here as we do for
> set_cpu_boot_mode_flag.
>
> That avoids a potential issue with boot_regs sharing a cacheline with
> data we write with the MMU on -- using __flush_dcache_area will result
> in a civac, so we could write back dirty data atop of the boot_regs if
> there were clean entries in the cache when we did the non-cacheable
> write.
>

Hmm, I wondered about that.

Could we instead just make it u64 __initconst boot_regs[] in setup.c ?

>> +
>>       mov     x21, x0                         // x21=FDT
>>       bl      el2_setup                       // Drop to EL1, w20=cpu_boot_mode
>>       adrp    x24, __PHYS_OFFSET
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index 6c5fb5aff325..2d5cae2de679 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -114,6 +114,11 @@ void __init early_print(const char *str, ...)
>>       printk("%s", buf);
>>  }
>>
>> +/*
>> + * The recorded values of x0 .. x3 upon kernel entry.
>> + */
>> +u64 __read_mostly boot_regs[4];
>> +
>>  void __init smp_setup_processor_id(void)
>>  {
>>       u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> @@ -387,6 +392,16 @@ void __init setup_arch(char **cmdline_p)
>>       conswitchp = &dummy_con;
>>  #endif
>>  #endif
>> +     /*
>> +      * boot_regs[] is written by the boot CPU with the caches off, so we
>> +      * need to ensure that we read the value from main memory
>> +      */
>> +     __flush_dcache_area(boot_regs, sizeof(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");
>> +     }
>>  }
>>
>>  static int __init arm64_device_init(void)
>> --
>> 1.8.3.2
>>
>>

  reply	other threads:[~2015-03-18 18:16 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 [this message]
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
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='CAKv+Gu_Psdg1PGbW8mydKGGUvyW=F1D125VSTdABLQEOHMaTwQ@mail.gmail.com' \
    --to=ard.biesheuvel@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.