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 C4503C433EF for ; Mon, 18 Apr 2022 22:50:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232846AbiDRWw4 (ORCPT ); Mon, 18 Apr 2022 18:52:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232756AbiDRWww (ORCPT ); Mon, 18 Apr 2022 18:52:52 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25AB1DF07 for ; Mon, 18 Apr 2022 15:50:12 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id n11-20020a17090a73cb00b001d1d3a7116bso817644pjk.0 for ; Mon, 18 Apr 2022 15:50:12 -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=qzBPeq4Z1Lm/THhXP/p+Guvp3S0k6RUjKQr12jgDsss=; b=hLZrBdUqWLV/GYiIngWtZXbHDACKG/z6epibpsJFq1BaIhs2Z2KJfmWYmL7JO8Vs5k 4swMjagpii7pBDxG9mRqPPeS6+cXe1apDmO4ek/Qv/mUAJpFaHx9fhZDvMXAl0AlShoJ XYxbWbjmNfZ32PLyYRZM4m4EXp55UekXWcwtBstrxxz6hHxw7520F0RQzIFyToh8VP+D Ffs8JDKtdWvIpEbxcRKUFlIVYZe53XaVIxtRxrDLAJS9WEBVF5gJL1ic/B5qPNae79ZJ yjrkV6x3IGT0C7jaHqXpaQxE41HZ84QaMG7W4wvJaomQFPKmNNzqNhQelaGrVlO38sDw jFTQ== 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=qzBPeq4Z1Lm/THhXP/p+Guvp3S0k6RUjKQr12jgDsss=; b=nrRDgJH7MkXXlxKtJa/1/lifk9BYU1S2WaZBzwcXJq+oGfNM7AjcnKjdtoGARJitkq GfIXsdJQgGonKwNl3oyM0iF4flia1WXd7ylTGzMM0G9Y3wIwYYAWD5uHjBzQJBgxVDRs xgQlDFC9n2feoXb9GVFAbnTu2jOvIl4+C0Ce+ITSxL6o6zzlPcEZuBLWUbl62NWax6Cb zB5eVJx0FutT+ugmDT2uem2Y1sZXJ4nKtEZ3lsbqQLejvSc5v+N28bi0u0jbF32XYDC4 Q5uYypwHcD4JhCoUS9Fjae49rUjxN3niIAW8JcY+YenvZ/MNWjt9uRoRP5B18G+8CcVD t5wg== X-Gm-Message-State: AOAM5317YMfuxTZ77nNN3duE/XCf+26cM6guHcHLJDZcgUSsCP4U5kcR SHZE1BI0g13t5Yra41ujGBbSKw== X-Google-Smtp-Source: ABdhPJw+yaMkUZUnbOjaOzUM4WWyFmXWGGeEaX9APFm/5xhK/PVs2+8n3UnfCm5Ue6KnHOXHo1K/8w== X-Received: by 2002:a17:902:7404:b0:158:bff8:aa13 with SMTP id g4-20020a170902740400b00158bff8aa13mr12845518pll.133.1650322211428; Mon, 18 Apr 2022 15:50:11 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id bt21-20020a056a00439500b0050a4dfb7c44sm10012680pfb.155.2022.04.18.15.50.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Apr 2022 15:50:10 -0700 (PDT) Date: Mon, 18 Apr 2022 22:50:07 +0000 From: Sean Christopherson To: Sathyanarayanan Kuppuswamy Cc: Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, pbonzini@redhat.com, dave.hansen@intel.com, len.brown@intel.com, tony.luck@intel.com, rafael.j.wysocki@intel.com, reinette.chatre@intel.com, dan.j.williams@intel.com, peterz@infradead.org, ak@linux.intel.com, kirill.shutemov@linux.intel.com, isaku.yamahata@intel.com Subject: Re: [PATCH v3 01/21] x86/virt/tdx: Detect SEAM Message-ID: References: <8e2269a7-3e71-5030-8d04-1e8e3fc4323f@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8e2269a7-3e71-5030-8d04-1e8e3fc4323f@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 18, 2022, Sathyanarayanan Kuppuswamy wrote: > > +static void detect_seam_ap(struct cpuinfo_x86 *c) > > +{ > > + u64 base, mask; > > + > > + /* > > + * Don't bother to detect this AP if SEAMRR is not > > + * enabled after earlier detections. > > + */ > > + if (!__seamrr_enabled()) > > + return; > > + > > + rdmsrl(MSR_IA32_SEAMRR_PHYS_BASE, base); > > + rdmsrl(MSR_IA32_SEAMRR_PHYS_MASK, mask); > > + > > + if (base == seamrr_base && mask == seamrr_mask) > > + return; > > + > > + pr_err("Inconsistent SEAMRR configuration by BIOS\n"); > > Do we need to panic for SEAM config issue (for security)? No, clearing seamrr_mask will effectively prevent the kernel from attempting to use TDX or any other feature that might depend on SEAM. Panicking because the user's BIOS is crappy would be to kicking them while they're down. As for security, it's the TDX Module's responsibility to validate the security properties of the system, the kernel only cares about not dying/crashing. > > + /* Mark SEAMRR as disabled. */ > > + seamrr_base = 0; > > + seamrr_mask = 0 > > +}