Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp126369pxt; Wed, 11 Aug 2021 16:27:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyYIhB3tX17xp/MCgYzHXad1BMBeCJmAXWidX5mTJXmuA98XAKP/xgQ5MoujdrK0JcNx6Qf X-Received: by 2002:a17:906:f2c9:: with SMTP id gz9mr932544ejb.41.1628724462267; Wed, 11 Aug 2021 16:27:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628724462; cv=none; d=google.com; s=arc-20160816; b=gNQMlgx0TdLvVLKmyMJmMlGu9KidpYNC61cC4ujea0h46xKeTDwMIUPoXHWNi6WP+h sEHQd5br0UHCLl+qf8NaxV59Q+DrOHC8IX+E+njoiUtgmeWwVyaEOs019fQW0E73RDFc Dk0LGB38vAFW2mibtv4Ziyu/XMiJ87xIoGSY5iRsPdMwXbDHJCmAIq/h20Sbxj1fGXcf bzFIE1Lo09GEEgHBAi/2hKaNW9vIGyd3vs1rR2ttPwjH/tG8whiy2RIB1RP+QfO+krXz RABOovuc4j65Ln1au3mxIG8d/qvg0vw3kduPqj6U7u6uERUy9GVkmxz4PCkLvc875jMj rkrg== 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=6xileyVBDLPQbiU9ENYdYPcfwma8KlRoGAsn6NAw+A0=; b=vuSwKrR/WrywNjMVLumRQYSpjm+oMHbXvhVQf0KRIXmE+CFntA1hkX02I3Bg3CEFTq hJ/l6NkthF2NrXKVN5KhATvkQFb8UAVJW6it/bOoMAAH+AyXOVbQCTS3dg8Fe0cy2VnG NjARkZr68pcl+oMFv3wxOk1B03Jdgiuxi6ZpkFMmuIPCgV67IdihzaPVWTsL+I5HVxhD tfkuZgu91nZu0/4ULNySHDybJuQtxQlyBheUpOCk0aE1mTWYu6KyYZ7Zj+R56TjbLi+R cd0OFTymFxN+q/UJr0OuXkSXlEG0CLt47zzpR/CwsJUGMJOjWfPl9bM8lttaIHz0mSZH SZAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=I8nlsUwT; 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 hr1si814545ejc.424.2021.08.11.16.27.18; Wed, 11 Aug 2021 16:27:42 -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=20161025 header.b=I8nlsUwT; 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 S232803AbhHKXZx (ORCPT + 99 others); Wed, 11 Aug 2021 19:25:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232664AbhHKXZx (ORCPT ); Wed, 11 Aug 2021 19:25:53 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DAF2C061765 for ; Wed, 11 Aug 2021 16:25:29 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id mq2-20020a17090b3802b0290178911d298bso7679288pjb.1 for ; Wed, 11 Aug 2021 16:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6xileyVBDLPQbiU9ENYdYPcfwma8KlRoGAsn6NAw+A0=; b=I8nlsUwTR2aHK896/rsgb60Kd9Dn8Y5VCb+a/hhYGJmqUvLVsOpVgThQTr5atV2vS3 o2cktuR/yFT4pIYVxRM/dnSCbgBAtoYdC5fuJ4atfKhvMjMjWukZZ2XgJ8ckBOnKKTB8 os43aGmbO9pCTiOKmsllCOotn8lEBTQW7HHRSuW4rQB9D8YEqVcDTljv4YSmOU4tPVEN Wb0r0eWybnIkESpn5dt17sCCEw/MEQnOhBGzicF3dETZRaoytzBF5VEwJ4qSw7mDXhNI JPZNN4uHn/eYlsjz3g49tXvwRu+Vg36tALMgbBETQS/Ag+LCRGvCX/heSjVQZ55OFLMl Q6lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6xileyVBDLPQbiU9ENYdYPcfwma8KlRoGAsn6NAw+A0=; b=Rkjl8+nh0L35lFunsP9HvZs+1URMAZk3me/Wa62W+gI+UyfPVxEgTVZkwNsCteATzi 8ffQgsZdt+UX+K+sVD8FQScNq1o3no/zSI3+EFDmPZ1/2xhrBRrervepFNHy7sauFbAV z/PAMz6i1WA3z1h3+0JX35aY639G1lqUCfrY0hQ6oA9uQny9f3wkgmIVWlURl26p6zPC rfbxlOz8fkZGH1YNDP9CNjrCnCl2XRLx1Qx+Tjh+zpib14191FNJheZwE9Jdiwt70vob n1sX6bybUkt1lbkDAMmI5fGGcloYcbaejhAe+REtoVvCG1Ly+Sol52PtBjO98arG4E+o U93w== X-Gm-Message-State: AOAM531pq/EE8/saCRaDQg2kuGHnRYsDX1I69SwGUR8nyGcSUAzIUTAV gxuZOEP3lbje1He2cgSFhI680w== X-Received: by 2002:a17:902:8e84:b029:12c:8742:1d02 with SMTP id bg4-20020a1709028e84b029012c87421d02mr1106099plb.38.1628724328540; Wed, 11 Aug 2021 16:25:28 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id l11sm657772pfd.187.2021.08.11.16.25.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Aug 2021 16:25:28 -0700 (PDT) Date: Wed, 11 Aug 2021 23:25:22 +0000 From: Sean Christopherson To: Maxim Levitsky Cc: Emanuele Giuseppe Esposito , kvm@vger.kernel.org, Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] KVM: nSVM: temporarly save vmcb12's efer, cr0 and cr4 to avoid TOC/TOU races Message-ID: References: <20210809145343.97685-1-eesposit@redhat.com> <20210809145343.97685-3-eesposit@redhat.com> <21b14e5711dff386ced705a385f85301761b50a5.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21b14e5711dff386ced705a385f85301761b50a5.camel@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 11, 2021, Maxim Levitsky wrote: > On Mon, 2021-08-09 at 16:53 +0200, Emanuele Giuseppe Esposito wrote: > > @@ -1336,7 +1335,8 @@ static int svm_set_nested_state(struct kvm_vcpu *vcpu, > > if (!(save->cr0 & X86_CR0_PG) || > > !(save->cr0 & X86_CR0_PE) || > > (save->rflags & X86_EFLAGS_VM) || > > - !nested_vmcb_valid_sregs(vcpu, save)) > > + !nested_vmcb_valid_sregs(vcpu, save, save->efer, save->cr0, > > + save->cr4)) > > goto out_free; > > > > /* > The disadvantage of my approach is that fields are copied twice, once from > vmcb12 to its local copy, and then from the local copy to vmcb02, however > this approach is generic in such a way that TOC/TOI races become impossible. > > The disadvantage of your approach is that only some fields are copied and > there is still a chance of TOC/TOI race in the future. The partial copy makes me nervous too. I also don't like pulling out select registers and passing them by value; IMO the resulting code is harder to follow and will be more difficult to maintain, e.g. it won't scale if the list of regs to check grows. But I don't think we need to copy _everything_. There's also an opportunity to clean up svm_set_nested_state(), though the ABI ramifications may be problematic. Instead of passing vmcb_control_area and vmcb_save_area to nested_vmcb_valid_sregs() and nested_vmcb_valid_sregs(), pass svm_nested_state and force the helpers to extract the save/control fields from the nested state. If a new check is added to KVM, it will be obvious (and hopefully fail) if the state being check is not copied from vmcb12. Regarding svm_set_nested_state(), if we can clobber svm->nested.ctl and svm->nested.save (doesn't exist currently) on a failed ioctl(), then the temporary allocations for those can be replaced with using svm->nested as the buffer. And to mitigate the cost of copying to a kernel-controlled cache, we should use the VMCB Clean bits as they're intended. Each set bit in the VMCB Clean field allows the processor to load one guest register or group of registers from the hardware cache; E.g. copy from vmcb12 iff the clean bit is clear. Then we could further optimize nested VMRUN to skip checks based on clean bits.