Received: by 10.192.165.148 with SMTP id m20csp4735242imm; Tue, 24 Apr 2018 07:37:14 -0700 (PDT) X-Google-Smtp-Source: AIpwx49MxABFRctkpLakNBS34tdASJX4s+u2CdOjKdDrBdpZ2flJFKhsPcdmhxhzMZcS8efNWZrg X-Received: by 10.101.101.132 with SMTP id u4mr20932080pgv.260.1524580634123; Tue, 24 Apr 2018 07:37:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524580634; cv=none; d=google.com; s=arc-20160816; b=Tn/4XdvuIuMshxjMbDyFfBFbT0ey873BNf9/TlTL/Tmzi75bsF5qnlQWinYJ9z77tb tmDx2wLxGWDj2j01fa6EWQ424fwCLUUiwOhKfByvTbHws6aOOjrvNt0+tH51gDHotMOy 3ft9POSUDOZ42Ii6J7nF1xoBVlzMq8aQ2jTSRfpKxKDicYwoCpP1GzLVBjPNczkCR/gU M3rtGvBgA8v/Nxlr9Y4pmr6Jg2xfnaF/b6PZXeCcEyxI5dJcJ21WGYbeDrCawSscS18L RdYji3RHY18DpOKx1KojhooFc9aWNfvI1keCJiDvivgDSNLHnopPTj+QrsG7Pon3/GFY s/wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=pherexfB0aR0C3mDgUHaIa1lkGXTYl7UCXVXuSRKd2c=; b=WEzwkSpaE/DPiI1tbUkDnWmBv1oud/mBOxftM1zMfoVMZ5XM1Sy+FXBs8z+8HzPVBu PKiUJNLpBLAZf9db/uNuTZ/vmZilNtuoMTyZjGTVP5/mLPqFYxCe3dPi+nTGQJyv/2nt +bkuxClyCm3VVDc9PryJghzzgerYgI545OhAYRhu/Q29OWyp1lBN/xRiRhmsHbk60XCk iJ36fczrxI+EgKUPmp+ZFovHm0296pFRUndlvFuRnERdUaFTAU6XRzCHKG+WDxGp3HvN d/lG/WACsmHhCoh4dsNKb7RzTDzznMOaB62tusvwV6vdkV36cx8IL1yTmekO9G6zdZpR kvwQ== 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 s24-v6si13026630plp.564.2018.04.24.07.36.59; Tue, 24 Apr 2018 07:37:14 -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 S933131AbeDXNLd (ORCPT + 99 others); Tue, 24 Apr 2018 09:11:33 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:45284 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757448AbeDXNL3 (ORCPT ); Tue, 24 Apr 2018 09:11:29 -0400 Received: by mail-wr0-f193.google.com with SMTP id p5-v6so22132801wre.12 for ; Tue, 24 Apr 2018 06:11:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pherexfB0aR0C3mDgUHaIa1lkGXTYl7UCXVXuSRKd2c=; b=A7GkTM4t9fg+kMc0AFOjrkxqP61JlxH3xFXZzNQrIi3xmRHUtv5/FFMmCVp3//3ARX aF/+ubu2LOVoMKy35SOXwxgO3Agnz5LpSFG0VP6jtHLE5/DEG4iJsJEvCho8M2xApk1W o38RkBKaOcg5pqlEkQW/vOxKHL2/0AONOwT8y6dDX7h3EGxrX1MTw/1VKLPD4+lwvmjf PztA8FUYDiYjbWh19/GS4eWYyIGC2IilQ2C2cT4cCLr9G8PZcEOKj0N8UDwkjguGsnJu g5O5ptzpzqe3G/pnj1oBfULBq4fsMWBmsDC/sTDYVhXXlsLPIZM7Lx17UMx9N/E44SoT hmgQ== X-Gm-Message-State: ALQs6tDep+87bDa3l8kYfrfp473mLEnHHjUNtLqWnM7+AogsHOGLCgJC H3Mg6bq0UMqiUmaResnaUlo0vQ== X-Received: by 2002:adf:c792:: with SMTP id l18-v6mr20368031wrg.224.1524575488056; Tue, 24 Apr 2018 06:11:28 -0700 (PDT) Received: from shalem.localdomain (546A5441.cm-12-3b.dynamic.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id p35-v6sm20738591wrb.12.2018.04.24.06.11.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Apr 2018 06:11:27 -0700 (PDT) Subject: Re: [PATCH v3 1/5] efi: Export boot-services code and data as debugfs-blobs To: Ard Biesheuvel Cc: Darren Hart , Andy Shevchenko , "Luis R . Rodriguez" , Greg Kroah-Hartman , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , platform-driver-x86@vger.kernel.org, Linux Kernel Mailing List , Peter Jones , Dave Olsthoorn , Will Deacon , Andy Lutomirski , Matt Fleming , David Howells , Mimi Zohar , Josh Triplett , Dmitry Torokhov , Martin Fuzzey , Kees Cook , Kalle Valo , Arend Van Spriel , Linus Torvalds , Nicolas Broeking , Bjorn Andersson , Torsten Duwe , the arch/x86 maintainers , linux-efi@vger.kernel.org References: <20180408174014.21908-1-hdegoede@redhat.com> <20180408174014.21908-2-hdegoede@redhat.com> From: Hans de Goede Message-ID: <3919feeb-cdad-7ce0-4fdf-1bf0004b63b5@redhat.com> Date: Tue, 24 Apr 2018 15:11:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 16-04-18 10:23, Ard Biesheuvel wrote: > Hallo Hans, > > On 8 April 2018 at 19:40, Hans de Goede wrote: >> Sometimes it is useful to be able to dump the efi boot-services code and >> data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, >> but only if efi=debug is passed on the kernel-commandline as this requires >> not freeing those memory-regions, which costs 20+ MB of RAM. >> >> Signed-off-by: Hans de Goede >> --- >> Changes in v2: >> -Do not call pr_err on debugfs call failures >> --- >> arch/x86/platform/efi/quirks.c | 4 +++ >> drivers/firmware/efi/efi.c | 53 ++++++++++++++++++++++++++++++++++ >> 2 files changed, 57 insertions(+) >> >> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c >> index 5b513ccffde4..0f968c7bcfec 100644 >> --- a/arch/x86/platform/efi/quirks.c >> +++ b/arch/x86/platform/efi/quirks.c >> @@ -374,6 +374,10 @@ void __init efi_free_boot_services(void) >> int num_entries = 0; >> void *new, *new_md; >> >> + /* Keep all regions for /sys/kernel/debug/efi */ >> + if (efi_enabled(EFI_DBG)) >> + return; >> + >> for_each_efi_memory_desc(md) { >> unsigned long long start = md->phys_addr; >> unsigned long long size = md->num_pages << EFI_PAGE_SHIFT; >> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c >> index cd42f66a7c85..10c896e8b82b 100644 >> --- a/drivers/firmware/efi/efi.c >> +++ b/drivers/firmware/efi/efi.c >> @@ -18,6 +18,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -316,6 +317,55 @@ static __init int efivar_ssdt_load(void) >> static inline int efivar_ssdt_load(void) { return 0; } >> #endif >> >> +#ifdef CONFIG_DEBUG_FS >> + >> +#define EFI_DEBUGFS_MAX_BLOBS 32 >> + >> +static struct debugfs_blob_wrapper debugfs_blob[EFI_DEBUGFS_MAX_BLOBS]; >> + >> +static void __init efi_debugfs_init(void) >> +{ >> + struct dentry *efi_debugfs; >> + efi_memory_desc_t *md; >> + char name[32]; >> + int type_count[EFI_BOOT_SERVICES_DATA + 1] = {}; >> + int i = 0; >> + >> + efi_debugfs = debugfs_create_dir("efi", NULL); >> + if (IS_ERR_OR_NULL(efi_debugfs)) >> + return; >> + >> + for_each_efi_memory_desc(md) { >> + switch (md->type) { >> + case EFI_BOOT_SERVICES_CODE: >> + snprintf(name, sizeof(name), "boot_services_code%d", >> + type_count[md->type]++); >> + break; >> + case EFI_BOOT_SERVICES_DATA: >> + snprintf(name, sizeof(name), "boot_services_data%d", >> + type_count[md->type]++); >> + break; >> + default: >> + continue; >> + } >> + >> + debugfs_blob[i].size = md->num_pages << EFI_PAGE_SHIFT; >> + debugfs_blob[i].data = memremap(md->phys_addr, >> + debugfs_blob[i].size, >> + MEMREMAP_WB); >> + if (!debugfs_blob[i].data) >> + continue; >> + >> + debugfs_create_blob(name, 0400, efi_debugfs, &debugfs_blob[i]); >> + i++; >> + if (i == EFI_DEBUGFS_MAX_BLOBS) >> + break; >> + } >> +} >> +#else >> +static inline void efi_debugfs_init(void) {} >> +#endif >> + >> /* >> * We register the efi subsystem with the firmware subsystem and the >> * efivars subsystem with the efi subsystem, if the system was booted with >> @@ -360,6 +410,9 @@ static int __init efisubsys_init(void) >> goto err_remove_group; >> } >> >> + if (efi_enabled(EFI_DBG)) >> + efi_debugfs_init(); >> + > > This doesn't really make any sense on non-x86. The boot services > regions are released to the kernel for general allocation, and so > exposing them this way only makes sense if you keep them as you do for > x86. > > Could you please try to make this call specific to situations where it > makes sense? I don't mind allocating a new EFI_xxx flag for preserving > the boot services regions so we could decide to set it for ARM/arm64 > as well in certain cases in the future. Ok, I've added a new EFI_BOOT_SERVICES flag for this for v4 of this patchset, mirroring the existing EFI_RUNTIME_SERVICES flag in naming. Regards, Hans