From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.8bytes.org (mail.8bytes.org [85.214.250.239]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 45D301E8328 for ; Wed, 12 Mar 2025 09:07:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=85.214.250.239 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741770457; cv=none; b=UM1aiK23fLU2WoceA6Q5fITgoy4h3106NCAZozZYBTJAhhwx1recwesdgFIGYOZSOvDeCbIcY+vQBB/nr+AWQ/wWsjIpU6KjbwxFwR72R90RPSRisJsoHYhXvj1/mE9mS7gqZ82XWUl7BnU2dK0UL3yfkLiQFP0fQDeqsKJVHpY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741770457; c=relaxed/simple; bh=2xtik8ZNjcv8YFpKcN5TMzwZKRCzMaZ5Gi4/BrubDos=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ou3x4HfU6DaIQ/hgR+hROLe1kKmGLxS12V/LpL0TOPzNDWCQZyLjTeEWDdpTIHBnqbcnh45ED92NbV6/NaSbwYG79HKD61dQzDFiRJaWlE4X//QldpNdc4YJRdgHxBaJRRrrrR5+WrnSXePAV9+GVGQGLkIBHkaz6LYax03mU+w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=8bytes.org; spf=pass smtp.mailfrom=8bytes.org; dkim=pass (2048-bit key) header.d=8bytes.org header.i=@8bytes.org header.b=vyW8G88A; arc=none smtp.client-ip=85.214.250.239 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=8bytes.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=8bytes.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=8bytes.org header.i=@8bytes.org header.b="vyW8G88A" Received: from 8bytes.org (p4ffe03ae.dip0.t-ipconnect.de [79.254.3.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.8bytes.org (Postfix) with ESMTPSA id DBFEC40E03; Wed, 12 Mar 2025 10:07:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=8bytes.org; s=default; t=1741770454; bh=2xtik8ZNjcv8YFpKcN5TMzwZKRCzMaZ5Gi4/BrubDos=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vyW8G88Ak5OwKJQOIEjJbMtdayD3+0Ob3NUSFqxeEuLBPmBUKReBs7CAusxTNu8Q7 FI04VSBsTnmD89Pmkiri/yxIrF7p7LJkaldLS+QKS8pgCvpogfR9TxpHXJbiCS6jk6 bCiPPVdRpDFc3NLD1YXhf+rUt3Pzjawl4HpRDlaaaSSqNjR9j5xknlTxOvdbg9FLU1 afUy/dd1YIdsZ/8235V5jFfD4KMADuUSMo+gPWmrpSI+PVvPaZtHBBaFDx9WaNPGzb gqMTWgiyTd/wokzr35Upcxgsi5wPlgrN7OVcjFZNjerTZ2RR46yXa5iItZ7bhgLOd1 78nUK+2Eoy16A== Date: Wed, 12 Mar 2025 10:07:32 +0100 From: Joerg Roedel To: "Kirill A. Shutemov" Cc: Joerg Roedel , Alexey Gladkov , Borislav Petkov , =?iso-8859-1?Q?J=FCrgen_Gro=DF?= , "Alexey Gladkov (Intel)" , Dave Hansen , Ingo Molnar , x86@kernel.org, hpa@zytor.com, Tom Lendacky , Nikunj A Dadhania , linux-kernel@vger.kernel.org, Larry.Dewey@amd.com Subject: Re: [PATCH] x86/sev: Make SEV_STATUS available via SYSFS Message-ID: References: <104b6d4f-2848-42f4-a134-3373d12d9424@suse.com> <29fa0d10-0d3d-47a0-8832-b2c7fc04f637@suse.com> <20250311110748.GCZ9AZhPYYAz-MXErv@fat_crate.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Mar 12, 2025 at 10:48:37AM +0200, Kirill A. Shutemov wrote: > There might be a value to have consistent structure for host and guest > information in sysfs, even if they are presented in different places under > /sys. There's subset of information that is common for both guest and > host, like version. I agree for the host side, but for the guest side I am less convinced. Any information exposed via sysfs on the guest side can not be trusted. The only trusted way to get this information in the guest is a successfully verified attestation report. The same is true for exposing SEV_STATUS, btw. This can also only be trusted together with a verified attestation. But the difference is that SEV_STATUS is not part of the attestation report. One might say that this does not matter much for debugging purposes, but the question stands whether it helps the security posture of the TEE to expose an untrusted interface which tooling then uses instead of the trusted variant. Regards, Joerg