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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20B79C77B6E for ; Thu, 13 Apr 2023 22:48:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230151AbjDMWsI (ORCPT ); Thu, 13 Apr 2023 18:48:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229567AbjDMWsG (ORCPT ); Thu, 13 Apr 2023 18:48:06 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB4FB10E5 for ; Thu, 13 Apr 2023 15:48:05 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id j2-20020a170902da8200b001a055243657so8777001plx.19 for ; Thu, 13 Apr 2023 15:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681426085; x=1684018085; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=7De+TR6k41slfMO+agxwSRrezzAt0xmZupWS+SIbKtw=; b=wripiq38optx0A61pEC4QlxbrXV9310O1yzg1yey6FDBM3X/3bgYqN6lxWXAho4x2Z b6b8/UzbX9j9h1jSPKzj89XyFovpOpw/PUeQ+0GvEyzDHVuB9wwO+dRPlFUrwpcPIhI7 ZKFw3DZ6ofccfo/zAQ44f4r2Rnwpb31HNbaYHWZM7/iPJ8BqRh4jIGV4uQ+CkeOUZdg3 u48pLtetbVssXKzdARwdPIHvlDYgsEuJYGdtXo6rIARliioKNY1De8ejJNY0TMvYlSp8 h9hcvepeqxGnrQjEb7GXmqTSAyAJ2JP9Q5UDMfqYZgFhQHMz1CjlVzVpjKCaNG57B1z6 wPYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681426085; x=1684018085; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7De+TR6k41slfMO+agxwSRrezzAt0xmZupWS+SIbKtw=; b=GAmbpKVwrBK5X6ukz+PNCyE7vjSE8d/eZ0qRn02IO41trQckiL8nMDN8miUfMd4Gpw XHzKO8NO8F/22wqlqSQZljqDY/HSmdr65ZoVtfxzpKLynZAJRVadWRJzwKh8P5XFlCJz MW6xnLF9ACvxXOTYMDPopfH7ErmB0fDO3UQws/mPV8YReXx8BMSY9UJemA9z1DcWW0sU SvdHwuBFBHwvSeZwh5ZUcpPzq75LhakUyeH3BhAYvldB7Tqn0llkw5rscJP/Xfl1JYTv fHpq0ur2bTkIAq5U1RhajWRPBnDof+NEvYDb6f6PCMiGfnpXgdEiURaGXrXF6CrDnR4V 0QGw== X-Gm-Message-State: AAQBX9ecTOzkIUTgWuI90N3YU1sx5PPebd2wpThHIa3q5j/Z00u9bn5a A+/Wsrde5JsYlTG6q9rKa6Dm0pht3Us= X-Google-Smtp-Source: AKy350b/OBsmKfKzcv0b+1digNdsex0QQ/cOy6US20y18DtoSSeFH/BrW0XfTLmwilEqK6wAU2/PGGYKlM4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:25d3:b0:1a4:f282:91c7 with SMTP id jc19-20020a17090325d300b001a4f28291c7mr216045plb.6.1681426085409; Thu, 13 Apr 2023 15:48:05 -0700 (PDT) Date: Thu, 13 Apr 2023 15:48:04 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230405005911.423699-1-seanjc@google.com> <20230406130119.000011fe.zhi.wang.linux@gmail.com> Message-ID: Subject: Re: [PATCH 0/3] KVM: x86: SGX vs. XCR0 cleanups From: Sean Christopherson To: Kai Huang Cc: "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "zhi.wang.linux@gmail.com" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 13, 2023, Kai Huang wrote: > On Wed, 2023-04-12 at 08:22 -0700, Sean Christopherson wrote: > > KVM's uAPI for initiating TDH.MNG.INIT could obviously filter out > > unsupported leafs, but doing so would lead to potential ABI breaks, e.g. if a leaf > > that KVM filters out becomes known to the TDX Module, then upgrading the TDX Module > > could result in previously allowed input becoming invalid. > > How about only filtering out PV related CPUIDs when applying CPUIDs to > TDH.MNG.INIT? I think we can assume they are not gonna be known to TDX module > anyway. Nope, not going down that road. Fool me once[*], shame on you. Fool me twice, shame on me :-) Objections to hardware vendors defining PV interfaces aside, there exist leafs that are neither PV related nor known to the TDX module, e.g. Centaur leafs. I think it's extremely unlikely (understatement) that anyone will want to expose Centaur leafs to a TDX guest, but again I want to say out of the business of telling userspace what is and isn't sane CPUID models. [*] https://lore.kernel.org/all/20221210160046.2608762-6-chen.zhang@intel.com > > Even if that weren't the case, ignoring KVM_SET_CPUID{2} would be a bad option > > becuase it doesn't allow KVM to open behavior in the future, i.e. ignoring the > > leaf would effectively make _everything_ valid input. If KVM were to rely solely > > on TDH.MNG.INIT, then KVM would want to completely disallow KVM_SET_CPUID{2}. > > Right. Disallowing SET_CPUID{2} probably is better, as it gives userspace a > more concrete result. > > > > > Back to Zhi's question, the best thing to do for TDX and SNP is likely to require > > that overlap between KVM_SET_CPUID{2} and the "trusted" CPUID be consistent. The > > key difference is that KVM would be enforcing consistency, not sanity. I.e. KVM > > isn't making arbitrary decisions on what is/isn't sane, KVM is simply requiring > > that userspace provide a CPUID model that's consistent with what userspace provided > > earlier. > > So IIUC, you prefer to verifying the CPUIDs in SET_CPUID{2} are a super set of > the CPUIDs provided in TDH.MNG.INIT? And KVM manually verifies all CPUIDs for > all vcpus are consistent (the same) in SET_CPUID{2}? Yes, except KVM doesn't need to verify vCPUs are consistent with respect to each other, just that each vCPU is consistent with respect to what was reported to the TDX Module. > Looks this is over-complicated, _if_ the "only filtering out PV related CPUIDs > when applying CPUIDs to TDH.MNG.INIT" approach works. It's not complicated at all. Walk through the leafs defined during TDH.MNG.INIT, reject KVM_SET_CPUID if a leaf isn't present or doesn't match exactly. Or has the TDX spec changed and it's no longer that simple?