Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp6721775rwl; Mon, 9 Jan 2023 12:06:43 -0800 (PST) X-Google-Smtp-Source: AMrXdXvnHlajBxb5BUNEmT4CoTZ4+UiuDabgl3K8UyH/snC/nlUk+MVwC1RH8XgPgd1O8vrxuWyw X-Received: by 2002:a17:907:c011:b0:7c0:e5ca:411c with SMTP id ss17-20020a170907c01100b007c0e5ca411cmr54100536ejc.17.1673294803392; Mon, 09 Jan 2023 12:06:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673294803; cv=none; d=google.com; s=arc-20160816; b=JG+lC2hdmTgQbvuDcqDCV9vg7pRkERCWv8GOYZal7Sh9RwmS8HshjDdNX5eLOP/r1c ffzvatL9oJfHS73pEd2glyuj9lOkNpiH4bEIzB+myMTGBKjnSBtm4N2h1SibVNMj+TZm FyUY6MplZlw65p4/DBVWlWrqqwmBGF0ttXczBjK/1GtqCYGgOhm9pvgrYGUgyn4KmTcz 76gG8dUpaHpqCkJQHHHZ4WPJIzrDijUbJ9/gQBicm6ejVuqpDQ748WqIdHCGy6z0BvYo /IrnZGDFVisNYzmYp5Bzmtg8KuFKvPGAUNcBj0bI7UgIbBQralA6v34G0hTpR96YOyaD Sp3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=d1aT87qrkvs6HaPvfvslxRbyKpdc9CVfc63ZusxeMkE=; b=jaYNb7X09ITjVoemX4WWsCv3tYTqO2XIgRyIxLewy2pTNzzekfBn6QG8czPCp+3C9Q FHQjn1EiQ0xG335yJhv+KAAC5+RCuGuvlNILEgYMsXchh7zjWfehdyxnVEUFCN496E8K xeaHSR1uCDwEllESnuZFboULiISbIYo3dsXxpXu1aKSrwNkbrT7VcAX9RVyUnxHV0+lu OpZ2/maL0ATWvSm4G/yoysgZggAggsP8AjqkBZHYI/Dv+Xd9M4dRpQ5Sc5gN1CvmAQNh X2Wt+/E5C13q1iZaQpfKApEY47UpQ8BYQa6YUTfSMJz4HRp6E2DaXRPv/hSrqGDDn2AE pQYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=TnvR4QqK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e21-20020a17090658d500b007adaedb2f14si11002378ejs.866.2023.01.09.12.06.30; Mon, 09 Jan 2023 12:06:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=TnvR4QqK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237653AbjAITLm (ORCPT + 53 others); Mon, 9 Jan 2023 14:11:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237625AbjAITLX (ORCPT ); Mon, 9 Jan 2023 14:11:23 -0500 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 260A263EB; Mon, 9 Jan 2023 11:11:00 -0800 (PST) Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (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 2F0891EC03B3; Mon, 9 Jan 2023 20:10:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1673291459; 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=d1aT87qrkvs6HaPvfvslxRbyKpdc9CVfc63ZusxeMkE=; b=TnvR4QqKv79+Uq6ymbdzaI+Rq/etn5FbXa8ZAw3wFMp3b3bflgl210qbftasaj+GTud5rv aQZBVuaihWa6+U4l1ljo2SALrwOOcNsc5mcam4sc94qPv7ewL7l/YStPc0alBcLab9wwPN vQivx8wbkoT2wtcZS2XpxGicLxzUBAk= Date: Mon, 9 Jan 2023 20:10:54 +0100 From: Borislav Petkov To: "Michael Kelley (LINUX)" Cc: "hpa@zytor.com" , KY Srinivasan , Haiyang Zhang , "wei.liu@kernel.org" , Dexuan Cui , "luto@kernel.org" , "peterz@infradead.org" , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "lpieralisi@kernel.org" , "robh@kernel.org" , "kw@linux.com" , "bhelgaas@google.com" , "arnd@arndb.de" , "hch@infradead.org" , "m.szyprowski@samsung.com" , "robin.murphy@arm.com" , "thomas.lendacky@amd.com" , "brijesh.singh@amd.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "dave.hansen@linux.intel.com" , Tianyu Lan , "kirill.shutemov@linux.intel.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "ak@linux.intel.com" , "isaku.yamahata@intel.com" , "Williams, Dan J" , "jane.chu@oracle.com" , "seanjc@google.com" , "tony.luck@intel.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-arch@vger.kernel.org" , "iommu@lists.linux.dev" Subject: Re: [Patch v4 04/13] x86/mm: Handle decryption/re-encryption of bss_decrypted consistently Message-ID: References: <1669951831-4180-1-git-send-email-mikelley@microsoft.com> <1669951831-4180-5-git-send-email-mikelley@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 29, 2022 at 04:25:16PM +0000, Michael Kelley (LINUX) wrote: > I'm ambivalent on the backport to stable. One might argue that older > kernel versions are conceptually wrong in using different conditions for > the decryption and re-encryption. But as you said, they aren't broken > from a practical standpoint because sme_me_mask and > CC_ATTR_MEM_ENCRYPT are equivalent prior to my patch set. However, > the email thread with Sathyanarayanan Kuppuswamy, Tom Lendacky, > and Dexuan Cui concluded that a Fixes: tag is appropriate. Right, just talked to Tom offlist. A Fixes tag triggers a lot of backporting activity and if it is not really needed, then let's leave it out. If distros decide to pick up vTOM support, then they'll pick up the whole set anyway. And if we decide we really need it backported for whatever reason, we will simply send it into stable and the same backporting activity will be triggered then. But then we'd at least have a concrete reason for it. Makes sense? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette