Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5550097imm; Wed, 12 Sep 2018 07:38:16 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYcyCV4LiqDp39XU9ktnyAh98pW1SVNn1y+oTMJyQUOIrWmoRlQSd0v2ctKVdJ4NoE04JC+ X-Received: by 2002:a17:902:7803:: with SMTP id p3-v6mr2628081pll.119.1536763096650; Wed, 12 Sep 2018 07:38:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536763096; cv=none; d=google.com; s=arc-20160816; b=q7AiuMzO5ifZfDhjQI7WUdSEUGIhLU/wZbenItgstXqqpfU8cGJrkmSmsvlU9D3Nf6 G6u864Mng3lNmeLZsT7P2+0k2PBK3L6Llq0tEUjUMQEbx+E28DJhcGxr71d8CjKH56EG CHUYHFtKX3Go0wemivfb/XoHXKei19nuaQbpLE8kGJSEhI5vMSWLFGAI6YSFmGnxJfB5 4adNwUIFDCsG6jY+3J5ivtfNkF0JnlPHbDKZTnLALgfa53afBzi6qFtRhcXAmXLKvtgX FW4zpolw2foVNLeDHKnYciOij14NnljqXxMJN8l7SpJhDs0tz/wh5nLK77Wb8T8yA2pu 2gug== 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:dkim-signature; bh=t2AkKMW3uG9PmM8uWvE13AYW8LWT09XOFJXk8rE9+rs=; b=zSY9awlYvAoGG7fDWnDBfwoU7Iu+895In5VK6wbSmuflscScf+idGhhzVxzy2jVJ7h 1tOBfa7yTzbCtKRW54avxdeTUWJsVsX6iJd1PiP+SyrBIOiS3vCJvH0o7xOGrirCyfsS vDztzXg9sew9e5Mt0t3jatQW6P4VDoVlGR/nzDY3vIHly2TUzhp8Qml5SkYEJOF5L90f fhHT2A8GaFhtzysH2kFGN6p+OqN0NsX0JhbXF9dkEY4B+D+WaFE8R3EbhewkCoDdW4fX Wl1EcAQFsyPAycaIxuYNvFDVVhx6QK/mFW+zmJ7npaqt1WAy1c5zcO3eyctD3Te1LGcD +wKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LpoJ6kj1; 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=pass (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 p12-v6si1197562pls.53.2018.09.12.07.38.01; Wed, 12 Sep 2018 07:38:16 -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; dkim=pass header.i=@linaro.org header.s=google header.b=LpoJ6kj1; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728021AbeILTmk (ORCPT + 99 others); Wed, 12 Sep 2018 15:42:40 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:36176 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726945AbeILTmj (ORCPT ); Wed, 12 Sep 2018 15:42:39 -0400 Received: by mail-it0-f65.google.com with SMTP id u13-v6so3350072iti.1 for ; Wed, 12 Sep 2018 07:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t2AkKMW3uG9PmM8uWvE13AYW8LWT09XOFJXk8rE9+rs=; b=LpoJ6kj1MZIAj4RWDpJO7wmdULde5QkARDY2VqMWixEU6WA2NR0Scr5Z/rN3Jrvu89 Px0nKa2u2p3vgpVKKG8El/ippR0qxbWQQE67S0KPoC1IfVRxwyeE78CVcpUR0CGfwj0v fE9s4Hu30MAX2E5dZZ4eE9/e6U+1ykq32kQek= 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=t2AkKMW3uG9PmM8uWvE13AYW8LWT09XOFJXk8rE9+rs=; b=eNn2ciy6MyePhR77xryuw2xFUyx5NkEZTpz0Vd0mbm334RjV5zJ+KEBmBp/fSRkb+c JcOxN+BWEFNGeS6oQ62AM1C26IxxOlXnr+5ty4FaRxAAS84LmnqKLTAEfW0+ebillfRo DV7Ykb3K9qbrc8r+LrckV2QH85QslB8RutQiRY1CLQarPzGLXCb9ioByNWqLNsxxpDkB lfO6OC5QpPoEWA2CPEi+Bu9uXQFTmDfwwMpc6+zLb4KFcD9euO1/38k6XZdsoa7EU0mD yWx40MscAJSMj37xvppeUpucABhGZwsa+Ild9hZLm2jdhOeULOSx92s+ZpWy5/myvdUc nsCg== X-Gm-Message-State: APzg51BAz1fz5ArLih/waBJGc7ODoZwKK1glXNI0YF97eP9fi9lYbcj3 DfBtnKYCZ/1YtvhSWFatkVvYSE+f0dP1OvajsRhLpA== X-Received: by 2002:a24:57cb:: with SMTP id u194-v6mr2182935ita.148.1536763071344; Wed, 12 Sep 2018 07:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:2848:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 07:37:50 -0700 (PDT) In-Reply-To: <1536693322-8335-1-git-send-email-sai.praneeth.prakhya@intel.com> References: <1536693322-8335-1-git-send-email-sai.praneeth.prakhya@intel.com> From: Ard Biesheuvel Date: Wed, 12 Sep 2018 16:37:50 +0200 Message-ID: Subject: Re: [PATCH V6 0/2] Add efi page fault handler to recover from page To: Sai Praneeth Prakhya Cc: linux-efi , Linux Kernel Mailing List , "the arch/x86 maintainers" , Al Stone , Borislav Petkov , Ingo Molnar , Andy Lutomirski , Bhupesh Sharma , Thomas Gleixner , Peter Zijlstra 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 On 11 September 2018 at 21:15, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > There may exist some buggy UEFI firmware implementations that access efi > memory regions other than EFI_RUNTIME_SERVICES_ even after > the kernel has assumed control of the platform. This violates UEFI > specification. Hence, provide a efi specific page fault handler which > recovers from page faults caused by buggy firmware. > > Page faults triggered by firmware happen at ring 0 and if unhandled, > hangs the kernel. So, provide an efi specific page fault handler to: > 1. Avoid panics/hangs caused by buggy firmware. > 2. Shout loud that the firmware is buggy and hence is not a kernel bug. > > The efi page fault handler will check if the access is by > efi_reset_system(). > 1. If so, then the efi page fault handler will reboot the machine > through BIOS and not through efi_reset_system(). > 2. If not, then the efi page fault handler will freeze efi_rts_wq and > schedules a new process. > > This issue was reported by Al Stone when he saw that reboot via EFI hangs > the machine. Upon debugging, I found that it's efi_reset_system() that's > touching memory regions which it shouldn't. To reproduce the same > behavior, I have hacked OVMF and made efi_reset_system() buggy. Along > with efi_reset_system(), I have also modified get_next_high_mono_count() > and set_virtual_address_map(). They illegally access both boot time and > other efi regions. > > Testing the patch set: > ---------------------- > 1. Download buggy firmware from here [1]. > 2. Run a qemu instance with this buggy BIOS and boot mainline kernel. > Add reboot=efi to the kernel command line arguments and after the kernel > is up and running, type "reboot". The kernel should hang while rebooting. > 3. With the same setup, boot kernel after applying patches and the > reboot should work fine. Also please notice warning/error messages > printed by kernel. > Did you test these patches with other buggy runtime services? > Changes from RFC to V1: > ----------------------- > 1. Drop "long jump" technique of dealing with illegal access and instead > use scheduling away from efi_rts_wq. > > Changes from V1 to V2: > ---------------------- > 1. Shortened config name to CONFIG_EFI_WARN_ON_ILLEGAL_ACCESS from > CONFIG_EFI_WARN_ON_ILLEGAL_ACCESSES. > 2. Made the config option available only to expert users. > 3. efi_free_boot_services() should be called only when > CONFIG_EFI_WARN_ON_ILLEGAL_ACCESS is not enabled. Previously, this > was part of init/main.c file. As it is an architecture agnostic code, > moved the change to arch/x86/platform/efi/quirks.c file. > > Changes from V2 to V3: > ---------------------- > 1. Drop treating illegal access to EFI_BOOT_SERVICES_ regions > separately from illegal accesses to other regions like > EFI_CONVENTIONAL_MEMORY or EFI_LOADER_. > In previous versions, illegal access to EFI_BOOT_SERVICES_ > regions were handled by mapping requested region to efi_pgd but from > V3 they are handled similar to illegal access to other regions i.e by > freezing efi_rts_wq and scheduling new process. > 2. Change __efi_init_fixup attribute to __efi_init. > > Changes from V3 to V4: > ---------------------- > 1. Drop saving original memory map passed by kernel. It also means less > checks in efi page fault handler. > 2. Change the config name to EFI_PAGE_FAULT_HANDLER to reflect it's > functionality more appropriately. > > Changes from V4 to V5: > ---------------------- > 1. Drop config option that enables efi page fault handler, instead make > it default. > 2. Call schedule() in an infinite loop to account for spurious wake ups. > 3. Introduce "NONE" as an efi runtime service function identifier so that > it could be used in efi_recover_from_page_fault() to check if the page > fault was indeed triggered by an efi runtime service. > > Changes from V5 to V6: > ---------------------- > 1. Thanks to 0-day for reporting build error when CONFIG_EFI is not > enabled. Fixed it by calling efi page fault handler only when > CONFIG_EFI is enabled. > 2. Change return type of efi page fault handler from int to void. void > return type should do (and int is not needed) because the efi page > fault handler returns only upon a failure to handle page fault. > > Note: > ----- > Patch set based on "next" branch in efi tree. > > [1] https://drive.google.com/drive/folders/1VozKTms92ifyVHAT0ZDQe55ZYL1UE5wt > > Sai Praneeth (2): > efi: Make efi_rts_work accessible to efi page fault handler > x86/efi: Add efi page fault handler to recover from page faults caused > by the firmware > > arch/x86/include/asm/efi.h | 1 + > arch/x86/mm/fault.c | 9 ++++ > arch/x86/platform/efi/quirks.c | 78 +++++++++++++++++++++++++++++++++ > drivers/firmware/efi/runtime-wrappers.c | 61 +++++++------------------- > include/linux/efi.h | 42 ++++++++++++++++++ > 5 files changed, 147 insertions(+), 44 deletions(-) > > Tested-by: Bhupesh Sharma > 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 > > -- > 2.7.4 >