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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F5E2C433EF for ; Thu, 21 Oct 2021 14:51:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4E68761260 for ; Thu, 21 Oct 2021 14:51:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231522AbhJUOxV (ORCPT ); Thu, 21 Oct 2021 10:53:21 -0400 Received: from mail.skyhub.de ([5.9.137.197]:58694 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230390AbhJUOxU (ORCPT ); Thu, 21 Oct 2021 10:53:20 -0400 Received: from zn.tnic (p200300ec2f1912003b8abe7004197216.dip0.t-ipconnect.de [IPv6:2003:ec:2f19:1200:3b8a:be70:419:7216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 7B24D1EC0445; Thu, 21 Oct 2021 16:51:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1634827863; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=mKv+mW+eWPilpLli84rOJtENzeDW72xonp+g0aJny1g=; b=EKa2uK43z8y8RLS1v6/4QDWWFpx+8GluX9zI+Lg880TYbNrjZym5GPV5qbh3949HE1GpNN ty/fQ5oOEQe56ViPLe7zFfZ+h4nLKlbpo2orS3Ze2tkOHmU6vLmR9KeGplW8T9xeJYMCDs 7vdI1K0/Jr0WOUGX9rsaiCwk8vY7Qj8= Date: Thu, 21 Oct 2021 16:51:06 +0200 From: Borislav Petkov To: Michael Roth Cc: Brijesh Singh , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , "Dr . David Alan Gilbert" , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v6 08/42] x86/sev-es: initialize sev_status/features within #VC handler Message-ID: References: <20211008180453.462291-1-brijesh.singh@amd.com> <20211008180453.462291-9-brijesh.singh@amd.com> <20211018184003.3ob2uxcpd2rpee3s@amd.com> <20211020161023.hzbj53ehmzjrt4xd@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211020161023.hzbj53ehmzjrt4xd@amd.com> Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Wed, Oct 20, 2021 at 11:10:23AM -0500, Michael Roth wrote: > The CPUID calls in snp_cpuid_init() weren't added specifically to induce > the #VC-based SEV MSR read, they were added only because I thought the > gist of your earlier suggestions were to do more validation against the > CPUID table advertised by EFI Well, if EFI is providing us with the CPUID table, who verified it? The attestation process? Is it signed with the AMD platform key? Because if we can verify the firmware is ok, then we can trust the CPUID page, right? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette