Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3157813imm; Fri, 10 Aug 2018 04:54:07 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwRWzfBfD5TTIy/sdhSrwPD6pb7QZ/v2ULA8qk628Xpfs7GCZfdiAe3MhfXh4Mg50HjeE8O X-Received: by 2002:a17:902:4d45:: with SMTP id o5-v6mr5839207plh.78.1533902047415; Fri, 10 Aug 2018 04:54:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533902047; cv=none; d=google.com; s=arc-20160816; b=tTfVBsfOX6mcTH3NuT1K2e7E84EiNznvBgNsQ9F8nAz4o+PQ7Tki+KZL644LwaCaNh Cj/VkVFYlz8kB+EOGZmQH0sM1nkljJTmV0DnAjSf8kTGkt0/ZZHJ67vSYaBpxffYAXaW NuHh9WychpYSteNUSjUw6JWc5Or/hXWrbq8zzAUzgl/2U9khmBtqtT/Bg5LMCk8/fNTE ZkPdZfxoBDv4iNc2I0n4z7BXEisUWbsAaVCLzNfVZcRBR2FBllLeUmKyx45+TmBFWL8A 6xLWcpTkWcek8TfstvFTXh7d+PAC8W68qu7FbgVYTqtMGEMJqtvkRRDEwtLJau7izxSt eAgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=u2IyLpdGopqKzXGQndpXte/9NFuflj8xgQ6zzU1ZXTA=; b=ehw8AQTuvHGNROuK0jcoWHbX5w4TekpIPRdordTlwXbOMyFcnOV3nK7z5leYL2qwMa 1L+dKIzr8v5UjLEkzGfb7zVeHHCWc+OTpNGXuF3VcqPP4qoElC7NcRezF48bhwmBEeDy AXcRATXz541iDRxovUYySC+p1Owmw0lF8Dzc4L05hqJtGUki6s7y7aqgaNYwrpjCQRPM g5kLRbrSpb0mE2BkXABE8i+/S2iLKtnVusXZhKoR9iDHzRnkElN0/PmyS+7eu77IL4x6 qQwuJ/JaOKcipt6GsROghdu/qdEPWuYki6lqRlZKYpDH4llv8SJtkSUGX+SQPIEE6tgU D2kA== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n19-v6si7204532pgd.408.2018.08.10.04.53.52; Fri, 10 Aug 2018 04:54:07 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727698AbeHJOMO (ORCPT + 99 others); Fri, 10 Aug 2018 10:12:14 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:44406 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726181AbeHJOMN (ORCPT ); Fri, 10 Aug 2018 10:12:13 -0400 Received: by mail-lj1-f196.google.com with SMTP id q127-v6so6899674ljq.11 for ; Fri, 10 Aug 2018 04:42:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u2IyLpdGopqKzXGQndpXte/9NFuflj8xgQ6zzU1ZXTA=; b=AKDI3Ls3ep0ZhTlC6aZ6t+MDUhg3Yc6y05M1KNlWNVadOn4BI+251od/CnqK+jR2/V 2JKjxGMTN/r/8mk8Iyvudej3F1XAPn1n6xm9hx0hDTomeB+9Qz2PC+MnvR50WB8XRC/G He5a9J5vYesCzSmfA50N8EDJtCY2+lM/r47rJRDutMndurAvZ0Yi/DG+d/ZKCAJHcV80 96EvaLipBUjMN0YRtDV2ZZfI+vxR/79RPgRDOKY9Qa87xqR14jbm+Mtq4yZByI6bvCgZ HPYlzM78HGJfkm1HKP3yJxR9cUmP1w8Lu2W3cERSZEJ+GbbGhTZndHvldO4GnJuwUhtM N7xg== X-Gm-Message-State: AOUpUlHL0/VhQ09uUDEjy+t3sAltxylS6sl/w8P6+bOMyUkrYEPzKZ6P Vnyto7mXNaF7wy8Ou5P9vy1qlfmYA0Aq2/UKAnCpeA== X-Received: by 2002:a2e:9a95:: with SMTP id p21-v6mr4538806lji.60.1533901357863; Fri, 10 Aug 2018 04:42:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:81a:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 04:42:37 -0700 (PDT) In-Reply-To: <1533789077-16156-7-git-send-email-sai.praneeth.prakhya@intel.com> References: <1533789077-16156-1-git-send-email-sai.praneeth.prakhya@intel.com> <1533789077-16156-7-git-send-email-sai.praneeth.prakhya@intel.com> From: Bhupesh Sharma Date: Fri, 10 Aug 2018 17:12:37 +0530 Message-ID: Subject: Re: [PATCH V1 6/6] x86/efi: Introduce EFI_WARN_ON_ILLEGAL_ACCESSES To: Sai Praneeth Prakhya Cc: linux-efi@vger.kernel.org, Linux Kernel Mailing List , ricardo.ner@intel.com, Matt Fleming , Lee Chun-Yi , Al Stone , Borislav Petkov , Ingo Molnar , Andy Lutomirski , Peter Zijlstra , Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Sai, On Thu, Aug 9, 2018 at 10:01 AM, Sai Praneeth Prakhya wrote: > 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 > fixup/recover from the page fault triggered by the firmware so that the > machine doesn't hang. > > To support this feature, two changes should be made to the existing efi > subsystem > 1. Map EFI_BOOT_SERVICES_ regions only when > EFI_WARN_ON_ILLEGAL_ACCESSES is disabled > Presently, the kernel maps EFI_BOOT_SERVICES_ regions as > a workaround for buggy firmware that accesses them even when they > shouldn't. With EFI_WARN_ON_ILLEGAL_ACCESSES enabled (and hence efi > page fault handler) kernel can now detect and handle such accesses > dynamically. Hence, rather than safely mapping > EFI_BOOT_SERVICES_ regions *all* the time, map them on > demand. > > 2. If EFI_WARN_ON_ILLEGAL_ACCESSES is enabled don't call > efi_free_boot_services() > Presently, during early boot phase EFI_BOOT_SERVICES_ > regions are marked as reserved by kernel > (see efi_reserve_boot_services()) and are freed before entering > runtime (see efi_free_boot_services()). But, while dynamically > fixing page faults caused by the firmware, efi page fault handler > assumes that EFI_BOOT_SERVICES_ regions are still intact. > Hence, to make this assumption true, don't call > efi_free_boot_services() if EFI_WARN_ON_ILLEGAL_ACCESSES is enabled. > > Suggested-by: Matt Fleming > Based-on-code-from: Ricardo Neri > Signed-off-by: Sai Praneeth Prakhya > Cc: Lee Chun-Yi > Cc: Al Stone > Cc: Borislav Petkov > Cc: Ingo Molnar > Cc: Andy Lutomirski > Cc: Bhupesh Sharma > Cc: Peter Zijlstra > Cc: Ard Biesheuvel > --- > arch/x86/Kconfig | 21 +++++++++++++++++++++ > arch/x86/platform/efi/efi.c | 4 ++++ > init/main.c | 3 ++- > 3 files changed, 27 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index f1dbb4ee19d7..278e5820e8dd 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1957,6 +1957,27 @@ config EFI_MIXED > > If unsure, say N. > > +config EFI_WARN_ON_ILLEGAL_ACCESSES How about shortening the name to just 'EFI_WARN_ON_ILLEGAL_ACCESS'? > + bool "Warn about illegal memory accesses by firmware" > + depends on EFI From a distribution p-o-v, I would suggest that we set this CONFIG option only if we are in the EXPERT mode, as this need more thrashing with the behaviour we see on old, buggy EFI firmwares available on very old x86 machines. So something like: bool "Warn about illegal memory accesses by firmware" if EXPERT > + 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 EFI_BOOT_SERVICES_, > + the kernel fixes it up by mapping the requested region. > + 2. If the illegally accessed region is any other region (Eg: > + EFI_CONVENTIONAL_MEMORY or EFI_LOADER_), 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. > + 3. If the access is to any other efi region like above but if the > + buggy efi runtime service is 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" > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c > index 7d18b7ed5d41..0ddb22a03d88 100644 > --- a/arch/x86/platform/efi/efi.c > +++ b/arch/x86/platform/efi/efi.c > @@ -768,9 +768,13 @@ static bool should_map_region(efi_memory_desc_t *md) > /* > * Map boot services regions as a workaround for buggy > * firmware that accesses them even when they shouldn't. > + * (only if CONFIG_EFI_WARN_ON_ILLEGAL_ACCESSES is disabled) > * > * See efi_{reserve,free}_boot_services(). > */ > + if (IS_ENABLED(CONFIG_EFI_WARN_ON_ILLEGAL_ACCESSES)) > + return false; > + > if (md->type == EFI_BOOT_SERVICES_CODE || > md->type == EFI_BOOT_SERVICES_DATA) > return true; > diff --git a/init/main.c b/init/main.c > index 3b4ada11ed52..dce0520861a1 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -730,7 +730,8 @@ asmlinkage __visible void __init start_kernel(void) > arch_post_acpi_subsys_init(); > sfi_init_late(); > > - if (efi_enabled(EFI_RUNTIME_SERVICES)) { > + if (efi_enabled(EFI_RUNTIME_SERVICES) && > + !IS_ENABLED(CONFIG_EFI_WARN_ON_ILLEGAL_ACCESSES)) { Since this is an arch agnostic code leg, do we really want to introduce a generic check for CONFIG_EFI_WARN_ON_ILLEGAL_ACCESSES here, without checking for whether we are actually running this on a x86 hardware, or alternatively we can consider moving CONFIG_EFI_WARN_ON_ILLEGAL_ACCESSES out of 'arch/x86/Kconfig' to 'arch/Kconfig' so that later it can be used on other archs like ARM64 as well. I think the later would be more useful.. Thanks, Bhupesh > efi_free_boot_services(); > } > > -- > 2.7.4 >