From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6E2BC433DF for ; Tue, 23 Jun 2020 13:57:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 941D820720 for ; Tue, 23 Jun 2020 13:57:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732711AbgFWN51 (ORCPT ); Tue, 23 Jun 2020 09:57:27 -0400 Received: from esa1.hc3370-68.iphmx.com ([216.71.145.142]:50852 "EHLO esa1.hc3370-68.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732657AbgFWN50 (ORCPT ); Tue, 23 Jun 2020 09:57:26 -0400 Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: RxHCBkGn6WCYmKI8uhwqpDzWq9+T02hGLgx/4StGqp26rXVL/9EHUTW4ZgZWcdrwy973h8+FL1 vuqOMF+AEy3R03F6tyzjQrt2Z04lpSzdTjGVedKmE+8goFjOSXq8bTLW7X1REC5Cfa0KZuLHu2 2qD6s/B/VzsFyM3jt90pG1SIBE4FZqvelWngm1YJyUG8/pNVPZt+4klXSO5TluydnT49CwDygG limi5Xh2jdtnNS/3Y5BWVO88o78s3uWHLpkzsF9dVK1dQ3NXHK8JVP176FwTkg1lAJtb/ohx2C C6Y= X-SBRS: 2.7 X-MesageID: 21024354 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,271,1589256000"; d="scan'208";a="21024354" Subject: Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace) To: Peter Zijlstra CC: Joerg Roedel , Andy Lutomirski , "Joerg Roedel" , Dave Hansen , Tom Lendacky , Mike Stunes , Dan Williams , Dave Hansen , "H. Peter Anvin" , Juergen Gross , Jiri Slaby , Kees Cook , kvm list , LKML , Thomas Hellstrom , Linux Virtualization , X86 ML , "Sean Christopherson" References: <20200425191032.GK21900@8bytes.org> <910AE5B4-4522-4133-99F7-64850181FBF9@amacapital.net> <20200425202316.GL21900@8bytes.org> <20200428075512.GP30814@suse.de> <20200623110706.GB4817@hirez.programming.kicks-ass.net> <20200623113007.GH31822@suse.de> <8413fe52-04ee-f4e1-873c-17595110856a@citrix.com> <20200623124712.GF4817@hirez.programming.kicks-ass.net> From: Andrew Cooper Message-ID: <4113e368-6bc8-51b7-9412-3b4df2633ad6@citrix.com> Date: Tue, 23 Jun 2020 14:57:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200623124712.GF4817@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 23/06/2020 13:47, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 12:51:03PM +0100, Andrew Cooper wrote: > >> There are cases which are definitely non-recoverable. >> >> For both ES and SNP, a malicious hypervisor can mess with the guest >> physmap to make the the NMI, #VC and #DF stacks all alias. >> >> For ES, this had better result in the #DF handler deciding that crashing >> is the way out, whereas for SNP, this had better escalate to Shutdown. >> Crashing out hard if the hypervisor is misbehaving is acceptable. > Then I'm thinking the only sensible option is to crash hard for any SNP > #VC from kernel mode. > > Sadly that doesn't help with #VC needing to be IST :-( IST is such a > frigging nightmare. I presume you mean any #VC caused by RMP faults (i.e. something went wrong with the memory owner/etc metadata) ? If so, then yes.  Any failure here is a bug in the kernel or hypervisor (and needs fixing) or a malicious hypervisor and the guest should terminate for its own safety. ~Andrew