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 1CB02C433EF for ; Thu, 23 Jun 2022 22:36:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229540AbiFWWgV (ORCPT ); Thu, 23 Jun 2022 18:36:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbiFWWgT (ORCPT ); Thu, 23 Jun 2022 18:36:19 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64EF750E28 for ; Thu, 23 Jun 2022 15:36:18 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id 9so728936pgd.7 for ; Thu, 23 Jun 2022 15:36:18 -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=BTIgkUt/48vjwewEjU9IxungLanIaqlKh/SLuzUnxW8=; b=RrSsDDhpkfmh/93ukUREG5c2Kn0Yg18gSfBi6eJ2rFn3uAxUl7o02Dw4httkbHRvGR N2973T3V/PSs8qlOjCzz6cLbeFspuBnx3+QcM/YctYSmryvIFy6c41h/dpKCZFGe9ywC u/V0fX5YCarOYM9/7rqJg/zcaCHolBG189q/cisNemTvGNHvJEo1MruXT9mgAgmsbjHw Jt+U64s9Zy/musXJXYahT3+jB6NS3E/ymNyu3gHzfW9a1pOXeGsVv3xwMNE5yJZ/JQwX WwRYy3RKk3fHYaGVGQ5uGWnlN0ighUxCcWPzmQYRFY3+C0pBF+2Ni3C689gWYBbt0gDZ OQyA== 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=BTIgkUt/48vjwewEjU9IxungLanIaqlKh/SLuzUnxW8=; b=dLBDOwToVkhXhDhlpXkZwtTvylczURS6F/pFTm5IK//RVI0xDlcRaeOZ+FYZc0msqC N/dnAFN462XqyMSOi/ZeU/6iixFuVRiHlvPW98KYdpry5HPjHUoIAn+lkoA8VeJoaqFT WX7OOumPmEHplLSAGv1WiFuhQdz/S6rmKnvd4hM3DeuO+XRgYewCrwGa5j5nh6nsTABG DeOH09Cts/5eRaOIJMY8HErMpWTJPdg5VxfZNQLKZjj4XZ6Cl738PfwdM/NJKY88PnwO jNbziDoYDWchNIoyZkbwR1zLu9KO6Sn+sSQxjIbJcXoGoK/KfkTMimRP2zyuc3vX7QBa lTqQ== X-Gm-Message-State: AJIora+wh7dVKzrVJ7sy5j4ZlcvK0WZWNAQIUxYNbAh1zlmz+O3BhkQl jRTkKVlCPJH15eFW2khJRCWTWw== X-Google-Smtp-Source: AGRyM1u6KCaymoEQRa/9nnIjGl1gKuRl4oeOLYwzK0C4D+k0Jn2QSlDuhvvoXtdozKr/n5Lzp3xvEg== X-Received: by 2002:a63:8c47:0:b0:40d:2d4:e3a2 with SMTP id q7-20020a638c47000000b0040d02d4e3a2mr9566670pgn.2.1656023777743; Thu, 23 Jun 2022 15:36:17 -0700 (PDT) Received: from google.com (123.65.230.35.bc.googleusercontent.com. [35.230.65.123]) by smtp.gmail.com with ESMTPSA id n10-20020a170902e54a00b0016191b843e2sm285051plf.235.2022.06.23.15.36.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 15:36:17 -0700 (PDT) Date: Thu, 23 Jun 2022 22:36:13 +0000 From: Sean Christopherson To: "Kalra, Ashish" Cc: Dave Hansen , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , "linux-mm@kvack.org" , "linux-crypto@vger.kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "jroedel@suse.de" , "Lendacky, Thomas" , "hpa@zytor.com" , "ardb@kernel.org" , "pbonzini@redhat.com" , "vkuznets@redhat.com" , "jmattson@google.com" , "luto@kernel.org" , "dave.hansen@linux.intel.com" , "slp@redhat.com" , "pgonda@google.com" , "peterz@infradead.org" , "srinivas.pandruvada@linux.intel.com" , "rientjes@google.com" , "dovmurik@linux.ibm.com" , "tobin@ibm.com" , "bp@alien8.de" , "Roth, Michael" , "vbabka@suse.cz" , "kirill@shutemov.name" , "ak@linux.intel.com" , "tony.luck@intel.com" , "marcorr@google.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "alpergun@google.com" , "dgilbert@redhat.com" , "jarkko@kernel.org" Subject: Re: [PATCH Part2 v6 05/49] x86/sev: Add RMP entry lookup helpers Message-ID: References: <25be3068-be13-a451-86d4-ff4cc12ddb23@intel.com> <681e4e45-eff1-600c-9b81-1fa9bdf24232@intel.com> <99d72d58-a9bb-d75c-93af-79d497dfe176@intel.com> <5db37cc2-4fb1-7a73-c39a-3531260414d0@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-crypto@vger.kernel.org On Wed, Jun 22, 2022, Kalra, Ashish wrote: > On 6/22/22 12:43, Kalra, Ashish wrote: > >>> I think that needs to be fixed. It should be as simple as a > >>> model/family check, though. If someone (for example) attempts to use > >>> SNP (and thus snp_lookup_rmpentry() and dump_rmpentry()) code on a > >>> newer CPU, the kernel should refuse. > >> More specifically I am thinking of adding RMP entry field accessors so > >> that they can do this cpu model/family check and return the correct > >> field as per processor architecture. > > >That will be helpful down the road when there's more than one format. But, > >the real issue is that the kernel doesn't *support* a different RMP format. > >So, the SNP support should be disabled when encountering a model/family > >other than the known good one. > > Yes, that makes sense, will add an additional check in snp_rmptable_init(). And as I suggested in v5[*], bury the microarchitectural struct in sev.c so that nothing outside of the few bits of SNP code that absolutely need to know the layout of the struct should even be aware that there's a struct overlay for RMP entries. [*] https://lore.kernel.org/all/YPCAZaROOHNskGlO@google.com