From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D5B48C09 for ; Mon, 9 Jan 2023 19:11:01 +0000 (UTC) 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> Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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