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=-2.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 AC770C43334 for ; Tue, 4 Sep 2018 22:14:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6CC632075E for ; Tue, 4 Sep 2018 22:14:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6CC632075E 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 S1727580AbeIEClW (ORCPT ); Tue, 4 Sep 2018 22:41:22 -0400 Received: from mga09.intel.com ([134.134.136.24]:33782 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727553AbeIEClV (ORCPT ); Tue, 4 Sep 2018 22:41:21 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2018 15:14:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,330,1531810800"; d="scan'208";a="70343616" Received: from sai-dev-mach.sc.intel.com ([143.183.140.52]) by orsmga007.jf.intel.com with ESMTP; 04 Sep 2018 15:14:14 -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 V3 5/5] x86/efi: Introduce EFI_WARN_ON_ILLEGAL_ACCESS Date: Tue, 4 Sep 2018 15:12:29 -0700 Message-Id: <1536099149-12564-6-git-send-email-sai.praneeth.prakhya@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1536099149-12564-1-git-send-email-sai.praneeth.prakhya@intel.com> References: <1536099149-12564-1-git-send-email-sai.praneeth.prakhya@intel.com> 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 might access efi regions other than EFI_RUNTIME_SERVICES_ even after the kernel has assumed control of the platform. This violates UEFI specification. If selected, this debug option will print a warning message if the UEFI firmware tries to access any memory region which it shouldn't. Along with the warning, the efi page fault handler will also try to recover from the page fault triggered by the firmware so that the machine doesn't hang. 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 --- arch/x86/Kconfig | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f1dbb4ee19d7..7dc270c17d0b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1957,6 +1957,23 @@ config EFI_MIXED If unsure, say N. +config EFI_WARN_ON_ILLEGAL_ACCESS + bool "Warn about illegal memory accesses by firmware" if EXPERT + depends on EFI + help + Enable this debug feature so that the kernel can detect illegal + memory accesses by firmware and issue a warning. Also, + 1. If the illegally accessed region is any region other than + EFI_RUNTIME_SERVICES_, then the kernel freezes + efi_rts_wq and schedules a new process. Also, it disables EFI + Runtime Services, so that it will never again call buggy firmware. + 2. If the illegal access is by efi_reset_system(), then the + platform is rebooted through BIOS. + Please see the UEFI specification for details on the expectations + of memory usage. + + If unsure, say N. + config SECCOMP def_bool y prompt "Enable seccomp to safely compute untrusted bytecode" -- 2.7.4