From patchwork Thu Jan 25 10:31:27 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 125780 Delivered-To: patch@linaro.org Received: by 10.46.66.141 with SMTP id h13csp1016447ljf; Thu, 25 Jan 2018 02:31:42 -0800 (PST) X-Google-Smtp-Source: AH8x225fmo/ev5CF5L2dxQ7JAKVupc5sF0F47DV7Opd6mz51nrmMqUR4NKv9kvb62lfOrOpfGOhj X-Received: by 10.101.75.141 with SMTP id t13mr13276612pgq.232.1516876302768; Thu, 25 Jan 2018 02:31:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516876302; cv=none; d=google.com; s=arc-20160816; b=oMQfBXZRuzs420Ev34soWrEAuXLdG4VJQt5aFhGUCoag/pZDnRH19QKlstFMMZUkbC gs541zOJOlpFfoXywYOdOSMKeF91TdXWgJVMn+Sg7YYGsiKWVg38hzC/Lj0a13uCpc6n naVZ71otjbdYT2woO6BHYgk5LpyRyNEeQ5rTjX1EaK1AgyuZkb+azurYyLslSrEToVt+ dEpTdx4ADZfKtUipHh2W7s2H99sKXQsNhoiEqLNRbSUXWdjTmEV5D/oVd6g7THG/N542 RloZGi4jwXxlY7wsxaLrWgcYqh2ld8wyJrTb4J1zguJ649vluzS+1JMPAKPWO04MpLj7 fpxg== 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 :dkim-signature:arc-authentication-results; bh=JVXe9gdGkW6p2EXUfxz+453euMAiynWxAiOlzGYXgMY=; b=UrJ8+w31ALoE9R1cs9KtBlQ/sk4lSWHC4Jc/0LykTrMSo9Zo2ygSKS8Ej4f76+Mo2z VTKN7IN+8hJUQf8Igtt9TQg0iy70Li7xoomDmLSOPH19tq3m/AmbMGBii9GbBl/a3C/p dzVpiw1tRxQJ7zORvxLEEiXxQQ4sxaQXDOtOVcsTRF33OWdQNrTbAsgTFMGiPfZ9zXpc 0dFqoIqKZf3g536AcHZO8M83H7nNWMb2UvCgBl8vJl9fMQGJ433dbN6jVEVfCxYHkaIq GnS+FLVazdNd5Oy9L4iuR/HxHAhp49ZQWK8d6R4UGRmgXz3fREwuC9ZhabLId2FqT2Xd Oc2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=ZCh0NcBZ; spf=pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-efi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q7si4419852pfh.74.2018.01.25.02.31.42; Thu, 25 Jan 2018 02:31:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=ZCh0NcBZ; spf=pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-efi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751138AbeAYKbm (ORCPT + 2 others); Thu, 25 Jan 2018 05:31:42 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:36006 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbeAYKbl (ORCPT ); Thu, 25 Jan 2018 05:31:41 -0500 Received: by mail-wr0-f196.google.com with SMTP id d9so7106260wre.3 for ; Thu, 25 Jan 2018 02:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=ZXj74iAaP7/e9CZGX0XJsWZKzStmTRNVsViFY0/cAA0=; b=ZCh0NcBZQANcLgxQd3pFI4GpGlDVqAsp/whkM9wdKvGsJHGMjGgEa5prXIIW/BChTa o6SL+HKWEuar5hxyd+cFMakKjIa7+BCFSQToW1qrsf6DKSf1FKVTakGlkhvlMF9qkncH 9W/0dGacq2r+2Vrls4/0yzjU9K9P+ZUPMRPzQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=ZXj74iAaP7/e9CZGX0XJsWZKzStmTRNVsViFY0/cAA0=; b=JpJ65DQFyXG0f8yi3Nsqo+FHSia2LoDgcqlDNHhbJzAguks3rEuS+RxKGBS/xupakW eXcxMSEQK7wb/4U6gI9H+hm5xUAkxgTRJ/hdfVx5RsQRgBr9022bnWQmid9+LIbxqM3S RLBCNQl9NchLnnX2iQurR598EpbK1r9xBk3c+7Lqv0b5k7DhNqREwY2TaT29ZBfQZYUR xWdy4HfJQ2D7NQwi/ZtGRSEilunAK23yTLkAMVSHTD184cuwVzgcSDDPjhhxt6mc7zFh zVZD7n+zxV28mRKoKP53vrZn8xa6lEORoE3rHDYq9sRzS4oZ2aY5Zs1vYg+d9BhfYLRl k1Dg== X-Gm-Message-State: AKwxyteuJDwnsE5o6J1n/GA4H9XyRSwdMWpQTBsUtpOJkg2tom4OX6Vj PChtFB1RNmpv2qoYYsLd44OuVmlhg3o= X-Received: by 10.223.170.150 with SMTP id h22mr8870722wrc.21.1516876299388; Thu, 25 Jan 2018 02:31:39 -0800 (PST) Received: from localhost.localdomain ([160.167.127.168]) by smtp.gmail.com with ESMTPSA id j77sm1199964wmf.37.2018.01.25.02.31.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 02:31:38 -0800 (PST) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, will.deacon@arm.com, catalin.marinas@arm.com, mark.rutland@arm.com, marc.zyngier@arm.com Cc: joakim.bech@linaro.org, leif.lindholm@linaro.org, graeme.gregory@linaro.org, Ard Biesheuvel Subject: [PATCH 0/4] efi/arm64: unmap the kernel during runtime service calls Date: Thu, 25 Jan 2018 10:31:27 +0000 Message-Id: <20180125103131.19168-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.11.0 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org UEFI doesn't keep any secrets, so it is mostly unaffected by Meltdown and Spectre. At boot time, when UEFI is in charge of everything, there is simply no point in inferring things from the cache state if you can simply read the data. At runtime, when UEFI runs in the execution context of the OS, it is really up to the OS to ensure that lower privilege levels cannot access OS data structures unpermitted. This applies equally to Spectre variant 2: UEFI runtime services are not entered directly from userland but always via the kernel, which carries out any required branch predictor maintenance when switching between the various tasks (and the UEFI runtime execution context may be considered a separate task in this sense) Spectre variant 1 is a different matter though. It requires code changes and software rebuilds with updated compilers to be fully hardened against it, although nobody seems to know exactly what that means at the moment. Given the poor track record of vendors when it comes to keeping UEFI firmware up to date, it is highly likely that vulnerable versions will still be in circulation long after we fixed the OS. Since UEFI interacts with data structures that the OS may consider opaque (capsule images, authenticated variable updates), it is not really up to the OS to reason about which invocation is safe and which one isn't. The only solution really is to simply unmap the entire kernel during UEFI runtime services invocations, so that there are no secrets to steal to begin with. Patch #1 is included for completeness. I sent it out before, and it is a dependency for this series, but it is otherwise unrelated. Patch #2 creates a separate stack for UEFI and puts it in the EFI page tables, along with the asm wrapper that invokes the UEFI runtime services and a vector table that is activated before and deactivated after the service is called. Patch #3 implements marshalling of all byref arguments taken by UEFI runtime services. This is necessary because they will refer to memory that is going to be unmapped. Patch #4 implements the actual unmap/remap sequences, by setting/clearing the EPD1 bit in TCR_EL1, and doing a local TLB flush. Note that capsule update has been omitted. This is a bit involved, and I'd rather get some feedback before burning too many cycles on that. All other services should be functional, with the caveat that EFI variable names are now limited to 1024 [wide] characters, and UEFI variables themselves to 64 KB. Ard Biesheuvel (4): efi: arm64: Check whether x18 is preserved by runtime services calls efi/arm64: map the stack and entry wrapper into the UEFI page tables efi/arm64: marshall runtime services arguments via buffer in TTBR0 efi/arm64: unmap the kernel while executing UEFI services arch/arm/include/asm/efi.h | 5 + arch/arm64/Kconfig | 1 - arch/arm64/include/asm/efi.h | 30 +- arch/arm64/include/asm/stacktrace.h | 4 + arch/arm64/kernel/Makefile | 3 +- arch/arm64/kernel/efi-rt-wrapper.S | 112 +++++ arch/arm64/kernel/efi.c | 505 +++++++++++++++++++- arch/arm64/kernel/entry.S | 1 + drivers/firmware/efi/arm-runtime.c | 2 + 9 files changed, 658 insertions(+), 5 deletions(-) create mode 100644 arch/arm64/kernel/efi-rt-wrapper.S -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html