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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B842C1975A for ; Tue, 17 Mar 2020 22:01:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 46AB820714 for ; Tue, 17 Mar 2020 22:01:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726913AbgCQWBu (ORCPT ); Tue, 17 Mar 2020 18:01:50 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:56009 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726530AbgCQWBu (ORCPT ); Tue, 17 Mar 2020 18:01:50 -0400 Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jEKGu-0000tj-1m; Tue, 17 Mar 2020 23:01:12 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 71BBA101161; Tue, 17 Mar 2020 23:01:11 +0100 (CET) From: Thomas Gleixner To: Borislav Petkov , Dave Hansen Cc: Borislav Petkov , lkml , "Schofield\, Alison" , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Ingo Molnar , x86@kernel.org, Dave Hansen , Andy Lutomirski , Peter Zijlstra , Christoph Hellwig , Marek Szyprowski , Robin Murphy , linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, iommu@lists.linux-foundation.org, Tom Lendacky , "Shutemov\, Kirill" Subject: Re: [PATCH] treewide: Rename "unencrypted" to "decrypted" In-Reply-To: <20200317210602.GG15609@zn.tnic> References: <20200317111822.GA15609@zn.tnic> <2cb4a8ae-3b13-67bd-c021-aee47fdf58c5@intel.com> <20200317210602.GG15609@zn.tnic> Date: Tue, 17 Mar 2020 23:01:11 +0100 Message-ID: <87fte6bpzs.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Borislav Petkov writes: > On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote: >> On 3/17/20 4:18 AM, Borislav Petkov wrote: >> > Back then when the whole SME machinery started getting mainlined, it >> > was agreed that for simplicity, clarity and sanity's sake, the terms >> > denoting encrypted and not-encrypted memory should be "encrypted" and >> > "decrypted". And the majority of the code sticks to that convention >> > except those two. So rename them. >> >> Don't "unencrypted" and "decrypted" mean different things? >> >> Unencrypted to me means "encryption was never used for this data". >> >> Decrypted means "this was/is encrypted but here is a plaintext copy". > > Maybe but linguistical semantics is not the point here. > > The idea is to represent a "binary" concept of memory being encrypted > or memory being not encrypted. And at the time we decided to use > "encrypted" and "decrypted" for those two things. > > Do you see the need to differentiate a third "state", so to speak, of > memory which was never encrypted? I think so. encrypted data is something you can't use without having the key decrypted data is the plaintext copy of something encrypted, so it might be of sensible nature. unencrypted data can still be sensible, but nothing ever bothered to encrypt it in the first place. So having this distinction is useful in terms of setting the context straight. Thanks, tglx