From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 470B3C34037 for ; Tue, 18 Feb 2020 11:34:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 18E4122527 for ; Tue, 18 Feb 2020 11:34:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582025654; bh=AdgygElFjm+9+VrUlac437cYd/rQkrwPTj+u9i3/SSw=; h=From:To:Cc:Subject:Date:List-ID:From; b=L3h8+ShGdElAClOhBURQI7ndNTbIGSqwpwXbwF9aav8isQUNhPPGozW3TkycXk9zd xNVmaumC0dSs25SK5CtAL8fRVCXablgV1dFP2FIiZnkhlgcx3xVzopZTesHvpEm/zD bKW49tnMd5aDTs6x4KoEMOBMZjvrALaQtY0LBIFo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726347AbgBRLeN (ORCPT ); Tue, 18 Feb 2020 06:34:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:43640 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726338AbgBRLeN (ORCPT ); Tue, 18 Feb 2020 06:34:13 -0500 Received: from e123331-lin.home (amontpellier-657-1-18-247.w109-210.abo.wanadoo.fr [109.210.65.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E75D121D56; Tue, 18 Feb 2020 11:34:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582025653; bh=AdgygElFjm+9+VrUlac437cYd/rQkrwPTj+u9i3/SSw=; h=From:To:Cc:Subject:Date:From; b=SE1sAy3CDFfufWhk8g9D3KU1M8JIQb7e3vt/C3wWuSkCDeWCBcu/Aqz9xvmSK/2Bm hzjaFn8ZepB6CGmDumIEYq1aI6ejIzHNqCGEqr/35jgOzj2WkPU3afk4ETjiJ9Zi5f Mqo33c+TL85bMcGGOrU2474Iq8ItVxsfpv5nMrOg= From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, maz@kernel.org, ilias.apalodimas@linaro.org, Ard Biesheuvel Subject: [PATCH] efi/arm: work around missing cache maintenance in decompressor handover Date: Tue, 18 Feb 2020 12:34:05 +0100 Message-Id: <20200218113405.31342-1-ardb@kernel.org> X-Mailer: git-send-email 2.17.1 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.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 --- arch/arm/boot/compressed/head.S | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 088b0a060876..4010f6e4b047 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -1458,6 +1458,18 @@ ENTRY(efi_stub_entry) cmn r0, #1 beq efi_load_fail + @ 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 it before proceeding. + ldr lr, [sp] @ relocated zImage + ldr ip, 0f + sub lr, lr, ip + mov pc, lr @ no mode switch + .align 2 +0: .long start - (. + 4) + @ Preserve return value of efi_entry() in r4 mov r4, r0 bl cache_clean_flush @@ -1469,12 +1481,7 @@ 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. -- 2.17.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 969CAC34026 for ; Tue, 18 Feb 2020 11:34:19 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 68AB121D56 for ; Tue, 18 Feb 2020 11:34:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="X+qZVXsK"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="SE1sAy3C" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68AB121D56 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=9Wi9sz0Hl82ksHNOCMIpGmrq6Tb97DX2Gokd/bZvN8g=; b=X+q ZVXsKUWQ8C337krWJiUpwxo0HCk8748Zois3sHpdahonC2BzkTECy8Og9ZAiKhSYqMV208ChAx/Jd 7TIUADCIi8J2jrAKPnTv54lg18pbYGd1sM7Y9xivwhymoMNvD7Ts23De+bbFa1jSxi9dWLXcxsAww X5hIRiBRsi00OpVk0PCmbp59NnMDlEEEMJDcL4q2mc9y0kMHSsm6t/2JgyhsnXKjQwe2TgWn3e5xg TFDTWOVWHBTvaWDP+GT24YNq2hH9qnRZrIsglqlZkp2kLptyGrVzOWOdLnGGPD15FT9Wg1nhaHntP Gj8aj12ROmET7EvnWmn9ZuZa0GUdBRw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j418q-0006lX-5Y; Tue, 18 Feb 2020 11:34:16 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j418n-0006kz-EB for linux-arm-kernel@lists.infradead.org; Tue, 18 Feb 2020 11:34:14 +0000 Received: from e123331-lin.home (amontpellier-657-1-18-247.w109-210.abo.wanadoo.fr [109.210.65.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E75D121D56; Tue, 18 Feb 2020 11:34:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582025653; bh=AdgygElFjm+9+VrUlac437cYd/rQkrwPTj+u9i3/SSw=; h=From:To:Cc:Subject:Date:From; b=SE1sAy3CDFfufWhk8g9D3KU1M8JIQb7e3vt/C3wWuSkCDeWCBcu/Aqz9xvmSK/2Bm hzjaFn8ZepB6CGmDumIEYq1aI6ejIzHNqCGEqr/35jgOzj2WkPU3afk4ETjiJ9Zi5f Mqo33c+TL85bMcGGOrU2474Iq8ItVxsfpv5nMrOg= From: Ard Biesheuvel To: linux-efi@vger.kernel.org Subject: [PATCH] efi/arm: work around missing cache maintenance in decompressor handover Date: Tue, 18 Feb 2020 12:34:05 +0100 Message-Id: <20200218113405.31342-1-ardb@kernel.org> X-Mailer: git-send-email 2.17.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200218_033413_505366_3CE63FCB X-CRM114-Status: GOOD ( 12.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: maz@kernel.org, ilias.apalodimas@linaro.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.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 --- arch/arm/boot/compressed/head.S | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 088b0a060876..4010f6e4b047 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -1458,6 +1458,18 @@ ENTRY(efi_stub_entry) cmn r0, #1 beq efi_load_fail + @ 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 it before proceeding. + ldr lr, [sp] @ relocated zImage + ldr ip, 0f + sub lr, lr, ip + mov pc, lr @ no mode switch + .align 2 +0: .long start - (. + 4) + @ Preserve return value of efi_entry() in r4 mov r4, r0 bl cache_clean_flush @@ -1469,12 +1481,7 @@ 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. -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel