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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 68F39C05027 for ; Fri, 20 Jan 2023 13:21:29 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.481769.746877 (Exim 4.92) (envelope-from ) id 1pIrKT-0005ou-FI; Fri, 20 Jan 2023 13:21:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 481769.746877; Fri, 20 Jan 2023 13:21:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pIrKT-0005on-Cd; Fri, 20 Jan 2023 13:21:13 +0000 Received: by outflank-mailman (input) for mailman id 481769; Fri, 20 Jan 2023 13:21:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pIrKS-0005od-Ad for xen-devel@lists.xenproject.org; Fri, 20 Jan 2023 13:21:12 +0000 Received: from mail.8bytes.org (mail.8bytes.org [85.214.250.239]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 4b99257b-98c5-11ed-b8d1-410ff93cb8f0; Fri, 20 Jan 2023 14:21:06 +0100 (CET) Received: from 8bytes.org (p200300c27714bc0086ad4f9d2505dd0d.dip0.t-ipconnect.de [IPv6:2003:c2:7714:bc00:86ad:4f9d:2505:dd0d]) (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 583BB262AD8; Fri, 20 Jan 2023 13:43:51 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4b99257b-98c5-11ed-b8d1-410ff93cb8f0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=8bytes.org; s=default; t=1674218631; bh=sZNmqKbvZoiovCzlI6WBiaIn/1uSYIe/nS6jVFFARMs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IPQE8Zu4cQksOFQUyswavYY4LJUrlMt8lxJm+3ahDYd+mZFXwGtyKeIQiaTg9xx6t XoR/R4zuZsPcWpd9otIOIqrWFKbf0GyoVlPAjf7IhQpqGh1zw08+91/R5sFqDlxF36 6X3Iigbgw0xZG1NFBkWTE/fIj3zY1tK+FSVOC7yBrZtGOWxNW+nsLLmSbs+C4H1kP3 mk9MA5YIesE4zA1Aabvkey/nokvwF4sQaoft0Cm4GSIXGJ1MS3iEJ2sPjAATJGGzkB SZ5XVMlEyaoXBpIi4mwhOn4QXQHrOE8MkL0RbA3pDV9iCa5bFlLis+fL7yqLWrCJNZ IVfun9JOL6CwQ== Date: Fri, 20 Jan 2023 13:43:50 +0100 From: =?iso-8859-1?Q?J=F6rg_R=F6del?= To: Borislav Petkov Cc: Peter Zijlstra , x86@kernel.org, Joan Bruguera , linux-kernel@vger.kernel.org, Juergen Gross , "Rafael J. Wysocki" , xen-devel , Jan Beulich , Roger Pau Monne , Kees Cook , mark.rutland@arm.com, Andrew Cooper , "H. Peter Anvin" Subject: Re: [PATCH v2 2/7] x86/boot: Delay sev_verify_cbit() a bit Message-ID: References: <20230116142533.905102512@infradead.org> <20230116143645.649204101@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jan 19, 2023 at 02:18:47PM +0100, Borislav Petkov wrote: > So, can we do that C-bit verification once on the BSP, *in C* which would be a > lot easier, and be done with it? > > Once it is verified there, the bit is the same on all APs so all good. Yes, I think this is safe to do. The page-table the APs will use to boot already has the correct C-bit set, and the position is verified on the BSP. Further, the C-bit position is a hardware capability and there is no chance the APs will have it at a different position than the BSP. Even if the HV is lying to the VM by faking CPUID on the APs it wouldn't matter, because the position is not read again on the APs. Regards, Joerg