From: Ard Biesheuvel <ardb@kernel.org> To: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>, Russell King <linux@armlinux.org.uk>, Marc Zyngier <maz@kernel.org>, Nicolas Pitre <nico@fluxnic.net>, Catalin Marinas <catalin.marinas@arm.com>, Tony Lindgren <tony@atomide.com>, Linus Walleij <linus.walleij@linaro.org> Subject: [PATCH v4 1/5] efi/arm: Work around missing cache maintenance in decompressor handover Date: Wed, 26 Feb 2020 17:57:34 +0100 [thread overview] Message-ID: <20200226165738.11201-2-ardb@kernel.org> (raw) In-Reply-To: <20200226165738.11201-1-ardb@kernel.org> The EFI stub executes within the context of the zImage as it was loaded by the firmware, which means it is treated as an ordinary PE/COFF executable, which is loaded into memory, and cleaned to the PoU to ensure that it can be executed safely while the MMU and caches are on. When the EFI stub hands over to the decompressor, we clean the caches by set/way and disable the MMU and D-cache, to comply with the Linux boot protocol for ARM. However, cache maintenance by set/way is not sufficient to ensure that subsequent instruction fetches and data accesses done with the MMU off see the correct data. This means that proceeding as we do currently is not safe, especially since we also perform data accesses with the MMU off, from a literal pool as well as the stack. So let's kick this can down the road a bit, and jump into the relocated zImage before disabling the caches. This removes the requirement to perform any by-VA cache maintenance on the original PE/COFF executable, but it does require that the relocated zImage is cleaned to the PoC, which is currently not the case. This will be addressed in a subsequent patch. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm/boot/compressed/head.S | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 088b0a060876..39f7071d47c7 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -1461,6 +1461,17 @@ ENTRY(efi_stub_entry) @ Preserve return value of efi_entry() in r4 mov r4, r0 bl cache_clean_flush + + @ The PE/COFF loader might not have cleaned the code we are + @ running beyond the PoU, and so calling cache_off below from + @ inside the PE/COFF loader allocated region is unsafe. Let's + @ assume our own zImage relocation code did a better job, and + @ jump into its version of this routine before proceeding. + ldr r0, [sp] @ relocated zImage + ldr r1, .Ljmp + sub r1, r0, r1 + mov pc, r1 @ no mode switch +0: bl cache_off @ Set parameters for booting zImage according to boot protocol @@ -1469,18 +1480,15 @@ ENTRY(efi_stub_entry) mov r0, #0 mov r1, #0xFFFFFFFF mov r2, r4 - - @ Branch to (possibly) relocated zImage that is in [sp] - ldr lr, [sp] - ldr ip, =start_offset - add lr, lr, ip - mov pc, lr @ no mode switch + b __efi_start efi_load_fail: @ Return EFI_LOAD_ERROR to EFI firmware on error. ldr r0, =0x80000001 ldmfd sp!, {ip, pc} ENDPROC(efi_stub_entry) + .align 2 +.Ljmp: .long start - 0b #endif .align -- 2.17.1
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org> To: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org, Nicolas Pitre <nico@fluxnic.net>, Tony Lindgren <tony@atomide.com>, Marc Zyngier <maz@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Ard Biesheuvel <ardb@kernel.org> Subject: [PATCH v4 1/5] efi/arm: Work around missing cache maintenance in decompressor handover Date: Wed, 26 Feb 2020 17:57:34 +0100 [thread overview] Message-ID: <20200226165738.11201-2-ardb@kernel.org> (raw) In-Reply-To: <20200226165738.11201-1-ardb@kernel.org> The EFI stub executes within the context of the zImage as it was loaded by the firmware, which means it is treated as an ordinary PE/COFF executable, which is loaded into memory, and cleaned to the PoU to ensure that it can be executed safely while the MMU and caches are on. When the EFI stub hands over to the decompressor, we clean the caches by set/way and disable the MMU and D-cache, to comply with the Linux boot protocol for ARM. However, cache maintenance by set/way is not sufficient to ensure that subsequent instruction fetches and data accesses done with the MMU off see the correct data. This means that proceeding as we do currently is not safe, especially since we also perform data accesses with the MMU off, from a literal pool as well as the stack. So let's kick this can down the road a bit, and jump into the relocated zImage before disabling the caches. This removes the requirement to perform any by-VA cache maintenance on the original PE/COFF executable, but it does require that the relocated zImage is cleaned to the PoC, which is currently not the case. This will be addressed in a subsequent patch. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm/boot/compressed/head.S | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 088b0a060876..39f7071d47c7 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -1461,6 +1461,17 @@ ENTRY(efi_stub_entry) @ Preserve return value of efi_entry() in r4 mov r4, r0 bl cache_clean_flush + + @ The PE/COFF loader might not have cleaned the code we are + @ running beyond the PoU, and so calling cache_off below from + @ inside the PE/COFF loader allocated region is unsafe. Let's + @ assume our own zImage relocation code did a better job, and + @ jump into its version of this routine before proceeding. + ldr r0, [sp] @ relocated zImage + ldr r1, .Ljmp + sub r1, r0, r1 + mov pc, r1 @ no mode switch +0: bl cache_off @ Set parameters for booting zImage according to boot protocol @@ -1469,18 +1480,15 @@ ENTRY(efi_stub_entry) mov r0, #0 mov r1, #0xFFFFFFFF mov r2, r4 - - @ Branch to (possibly) relocated zImage that is in [sp] - ldr lr, [sp] - ldr ip, =start_offset - add lr, lr, ip - mov pc, lr @ no mode switch + b __efi_start efi_load_fail: @ Return EFI_LOAD_ERROR to EFI firmware on error. ldr r0, =0x80000001 ldmfd sp!, {ip, pc} ENDPROC(efi_stub_entry) + .align 2 +.Ljmp: .long start - 0b #endif .align -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-26 16:57 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-26 16:57 [PATCH v4 0/5] ARM: decompressor: use by-VA cache maintenance for v7 cores Ard Biesheuvel 2020-02-26 16:57 ` Ard Biesheuvel 2020-02-26 16:57 ` Ard Biesheuvel [this message] 2020-02-26 16:57 ` [PATCH v4 1/5] efi/arm: Work around missing cache maintenance in decompressor handover Ard Biesheuvel 2020-02-26 16:57 ` [PATCH v4 2/5] efi/arm: Pass start and end addresses to cache_clean_flush() Ard Biesheuvel 2020-02-26 16:57 ` Ard Biesheuvel 2020-02-26 16:57 ` [PATCH v4 3/5] ARM: decompressor: factor out routine to obtain the inflated image size Ard Biesheuvel 2020-02-26 16:57 ` Ard Biesheuvel 2020-02-26 16:57 ` [PATCH v4 4/5] ARM: decompressor: prepare cache_clean_flush for doing by-VA maintenance Ard Biesheuvel 2020-02-26 16:57 ` Ard Biesheuvel 2020-02-26 16:57 ` [PATCH v4 5/5] ARM: decompressor: switch to by-VA cache maintenance for v7 cores Ard Biesheuvel 2020-02-26 16:57 ` Ard Biesheuvel 2020-02-26 19:14 ` [PATCH v4 0/5] ARM: decompressor: use " Tony Lindgren 2020-02-26 19:14 ` Tony Lindgren 2020-02-27 10:11 ` Linus Walleij 2020-02-27 10:11 ` Linus Walleij 2020-02-27 16:01 ` Marc Zyngier 2020-02-27 16:01 ` Marc Zyngier 2020-02-27 16:47 ` Ard Biesheuvel 2020-02-27 16:47 ` Ard Biesheuvel 2020-02-27 16:53 ` Marc Zyngier 2020-02-27 16:53 ` Marc Zyngier
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=20200226165738.11201-2-ardb@kernel.org \ --to=ardb@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=maz@kernel.org \ --cc=nico@fluxnic.net \ --cc=tony@atomide.com \ /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: linkBe 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.