Received: by 2002:a05:6520:1682:b0:147:d1a0:b502 with SMTP id ck2csp5598693lkb; Mon, 11 Oct 2021 09:41:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLGwJjGo92er1B3RrFgqWOvI8MEQW6eXfmeevpWy+THGhOI8QmBM/3Kg5wA82K/harou7Z X-Received: by 2002:a17:906:69c3:: with SMTP id g3mr27806883ejs.265.1633970478644; Mon, 11 Oct 2021 09:41:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633970478; cv=none; d=google.com; s=arc-20160816; b=s3EkM5vKdA/c1fjkM2OsRseiFK4iX2Qr0v5ZW+M6hOAT8Q/8vckKQ/5Vuw0oQdX52m oSTcpu7dpiPqWY2BheRgbQ3kTlRCtzg7uP4VsKyLwR83TQwJPnLLwLpxCoDL7SgZH+ml tLshNXq3+nhHryUvaSSgSX3ismDx+8S7lqNtF9o2/up2HOPd5kG/WLmFujgFpwxb5ePA +W9V8J62Kg4N1F3dX4INZcpArTjqpGZFZg9PO4g39KnCABsesbLAdNSPEfmA5nMzz+1W OHYmBw61eBai7xNW/TUXyFrz4J5VnHZyZcPVCWSWucEN1eKHeQAYZDdGWwcSQ76L9QfO Ud7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ES0x4KKi213NBYwRVGpLwmppAh4kTz9W8sOWXXeERdE=; b=XLeWxphYG7YdFEGjdZUo7oaT3W56MSjnaiAqxrneZ4TNFQKnxd+a4MBTNdwbuBxnE5 tYvtq68r4BbyclPAW63z5luWAP00uPoNUIWmElDnlBqobfwdKhyFE+3ZNZpZ50MxWX7Z p6PWLMdZOpw5HVHpXxvG9Xr2Qn2Mn+waMXAmR7ReHXHKfQBAsQdF2SrTPpH0wMNR8KPm NrHjSZlVXK85HCU4nUZqwlkMGy/EwLNYRbe9NFWzLcjhN5DHdFFVjkq9+KMDZrBczwoT T3Rl1RZ+hzLqBs6MZyPPBRz9dsm1MLR0Mk+iB9w+kKIR+Qy1WbIQVRSxP+knnS0GPg8+ giKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sgBTxJ6b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hh20si16097617ejb.10.2021.10.11.09.40.55; Mon, 11 Oct 2021 09:41:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sgBTxJ6b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233535AbhJKPIT (ORCPT + 99 others); Mon, 11 Oct 2021 11:08:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233481AbhJKPIQ (ORCPT ); Mon, 11 Oct 2021 11:08:16 -0400 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD887C061745 for ; Mon, 11 Oct 2021 08:06:16 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id c29so15089551pfp.2 for ; Mon, 11 Oct 2021 08:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ES0x4KKi213NBYwRVGpLwmppAh4kTz9W8sOWXXeERdE=; b=sgBTxJ6bOpXaNmhkrBXsEoQw4rIy/dIleE6rK90FOuieGJ2a4gVZmJWAfHjR0Yt0yF LR6VJK7kjCueP5x820M7LMQr3/z6k3Fdsm6N3nBxxqa1eCRP8TsJ/EAGjJnbtaq2sujf c0hrAGdTEBwaxDC4ehCOm6+uFYHrP0gQSCm8qmiX7IurFeRmHHQGhL73ualnsDPFAV5g IdmFluPMqkXHU8D8oGC8rvfAq+JxhqEqtXaj9EKy5dR4BN+gHTLLucTvRBhKg2P2h/SW IxdYu/Bq71ojz80eZy/OFf4+q4oxBJ1akW7jxBo0vMHZlRaEuodrJKq5dK2LFM70o6JA 73eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ES0x4KKi213NBYwRVGpLwmppAh4kTz9W8sOWXXeERdE=; b=zoDHul71AL1tMw1YNJQLyf0xxvVyL35zwSJVKYyumLhcmR8JPj2sXYVgbHIRIUuJAY S2Y2mmwPnDNCYtMLqZQ/6SjFPr06HwsPInAmrT0hrn25tYu0SqmE8Vbzcg9BGzTNPpHq RRIAmE6vRN7SokAtJLQ5pnjl232jfH0PTcFdcQZkyWNVgkHDhdXqntQts700ghX2mnjk fhi1NVS2ojnoDHRWBmqNevh3MnPTG47q9PYsjVSDG4foBHJXqFd04y5kHLMF+koBNneC 1cMlmlMVcrJgf3YLTzfRAI3VMY1QD24FDeKQvqXrTnvkJnxpGge/icza7+5qJbQ9SYwF bRww== X-Gm-Message-State: AOAM530hkqrz3wVK0+/pOHpd0mgdFDbJNwKhHsTqMQnAvrn1n1x4UB7k sMWqD6ekzlejHDQXjBjYzeDkoQ== X-Received: by 2002:a63:ac09:: with SMTP id v9mr18351405pge.355.1633964775941; Mon, 11 Oct 2021 08:06:15 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id r14sm8567066pgf.49.2021.10.11.08.06.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Oct 2021 08:06:15 -0700 (PDT) Date: Mon, 11 Oct 2021 15:06:11 +0000 From: Sean Christopherson To: Lai Jiangshan Cc: Kuppuswamy Sathyanarayanan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , Paolo Bonzini , David Hildenbrand , Andrea Arcangeli , Josh Poimboeuf , Juergen Gross , Deep Shah , VMware Inc , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Peter H Anvin , Dave Hansen , Tony Luck , Dan Williams , Andi Kleen , Kirill Shutemov , Kuppuswamy Sathyanarayanan , LKML Subject: Re: [PATCH v8 06/11] x86/traps: Add #VE support for TDX guest Message-ID: References: <20211005025205.1784480-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20211005025205.1784480-7-sathyanarayanan.kuppuswamy@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 09, 2021, Lai Jiangshan wrote: > On Tue, Oct 5, 2021 at 10:54 AM Kuppuswamy Sathyanarayanan > wrote: > > > > > The entry paths do not access TD-shared memory, MMIO regions or use > > those specific MSRs, instructions, CPUID leaves that might generate #VE. > > In addition, all interrupts including NMIs are blocked by the hardware > > starting with #VE delivery until TDGETVEINFO is called. This eliminates > > the chance of a #VE during the syscall gap or paranoid entry paths and > > simplifies #VE handling. Minor clarification: it eliminates the chance of a #VE during the syscall gap _if the VMM is benign_. If the VMM is malicious, it can unmap and remap the syscall page to induce an EPT Violation #VE due to the page not being accepted. > Hello > > If the reason is applied to #VE, I think it can be applied to SVM-ES's > #VC too. (I wish the entry code for #VC to be simplified since I'm > moving some the asm entry code to C code) > > And I'm sorry I haven't read all the emails. > Has the question asked by Andy Lutomirski been answered in any emails? > > https://lore.kernel.org/lkml/CALCETrU9XypKbj-TrXLB3CPW6=MZ__5ifLz0ckbB=c=Myegn9Q@mail.gmail.com/ This question? Can the hypervisor cause an already-accepted secure-EPT page to transition to the unaccepted state? Yep. I wrote the above before following the link, I should have guessed which question it was :-) IIRC, the proposed middle ground was to add a TDCALL and/or TDPARAMS setting that would allow the guest to opt-out of EPT Violation #VE due to page not accepted, and instead terminate the VM on such a condition. The caveat is that that would require the kernel to never take an "page not accepted #VE" when doing lazy page acceptance, but that was deemed doable. That also raises the question of whether Andy's NAK applies to SEV-SNP without support for "Enhanced SYSCALL Behavior"[*], otherwise SEV-SNP has the same "#VC in syscall gap" attack. [*] https://www.amd.com/system/files/TechDocs/57115.pdf