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=-5.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,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 7309FECDE44 for ; Fri, 26 Oct 2018 21:40:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3DF562064C for ; Fri, 26 Oct 2018 21:40:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3DF562064C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728402AbeJ0GS7 (ORCPT ); Sat, 27 Oct 2018 02:18:59 -0400 Received: from mga06.intel.com ([134.134.136.31]:25644 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725782AbeJ0GS7 (ORCPT ); Sat, 27 Oct 2018 02:18:59 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 14:40:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,429,1534834800"; d="scan'208";a="91559240" Received: from sai-dev-mach.sc.intel.com ([143.183.140.153]) by FMSMGA003.fm.intel.com with ESMTP; 26 Oct 2018 14:40:19 -0700 From: Sai Praneeth Prakhya To: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org Cc: Sai Praneeth Prakhya , Borislav Petkov , Ingo Molnar , Andy Lutomirski , Dave Hansen , Bhupesh Sharma , Thomas Gleixner , Peter Zijlstra , Ard Biesheuvel Subject: [PATCH V2 0/2] Unmap EFI boot services code/data regions after boot. Date: Fri, 26 Oct 2018 14:38:43 -0700 Message-Id: <20181026213845.28166-1-sai.praneeth.prakhya@intel.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CC'ing x86 folks because this patch touches x86/mm which I am no expert of. [Copied from Patch 1] Ideally, after kernel assumes control of the platform, firmware shouldn't access EFI boot services code/data regions. But, it's noticed that this is not so true in many x86 platforms. Hence, during boot, kernel reserves EFI boot services code/data regions [1] and maps [2] them to efi_pgd so that call to set_virtual_address_map() doesn't fail. After returning from set_virtual_address_map(), kernel frees the reserved regions [3] but they still remain mapped. This means that any code that's running in efi_pgd address space (e.g: any EFI runtime service) would still be able to access EFI boot services code/data regions but the contents of these regions would have long been over written by someone else as they are freed by efi_free_boot_services(). So, it's important to unmap these regions. After unmapping EFI boot services code/data regions, any illegal access by buggy firmware to these regions would result in page fault which will be handled by efi specific fault handler. Unmapping EFI boot services code/data regions will result in clearing PAGE_PRESENT bit and it shouldn't bother L1TF cases because it's already handled by protnone_mask() at arch/x86/include/asm/pgtable-invert.h. [1] Please see efi_reserve_boot_services() [2] Please see efi_map_region() -> __map_region() [3] Please see efi_free_boot_services() Testing the patch set: ---------------------- 1. Download buggy firmware (which accesses boot regions even after kernel has booted) from here [1]. 2. Without the patch set, you shouldn't see any kernel warning/error messages (i.e. kernel allows accesses to EFI boot services code/data regions even after call to set_virtual_address_map()). 3. With the patch set, you should see a kernel warning about buggy firmware, efi_rts_wq beeing freezed and disabling runtime services forever. Please note that this patch will change kernel's existing behavior for some EFI runtime services but I think it's OK because kernel should have never allowed those accesses in the first place. Also please note that this patch set needs lot of real time trashing as I just tested it out with OVMF. Note: ----- Patch set based on "next" branch in efi tree. Changes from V1 -> v2: ---------------------- 1. Rewrite the cpa initializer in a more readable fashion. 2. Don't use cpa->pfn while unmapping, as it's not useful. 3. Unmap regions before freeing them up. 4. Fix spelling nits. Sai Praneeth (2): x86/efi: Unmap EFI boot services code/data regions from efi_pgd x86/efi: Move efi__boot_services() to arch/x86 arch/x86/include/asm/efi.h | 2 ++ arch/x86/include/asm/pgtable_types.h | 2 ++ arch/x86/mm/pageattr.c | 26 ++++++++++++++++++++++++++ arch/x86/platform/efi/efi.c | 2 ++ arch/x86/platform/efi/quirks.c | 25 +++++++++++++++++++++++++ include/linux/efi.h | 3 --- init/main.c | 4 ---- 7 files changed, 57 insertions(+), 7 deletions(-) Signed-off-by: Sai Praneeth Prakhya Cc: Borislav Petkov Cc: Ingo Molnar Cc: Andy Lutomirski Cc: Dave Hansen Cc: Bhupesh Sharma Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ard Biesheuvel -- 2.19.1