Received: by 10.223.185.116 with SMTP id b49csp3163606wrg; Mon, 5 Mar 2018 15:31:57 -0800 (PST) X-Google-Smtp-Source: AG47ELvZBF4PvK3HSllRz22GOOWS6Rb/z8oK7B82KwH4jDVg0fNy7S3bGblxybNa2ZTsGd2MdWpW X-Received: by 2002:a17:902:8214:: with SMTP id x20-v6mr14509473pln.182.1520292717581; Mon, 05 Mar 2018 15:31:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520292717; cv=none; d=google.com; s=arc-20160816; b=TW19LwAnUsHh7/eR4+6jdSEIMadMWQ3TD0ofmFdkXslCfSzOiSy+9A9jETStLLXtoX rbMi0qXfJhVdoe3SvIiH2wkQihRlCfZR+NNtV62M2hSNqEWro4aI5jGC61R2v65e7bXr OHqqfziBqxxLeAcEt9fndSmDf+u4HBNm5LAMv0SLH5QJcd2ywJGcu1sVSU/t69qASCBK r4G4OEkULnKH6l9UsbTwYUuB0oCN8jh1UxLpjmXhsDqza2VrV0R/kFatxFpyIJRS/Qv8 lvCwewJhVeeY4GWVmAbIbpAxj+cyLHGrg14MYPjGVxE+xgiqoHip3x+1AUc9m0X//kny 3LCA== 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 :arc-authentication-results; bh=KKcRIDAjM7eK1m+Np8rMh1wuP+3o9BBFkyoC+gmpqZI=; b=AWvF6L1alXe4rLqJ3UQHwyUv9j4NLpd86sikSSlTFcrwLZUo7oFC3TUI75BF6sqivI z3D2vcb+neIyGUbQaMljd7SGl52Mce8uasdd8GK0WsdRnxpGgp5TFF7otsIbnRluLZ4g sULleOJlR7TLMyGuyHlDbM/LXjiXuFGj6NB68QRSCe/Pkv8469hF4m7FU+439HcZHV1N BLUfil4TM7NGQJ+964ViJv2/+niubavWWKJNBVkHZJh+rKps78FM4QC2chs1+FILJXdF IGnAv33D8hxtSthJCMtzuHMUFnVpApeAtLZtMZ//ICS1SvVOvGqYg7z7XvEjtIDWs/6M 2v9g== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u7-v6si9953504plr.241.2018.03.05.15.31.43; Mon, 05 Mar 2018 15:31:57 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932713AbeCEX3l (ORCPT + 99 others); Mon, 5 Mar 2018 18:29:41 -0500 Received: from mga02.intel.com ([134.134.136.20]:47760 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932393AbeCEX3j (ORCPT ); Mon, 5 Mar 2018 18:29:39 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2018 15:29:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,429,1515484800"; d="scan'208";a="25443519" Received: from sai-dev-mach.sc.intel.com ([143.183.140.145]) by fmsmga002.fm.intel.com with ESMTP; 05 Mar 2018 15:29:37 -0800 From: Sai Praneeth Prakhya To: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Sai Praneeth , Lee@vger.kernel.org, Chun-Yi , Borislav Petkov , Tony Luck , Will Deacon , Dave Hansen , Mark Rutland , Bhupesh Sharma , Ricardo Neri , Ravi Shankar , Matt Fleming , Peter Zijlstra , Ard Biesheuvel , Dan Williams Subject: [PATCH V2 0/3] Use efi_rts_workqueue to invoke EFI Runtime Services Date: Mon, 5 Mar 2018 15:23:07 -0800 Message-Id: <1520292190-5027-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 This patch set is an outcome of the discussion at https://lkml.org/lkml/2017/8/21/607 Presently, efi_runtime_services() are executed by firmware in process context. To execute efi_runtime_service(), kernel switches the page directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have any user space mappings. A potential issue could be, for instance, an NMI interrupt (like perf) trying to profile some user data while in efi_pgd. A solution for this issue could be to use kthread to run efi_runtime_service(). When a user/kernel thread requests to execute efi_runtime_service(), kernel off-loads this work to kthread which in turn uses efi_pgd. Anything that tries to touch user space addresses while in kthread is terminally broken. This patch set adds support to the efi subsystem to handle all calls to efi_runtime_services() using a work queue (which in turn uses kthread). Implementation summary: ----------------------- 1. When a user/kernel thread requests to execute efi_runtime_service(), enqueue work to a work queue, efi_rts_workqueue. 2. The caller thread waits until the work is finished because it's dependent on the return status of efi_runtime_service() and, in specific cases, the arguments populated by efi_runtime_service(). Some efi_runtime_services() takes a pointer to buffer as an argument and fills up the buffer with requested data. For instance, efi_get_variable() and efi_get_next_variable(). Hence, the caller process cannot just post the work and get going, it has to wait for results from firmware. Caveat: efi_rts_workqueue to run efi_runtime_services() shouldn't be used while in atomic, because caller thread might sleep. Presently, pstore code doesn't use efi_rts_workqueue. Tested using LUV (Linux UEFI Validation) for x86_64 and x86_32. Builds fine for arm and arm64. Will appreciate the effort if someone could test the patches on real ARM/ARM64 machines. LUV: https://01.org/linux-uefi-validation Thanks to Ricardo and Dan for initial reviews and suggestions. Please feel free to pour in your comments and concerns. Note: Patches are based on Linus's kernel v4.16-rc4 Changes from V1 to V2: ---------------------- 1. Remove unnecessary include of asm/efi.h file - Fixes build error on ia64, reported by 0-day 2. Use enum to identify efi_runtime_services() 3. Use alloc_ordered_workqueue() to create efi_rts_wq as create_workqueue() is scheduled for depreciation. 4. Make efi_call_rts() static, as it has no callers outside runtime-wrappers.c 5. Use BUG(), when we are unable to queue work or unable to identify requested efi_runtime_service() - Because these two situations should *never* happen. Sai Praneeth (3): x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services() efi: Use efi_rts_workqueue to invoke EFI Runtime Services arch/x86/include/asm/efi.h | 1 - arch/x86/platform/efi/efi.c | 6 - drivers/firmware/efi/efi.c | 21 +++ drivers/firmware/efi/runtime-wrappers.c | 229 +++++++++++++++++++++++++++++--- include/linux/efi.h | 23 ++++ 5 files changed, 253 insertions(+), 27 deletions(-) Signed-off-by: Sai Praneeth Prakhya Suggested-by: Andy Lutomirski Cc: Lee, Chun-Yi Cc: Borislav Petkov Cc: Tony Luck Cc: Will Deacon Cc: Dave Hansen Cc: Mark Rutland Cc: Bhupesh Sharma Cc: Ricardo Neri Cc: Ravi Shankar Cc: Matt Fleming Cc: Peter Zijlstra Cc: Ard Biesheuvel Cc: Dan Williams -- 2.7.4