From nobody Sat Apr 27 01:02:21 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail(p=none dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1590075855; cv=none; d=zohomail.com; s=zohoarc; b=OIOI11gDRig2Lc3FFxkuLFNIWbGKLGir7EMHX1Y67WI1LCkTUKDdw3VQ95RmFYYAcosTRTSRfHNEgeYGS6ndSTvN+m7vbt35BFacoHWrVF+/+K/zAfFOWgByHxY1IqLWw7UYY8MDA/b9z1XSILXxHGgEL/KdWLYqADjvNXs+2OA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1590075855; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=7aW43mcJC6ErDxeKvcDCZL92T1wqw4zItJlVYvhxmmA=; b=BYDK0ntBuXVBrMGjsyVueac+CBHvMylyDVlXEJ3Ia9HfHmlUZS1Rggvgi0H6MvVfXYmh3dJh0WmDEgXL6DwM2GzCoSB21+eeMJhFKRyrtjhjF1vR9Xb765rXc3rKZbeExRqus4fOcCLt7lPz4EjDogg7vFcrSU8J0c5zAXd61Nc= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1590075855681539.4241513202968; Thu, 21 May 2020 08:44:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jbnM0-0005iR-S8; Thu, 21 May 2020 15:43:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jbnLz-0005iM-UQ for xen-devel@lists.xenproject.org; Thu, 21 May 2020 15:43:27 +0000 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cf5a1a74-9b79-11ea-ab28-12813bfff9fa; Thu, 21 May 2020 15:43:26 +0000 (UTC) X-Inumbo-ID: cf5a1a74-9b79-11ea-ab28-12813bfff9fa Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: cEQAIyRN+tdQi+VpIaRV7Q1pQgxcZYrRRMia970thXQEK5dywKJkHh48aAL7Ff3uPsuI61o82a QaAonCbikwrrQ83ipUmYxEzHZmZ7EvZsKT1tJmVFyTLkfvUu57hbkFQiHpc4lD9O3hzaQtCJgF mvQuN0VxuPANzHU61Cbpm1PfgjNin52WjHzqApjU4r+ty6xv0ouy1Wr51SpvEh71cKSw7aPkcq nZEhUX+PIYl1pVuXig2c26Eh7+Xe8SpvchQMpv4wWmuw5wg6Dv1qP3k6vMBiozxPA6VkbdZkD2 qdk= X-SBRS: 2.7 X-MesageID: 18128437 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,418,1583211600"; d="scan'208";a="18128437" From: Andrew Cooper To: Xen-devel Subject: [PATCH v2] x86/traps: Rework #PF[Rsvd] bit handling Date: Thu, 21 May 2020 16:43:06 +0100 Message-ID: <20200521154306.29019-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200518153820.18170-1-andrew.cooper3@citrix.com> References: <20200518153820.18170-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Wei Liu , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The reserved_bit_page_fault() paths effectively turn reserved bit faults in= to a warning, but in the light of L1TF, the real impact is far more serious. Make #PF[Rsvd] a hard error, irrespective of mode. Any new panic() caused = by this constitutes pagetable corruption, and probably an L1TF gadget needing fixing. Drop the PFEC_reserved_bit check in __page_fault_type() which has been made dead by the rearrangement in do_page_fault(). Additionally, drop the comment for do_page_fault(). It is inaccurate (bit 0 being set isn't always a protection violation) and stale (missing bits 5,6,15,31). Signed-off-by: Andrew Cooper Acked-by: Jan Beulich --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monn=C3=A9 v2: * Reword commit message and comment in do_page_fault(). --- xen/arch/x86/traps.c | 42 ++++++++++++++++-------------------------- 1 file changed, 16 insertions(+), 26 deletions(-) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 1f6f1dde76..e8a0877344 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1137,15 +1137,6 @@ void do_int3(struct cpu_user_regs *regs) pv_inject_hw_exception(TRAP_int3, X86_EVENT_NO_EC); } =20 -static void reserved_bit_page_fault(unsigned long addr, - struct cpu_user_regs *regs) -{ - printk("%pv: reserved bit in page table (ec=3D%04X)\n", - current, regs->error_code); - show_page_walk(addr); - show_execution_state(regs); -} - #ifdef CONFIG_PV static int handle_ldt_mapping_fault(unsigned int offset, struct cpu_user_regs *regs) @@ -1248,10 +1239,6 @@ static enum pf_type __page_fault_type(unsigned long = addr, if ( in_irq() ) return real_fault; =20 - /* Reserved bit violations are never spurious faults. */ - if ( error_code & PFEC_reserved_bit ) - return real_fault; - required_flags =3D _PAGE_PRESENT; if ( error_code & PFEC_write_access ) required_flags |=3D _PAGE_RW; @@ -1413,14 +1400,6 @@ static int fixup_page_fault(unsigned long addr, stru= ct cpu_user_regs *regs) return 0; } =20 -/* - * #PF error code: - * Bit 0: Protection violation (=3D1) ; Page not present (=3D0) - * Bit 1: Write access - * Bit 2: User mode (=3D1) ; Supervisor mode (=3D0) - * Bit 3: Reserved bit violation - * Bit 4: Instruction fetch - */ void do_page_fault(struct cpu_user_regs *regs) { unsigned long addr, fixup; @@ -1439,6 +1418,21 @@ void do_page_fault(struct cpu_user_regs *regs) if ( unlikely(fixup_page_fault(addr, regs) !=3D 0) ) return; =20 + /* + * Xen doesn't have reserved bits set in its pagetables, nor do we per= mit + * PV guests to write any. Such entries would generally be vulnerable= to + * the L1TF sidechannel. + * + * The shadow pagetable logic may use reserved bits as part of + * SHOPT_FAST_FAULT_PATH. Pagefaults arising from these will be resol= ved + * via the fixup_page_fault() path. + * + * Anything remaining is an error, constituting corruption of the + * pagetables and probably an L1TF vulnerable gadget. + */ + if ( error_code & PFEC_reserved_bit ) + goto fatal; + if ( unlikely(!guest_mode(regs)) ) { enum pf_type pf_type =3D spurious_page_fault(addr, regs); @@ -1457,13 +1451,12 @@ void do_page_fault(struct cpu_user_regs *regs) if ( likely((fixup =3D search_exception_table(regs)) !=3D 0) ) { perfc_incr(copy_user_faults); - if ( unlikely(regs->error_code & PFEC_reserved_bit) ) - reserved_bit_page_fault(addr, regs); this_cpu(last_extable_addr) =3D regs->rip; regs->rip =3D fixup; return; } =20 + fatal: if ( debugger_trap_fatal(TRAP_page_fault, regs) ) return; =20 @@ -1475,9 +1468,6 @@ void do_page_fault(struct cpu_user_regs *regs) error_code, _p(addr)); } =20 - if ( unlikely(regs->error_code & PFEC_reserved_bit) ) - reserved_bit_page_fault(addr, regs); - pv_inject_page_fault(regs->error_code, addr); } =20 --=20 2.11.0