Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1152542imm; Thu, 6 Sep 2018 16:43:17 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZltBT6Tf9NQxuGbW/uHNzhU10q9iEziTOBFD92pbUXwu0AYe3CWsQNoqOrhBj1xeCXLgWe X-Received: by 2002:a62:490e:: with SMTP id w14-v6mr5497982pfa.213.1536277397371; Thu, 06 Sep 2018 16:43:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536277397; cv=none; d=google.com; s=arc-20160816; b=MUNgPda1TMNm7fFlXYqROnzz4i29cdpeZN+xCtohFnPuUIe+w7efLFVI0q+ZWNX2TT 51jgMLA/TOj4jVL6Jcrhr72LFDVL/RL7qRwRiZQrONVdmelni0njbX4RHr9mqxIscMMI 05p5av91r/BllRrCyz8xCI4m8XHGOcl6Pp7kjw8j6fAF4VkWoLF5fWzn1hqM+OYbltcs aCoCn5dvqThCiZ5+h4iy3mHfeKoBHudfJFEWt6IfUPXgTqbJfW/2jqeDttfMH/CDhnEp iVSfTRn6qNvzFHxGcojSJOlzY1NzVn6dg6dlT319cPgLLwDL9Xl5V+HFhf27NQFpMMgj bN7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=9F/VUinWx67WGdv6OIbzhVLAZnrJt8i2BxYyprqCXYw=; b=rLtmqAHs3owibAuOinLd0eX0nI3Y5TUVv8ZcOSx+xpS4E9uSK6oU7f6geKwCYWr+cG 1lJP0lDSa5gypFxyIFtz05OeraHBEMjpwgUOG/GTWkFiknIcnJ/fG4h+umEmfZYfOmjG yR4sosrQlTyrVwg3oO+Ge5H5kOT6TNkCevm5iP/SDVnR/2YURsafCXEFJ3Sw+TmpKaEV W0wwwzzLSDdKMpzzrVEgO7AWsiGk4I5Kim8HfCZHVLiaFhoVja3NZ/I7sUyM69d8WXZt 1d7AXUwaygNeGEltrkJd89Unt2he9yXmCewGf7LaKs6wMJAS9VfrL5eV9SvG52rJcbEG z4Mw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s126-v6si6886637pfc.222.2018.09.06.16.43.01; Thu, 06 Sep 2018 16:43:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726293AbeIGEGm (ORCPT + 99 others); Fri, 7 Sep 2018 00:06:42 -0400 Received: from mga05.intel.com ([192.55.52.43]:24972 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbeIGEGl (ORCPT ); Fri, 7 Sep 2018 00:06:41 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2018 16:28:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,339,1531810800"; d="scan'208";a="68154887" Received: from sai-dev-mach.sc.intel.com ([143.183.140.52]) by fmsmga007.fm.intel.com with ESMTP; 06 Sep 2018 16:28:51 -0700 From: Sai Praneeth Prakhya To: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org Cc: ricardo.neri@intel.com, matt@codeblueprint.co.uk, Sai Praneeth , Al Stone , Borislav Petkov , Ingo Molnar , Andy Lutomirski , Bhupesh Sharma , Thomas Gleixner , Peter Zijlstra , Ard Biesheuvel Subject: [PATCH V4 0/3] Add efi page fault handler to recover from page Date: Thu, 6 Sep 2018 16:27:45 -0700 Message-Id: <1536276468-28499-1-git-send-email-sai.praneeth.prakhya@intel.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sai Praneeth There may exist some buggy UEFI firmware implementations that access efi memory regions other than EFI_RUNTIME_SERVICES_ even after the kernel has assumed control of the platform. This violates UEFI specification. Hence, provide a debug config option which when enabled recovers from page faults caused by buggy firmware. Page faults triggered by firmware happen at ring 0 and if unhandled, hangs the kernel. So, provide an efi specific page fault handler to: 1. Avoid panics/hangs caused by buggy firmware. 2. Shout loud that the firmware is buggy and hence is not a kernel bug. The efi page fault handler will check if the access is by efi_reset_system(). 1. If so, then the efi page fault handler will reboot the machine through BIOS and not through efi_reset_system(). 2. If not, then the efi page fault handler will freeze efi_rts_wq and schedules a new process. This issue was reported by Al Stone when he saw that reboot via EFI hangs the machine. Upon debugging, I found that it's efi_reset_system() that's touching memory regions which it shouldn't. To reproduce the same behavior, I have hacked OVMF and made efi_reset_system() buggy. Along with efi_reset_system(), I have also modified get_next_high_mono_count() and set_virtual_address_map(). They illegally access both boot time and other efi regions. Testing the patch set: ---------------------- 1. Download buggy firmware from here [1]. 2. Run a qemu instance with this buggy BIOS and boot mainline kernel. Add reboot=efi to the kernel command line arguments and after the kernel is up and running, type "reboot". The kernel should hang while rebooting. 3. With the same setup, boot kernel after applying patches and the reboot should work fine. Also please notice warning/error messages printed by kernel. Changes from RFC to V1: ----------------------- 1. Drop "long jump" technique of dealing with illegal access and instead use scheduling away from efi_rts_wq. Changes from V1 to V2: ---------------------- 1. Shortened config name to CONFIG_EFI_WARN_ON_ILLEGAL_ACCESS from CONFIG_EFI_WARN_ON_ILLEGAL_ACCESSES. 2. Made the config option available only to expert users. 3. efi_free_boot_services() should be called only when CONFIG_EFI_WARN_ON_ILLEGAL_ACCESS is not enabled. Previously, this was part of init/main.c file. As it is an architecture agnostic code, moved the change to arch/x86/platform/efi/quirks.c file. Changes from V2 to V3: ---------------------- 1. Drop treating illegal access to EFI_BOOT_SERVICES_ regions separatley from illegal accesses to other regions like EFI_CONVENTIONAL_MEMORY or EFI_LOADER_. In previous versions, illegal access to EFI_BOOT_SERVICES_ regions were handled by mapping requested region to efi_pgd but from V3 they are handled similar to illegal access to other regions i.e by freezing efi_rts_wq and scheduling new process. 2. Change __efi_init_fixup attribute to __efi_init. Changes from V3 to V4: ---------------------- 1. Drop saving original memory map passed by kernel. It also means less checks in efi page fault handler. 2. Change the config name to EFI_PAGE_FAULT_HANDLER to reflect it's functionality more appropriatley. Note: ----- Patch set based on "next" branch in efi tree. [1] https://drive.google.com/drive/folders/1VozKTms92ifyVHAT0ZDQe55ZYL1UE5wt Sai Praneeth (3): efi: Make efi_rts_work accessible to efi page fault handler x86/efi: Add efi page fault handler to recover from page faults caused by the firmware x86/efi: Introduce EFI_PAGE_FAULT_HANDLER arch/x86/Kconfig | 18 +++++++++ arch/x86/include/asm/efi.h | 9 +++++ arch/x86/mm/fault.c | 9 +++++ arch/x86/platform/efi/quirks.c | 70 +++++++++++++++++++++++++++++++++ drivers/firmware/efi/runtime-wrappers.c | 60 ++++++++-------------------- include/linux/efi.h | 37 +++++++++++++++++ 6 files changed, 159 insertions(+), 44 deletions(-) Suggested-by: Matt Fleming Based-on-code-from: Ricardo Neri Signed-off-by: Sai Praneeth Prakhya Cc: Al Stone Cc: Borislav Petkov Cc: Ingo Molnar Cc: Andy Lutomirski Cc: Bhupesh Sharma Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ard Biesheuvel -- 2.7.4