From patchwork Thu Apr 9 13:04:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 206430 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, URIBL_BLOCKED, 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 15F63C2BBFD for ; Thu, 9 Apr 2020 13:05:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E14FC2083E for ; Thu, 9 Apr 2020 13:05:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586437504; bh=s0BcahdYY8q86hUtZsg5RZ5S4I6Vs3eEU8W8z2AxMt8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=bRXg7qY7eTE+BEvc1Q13bcwXk8no2QPcyivI2jgZ0pjBJT30uUIYtUqV+r2ny8y/v CbONjt9Xk5RqkCvf/gCnDcrWuLJqZvS71QnAihlCym1NTvb3eNdJC+fbvMPnN3sId+ b8tDK9wSuhGe3YU8YwkohgY0YunQVVQPgyVdQGcI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726723AbgDINFA (ORCPT ); Thu, 9 Apr 2020 09:05:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:43810 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726690AbgDINFA (ORCPT ); Thu, 9 Apr 2020 09:05:00 -0400 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 3C5532145D; Thu, 9 Apr 2020 13:04:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586437500; bh=s0BcahdYY8q86hUtZsg5RZ5S4I6Vs3eEU8W8z2AxMt8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J3E99niXy8+9vp7aIJal9abB2VG2QCunrWkzk43NjrJdglRTUPnav4OG95gSz0pfo +XcaZRXQhxjpnXFCxjMgVVbkIRC7sdAUc8vb24LTa7D7cbOP+1o60nAo8oqylZeMZR IX62zGTf3UhQ7BxCLEBLnKMuNVP1/fRH5gKJCRF0= From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, Arnd Bergmann , Arvind Sankar , Borislav Petkov , Colin Ian King , Gary Lin , Jiri Slaby , Sergey Shatunov , Takashi Iwai Subject: [PATCH 2/9] efi/libstub/x86: remove redundant assignment to pointer hdr Date: Thu, 9 Apr 2020 15:04:27 +0200 Message-Id: <20200409130434.6736-3-ardb@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200409130434.6736-1-ardb@kernel.org> References: <20200409130434.6736-1-ardb@kernel.org> Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org From: Colin Ian King The pointer hdr is being assigned a value that is never read and it is being updated later with a new value. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20200402102537.503103-1-colin.king@canonical.com Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/x86-stub.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c index 8d3a707789de..e02ea51273ff 100644 --- a/drivers/firmware/efi/libstub/x86-stub.c +++ b/drivers/firmware/efi/libstub/x86-stub.c @@ -392,8 +392,6 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle, image_base = efi_table_attr(image, image_base); image_offset = (void *)startup_32 - image_base; - hdr = &((struct boot_params *)image_base)->hdr; - status = efi_allocate_pages(0x4000, (unsigned long *)&boot_params, ULONG_MAX); if (status != EFI_SUCCESS) { efi_printk("Failed to allocate lowmem for boot params\n"); From patchwork Thu Apr 9 13:04:29 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 206429 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, URIBL_BLOCKED, 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 21644C352BE for ; Thu, 9 Apr 2020 13:05:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E973C2145D for ; Thu, 9 Apr 2020 13:05:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586437511; bh=ilS9Uh3RrYGVJaGs8AYWP2E9uj7DxanAuXoWfeQM8ZA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=WPqZNj+uOWJMG33PXvpGSfuJwhq4LcN2XK9kO9UAvPhF8Q/Uenp+L+OqihBEQT1So VSzvnpXtVKRXpSEvtSnhhRzxWQMFwI4jG+fuil/iSszZgPu4KoAUBKSu8N4SsUFL8a rvJ1MGXtWGyKMWspE0JTByoqeemUu6eYAQ1kupJY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726855AbgDINFG (ORCPT ); Thu, 9 Apr 2020 09:05:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:43916 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726690AbgDINFG (ORCPT ); Thu, 9 Apr 2020 09:05:06 -0400 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 D490721556; Thu, 9 Apr 2020 13:05:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586437506; bh=ilS9Uh3RrYGVJaGs8AYWP2E9uj7DxanAuXoWfeQM8ZA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SX96mAGFX6SqwnptbHoyyroFo+xTp8pvzuO1sa9LkgXzQSbg4bpoBIkPrbFqM16P5 SUleIfqb6MjNrJWpgtfuujELOEJQfRLJdtYgh9n5nXW83ZY6/wlEs7ddxIdPWxw6Cp 6RtL+GF+EyXbGF7yXRdZuAugQhLJfdve0eEclZLM= From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, Arnd Bergmann , Arvind Sankar , Borislav Petkov , Colin Ian King , Gary Lin , Jiri Slaby , Sergey Shatunov , Takashi Iwai Subject: [PATCH 4/9] efi/x86: Always relocate the kernel for EFI handover entry Date: Thu, 9 Apr 2020 15:04:29 +0200 Message-Id: <20200409130434.6736-5-ardb@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200409130434.6736-1-ardb@kernel.org> References: <20200409130434.6736-1-ardb@kernel.org> Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org From: Arvind Sankar Commit d5cdf4cfeac9 ("efi/x86: Don't relocate the kernel unless necessary") tries to avoid relocating the kernel in the EFI stub as far as possible. However, when systemd-boot is used to boot a unified kernel image [1], the image is constructed by embedding the bzImage as a .linux section in a PE executable that contains a small stub loader from systemd that will call the EFI stub handover entry, together with additional sections and potentially an initrd. When this image is constructed, by for example dracut, the initrd is placed after the bzImage without ensuring that at least init_size bytes are available for the bzImage. If the kernel is not relocated by the EFI stub, this could result in the compressed kernel's startup code in head_{32,64}.S overwriting the initrd. To prevent this, unconditionally relocate the kernel if the EFI stub was entered via the handover entry point. [1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images Signed-off-by: Arvind Sankar Reported-by: Sergey Shatunov Fixes: d5cdf4cfeac9 ("efi/x86: Don't relocate the kernel unless necessary") Link: https://lore.kernel.org/r/20200406180614.429454-2-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/x86-stub.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c index 867a57e28980..05ccb229fb45 100644 --- a/drivers/firmware/efi/libstub/x86-stub.c +++ b/drivers/firmware/efi/libstub/x86-stub.c @@ -740,8 +740,15 @@ unsigned long efi_main(efi_handle_t handle, * now use KERNEL_IMAGE_SIZE, which will be 512MiB, the same as what * KASLR uses. * - * Also relocate it if image_offset is zero, i.e. we weren't loaded by - * LoadImage, but we are not aligned correctly. + * Also relocate it if image_offset is zero, i.e. the kernel wasn't + * loaded by LoadImage, but rather by a bootloader that called the + * handover entry. The reason we must always relocate in this case is + * to handle the case of systemd-boot booting a unified kernel image, + * which is a PE executable that contains the bzImage and an initrd as + * COFF sections. The initrd section is placed after the bzImage + * without ensuring that there are at least init_size bytes available + * for the bzImage, and thus the compressed kernel's startup code may + * overwrite the initrd unless it is moved out of the way. */ buffer_start = ALIGN(bzimage_addr - image_offset, @@ -751,8 +758,7 @@ unsigned long efi_main(efi_handle_t handle, if ((buffer_start < LOAD_PHYSICAL_ADDR) || (IS_ENABLED(CONFIG_X86_32) && buffer_end > KERNEL_IMAGE_SIZE) || (IS_ENABLED(CONFIG_X86_64) && buffer_end > MAXMEM_X86_64_4LEVEL) || - (image_offset == 0 && !IS_ALIGNED(bzimage_addr, - hdr->kernel_alignment))) { + (image_offset == 0)) { status = efi_relocate_kernel(&bzimage_addr, hdr->init_size, hdr->init_size, hdr->pref_address, From patchwork Thu Apr 9 13:04:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 206428 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, URIBL_BLOCKED, 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 D90B4C38A24 for ; Thu, 9 Apr 2020 13:05:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B1001214DB for ; Thu, 9 Apr 2020 13:05:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586437519; bh=U7IetTerUYNpcR10zlJAkIrjjq2uos2SYYzL0HOR3ec=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=RwT25FKLSssJsR/bYBYSSzbEIEF+4Rx5uP0yrydEB7GUk20HU7NNdrqyroP8YXmEs mKBZ7op6p7tDOSW0I9nNrbbNqxQ2wzVR8h8kW70/V6B2u6E36D7MNVFN2BX3v2VRaj Cpn4ZtvXSsVxWjXntYqRUdy5M5U7l0DxY7dOwGr0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726894AbgDINFP (ORCPT ); Thu, 9 Apr 2020 09:05:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:44108 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726890AbgDINFO (ORCPT ); Thu, 9 Apr 2020 09:05:14 -0400 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 4A15B2145D; Thu, 9 Apr 2020 13:05:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586437514; bh=U7IetTerUYNpcR10zlJAkIrjjq2uos2SYYzL0HOR3ec=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xVivXXWyqayWq6D9G+GLJSsib5ank0YIP/DlXzSb3ojl9NUp29WtTFoTRjchC+1/w A28mpGBqaNA2Ho+J+3n77Wx/iwLrbFCH9nbhcihRObyk4M6yxnpXrPRX4CQSUuW4+l k3HlNVVBXb1Jhla4DRwvTMZyM51y1pURzKWFi2mc= From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, Arnd Bergmann , Arvind Sankar , Borislav Petkov , Colin Ian King , Gary Lin , Jiri Slaby , Sergey Shatunov , Takashi Iwai Subject: [PATCH 7/9] efi/libstub/file: merge filename buffers to reduce stack usage Date: Thu, 9 Apr 2020 15:04:32 +0200 Message-Id: <20200409130434.6736-8-ardb@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200409130434.6736-1-ardb@kernel.org> References: <20200409130434.6736-1-ardb@kernel.org> Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Arnd reports that commit 9302c1bb8e47 ("efi/libstub: Rewrite file I/O routine") reworks the file I/O routines in a way that triggers the following warning: drivers/firmware/efi/libstub/file.c:240:1: warning: the frame size of 1200 bytes is larger than 1024 bytes [-Wframe-larger-than=] We can work around this issue dropping an instance of efi_char16_t[256] from the stack frame, and reusing the 'filename' field of the file info struct that we use to obtain file information from EFI (which contains the filename even though we already know it since we used it to open the file in the first place) Reported-by: Arnd Bergmann Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/file.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/drivers/firmware/efi/libstub/file.c b/drivers/firmware/efi/libstub/file.c index d4c7e5f59d2c..ea66b1f16a79 100644 --- a/drivers/firmware/efi/libstub/file.c +++ b/drivers/firmware/efi/libstub/file.c @@ -29,30 +29,31 @@ */ #define EFI_READ_CHUNK_SIZE SZ_1M +struct finfo { + efi_file_info_t info; + efi_char16_t filename[MAX_FILENAME_SIZE]; +}; + static efi_status_t efi_open_file(efi_file_protocol_t *volume, - efi_char16_t *filename_16, + struct finfo *fi, efi_file_protocol_t **handle, unsigned long *file_size) { - struct { - efi_file_info_t info; - efi_char16_t filename[MAX_FILENAME_SIZE]; - } finfo; efi_guid_t info_guid = EFI_FILE_INFO_ID; efi_file_protocol_t *fh; unsigned long info_sz; efi_status_t status; - status = volume->open(volume, &fh, filename_16, EFI_FILE_MODE_READ, 0); + status = volume->open(volume, &fh, fi->filename, EFI_FILE_MODE_READ, 0); if (status != EFI_SUCCESS) { pr_efi_err("Failed to open file: "); - efi_char16_printk(filename_16); + efi_char16_printk(fi->filename); efi_printk("\n"); return status; } - info_sz = sizeof(finfo); - status = fh->get_info(fh, &info_guid, &info_sz, &finfo); + info_sz = sizeof(struct finfo); + status = fh->get_info(fh, &info_guid, &info_sz, fi); if (status != EFI_SUCCESS) { pr_efi_err("Failed to get file info\n"); fh->close(fh); @@ -60,7 +61,7 @@ static efi_status_t efi_open_file(efi_file_protocol_t *volume, } *handle = fh; - *file_size = finfo.info.file_size; + *file_size = fi->info.file_size; return EFI_SUCCESS; } @@ -146,13 +147,13 @@ static efi_status_t handle_cmdline_files(efi_loaded_image_t *image, alloc_addr = alloc_size = 0; do { - efi_char16_t filename[MAX_FILENAME_SIZE]; + struct finfo fi; unsigned long size; void *addr; offset = find_file_option(cmdline, cmdline_len, optstr, optstr_size, - filename, ARRAY_SIZE(filename)); + fi.filename, ARRAY_SIZE(fi.filename)); if (!offset) break; @@ -166,7 +167,7 @@ static efi_status_t handle_cmdline_files(efi_loaded_image_t *image, return status; } - status = efi_open_file(volume, filename, &file, &size); + status = efi_open_file(volume, &fi, &file, &size); if (status != EFI_SUCCESS) goto err_close_volume; From patchwork Thu Apr 9 13:04:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 206427 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,URIBL_BLOCKED,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 CFA57C38A24 for ; Thu, 9 Apr 2020 13:05:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A0B3C2145D for ; Thu, 9 Apr 2020 13:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586437522; bh=qZCGqLyDsrfWvTIBZIFUaR8x9EPxCLTQDYBA4Nrfm2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=NpwYK5CJL9+a83Dpl78uiEIcN4fZAKR5nChj+OW5/kzP2XxmtSIxsH7iYZlcu/DKq SgbhI+FUZKEjaly9s5SiT2yNDfc82sWQmsa8dtV8RDpu4QR1OaeOPg2iPOaNy+v1di TuDhyHxAJD+rJpsJcvJf/mIjnivBy8OSDutWSTXs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726908AbgDINFV (ORCPT ); Thu, 9 Apr 2020 09:05:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:44238 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726890AbgDINFU (ORCPT ); Thu, 9 Apr 2020 09:05:20 -0400 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 DD3762083E; Thu, 9 Apr 2020 13:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586437520; bh=qZCGqLyDsrfWvTIBZIFUaR8x9EPxCLTQDYBA4Nrfm2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fOMA3Q/mK1X8bDIQ+0ZRU7tylCDlsiuObwFpiFlS5z1I71NcsaOXh0H2Zwf5CbPAy +paleQA0IGfdtxP4WZ+yJowXMgfgtaqtcnjQ4Ql1tupFurzvr1UUjmob+Kqvfc4XY7 zSRffMajdRpGfpe6Oxhg3fdrEp8Vk8g9GK7oE0q8= From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, Arnd Bergmann , Arvind Sankar , Borislav Petkov , Colin Ian King , Gary Lin , Jiri Slaby , Sergey Shatunov , Takashi Iwai Subject: [PATCH 9/9] efi/x86: Don't remap text<->rodata gap read-only for mixed mode Date: Thu, 9 Apr 2020 15:04:34 +0200 Message-Id: <20200409130434.6736-10-ardb@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200409130434.6736-1-ardb@kernel.org> References: <20200409130434.6736-1-ardb@kernel.org> Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Commit d9e3d2c4f10320 ("efi/x86: Don't map the entire kernel text RW for mixed mode") updated the code that creates the 1:1 memory mapping to use read-only attributes for the 1:1 alias of the kernel's text and rodata sections, to protect it from inadvertent modification. However, it failed to take into account that the unused gap between text and rodata is given to the page allocator for general use. If the vmap'ed stack happens to be allocated from this region, any by-ref output arguments passed to EFI runtime services that are allocated on the stack (such as the 'datasize' argument taken by GetVariable() when invoked from efivar_entry_size()) will be referenced via a read-only mapping, resulting in a page fault if the EFI code tries to write to it: BUG: unable to handle page fault for address: 00000000386aae88 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fd61063 P4D fd61063 PUD fd62063 PMD 386000e1 Oops: 0003 [#1] SMP PTI CPU: 2 PID: 255 Comm: systemd-sysv-ge Not tainted 5.6.0-rc4-default+ #22 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0008:0x3eaeed95 Code: ... <89> 03 be 05 00 00 80 a1 74 63 b1 3e 83 c0 48 e8 44 d2 ff ff eb 05 RSP: 0018:000000000fd73fa0 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 00000000386aae88 RCX: 000000003e9f1120 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 000000000fd73fd8 R08: 00000000386aae88 R09: 0000000000000000 R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 R13: ffffc0f040220000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f21160ac940(0000) GS:ffff9cf23d500000(0000) knlGS:0000000000000000 CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 CR2: 00000000386aae88 CR3: 000000000fd6c004 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: Modules linked in: CR2: 00000000386aae88 ---[ end trace a8bfbd202e712834 ]--- Let's fix this by remapping text and rodata individually, and leave the gaps mapped read-write. Fixes: d9e3d2c4f10320 ("efi/x86: Don't map the entire kernel text RW for mixed mode") Reported-by: Jiri Slaby Tested-by: Jiri Slaby Signed-off-by: Ard Biesheuvel --- arch/x86/platform/efi/efi_64.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c index e0e2e8136cf5..c5e393f8bb3f 100644 --- a/arch/x86/platform/efi/efi_64.c +++ b/arch/x86/platform/efi/efi_64.c @@ -202,7 +202,7 @@ virt_to_phys_or_null_size(void *va, unsigned long size) int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) { - unsigned long pfn, text, pf; + unsigned long pfn, text, pf, rodata; struct page *page; unsigned npages; pgd_t *pgd = efi_mm.pgd; @@ -256,7 +256,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) efi_scratch.phys_stack = page_to_phys(page + 1); /* stack grows down */ - npages = (__end_rodata_aligned - _text) >> PAGE_SHIFT; + npages = (_etext - _text) >> PAGE_SHIFT; text = __pa(_text); pfn = text >> PAGE_SHIFT; @@ -266,6 +266,14 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) return 1; } + npages = (__end_rodata - __start_rodata) >> PAGE_SHIFT; + rodata = __pa(__start_rodata); + pfn = rodata >> PAGE_SHIFT; + if (kernel_map_pages_in_pgd(pgd, pfn, rodata, npages, pf)) { + pr_err("Failed to map kernel rodata 1:1\n"); + return 1; + } + return 0; }