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;
Date:   Thu, 27 Oct 2022 10:57:32 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Martin Fernandez <martin.fernandez@eclypsium.com>
Cc:     linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
        platform-driver-x86@vger.kernel.org, linux-mm@kvack.org,
        kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org,
        tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com,
        x86@kernel.org, hpa@zytor.com, ardb@kernel.org,
        dvhart@infradead.org, andy@infradead.org,
        gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org,
        akpm@linux-foundation.org, daniel.gutson@eclypsium.com,
        hughsient@gmail.com, alex.bazhaniuk@eclypsium.com,
        alison.schofield@intel.com, keescook@chromium.org
Subject: Re: [PATCH v9 0/9] x86: Show in sysfs if a memory node is able to do
 encryption
Message-ID: <Y1pH/DuYJeo7Kyo5@zn.tnic>
References: <20220704135833.1496303-1-martin.fernandez@eclypsium.com>
 <Y0hrhzprPFTK+VWV@zn.tnic>
 <CAKgze5ajp-z0+F+8Qo2z=834=i=HNa5=s54MLyrk16wQVnxCzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAKgze5ajp-z0+F+8Qo2z=834=i=HNa5=s54MLyrk16wQVnxCzQ@mail.gmail.com>
Precedence: bulk

On Thu, Oct 13, 2022 at 06:00:58PM -0300, Martin Fernandez wrote:
> That's bad, because it would be nice if that attribute only depended
> on the hardware and not on some setting.

Why would that be bad?

You want to be able to disable encryption for whatever reason sometimes.

> The plan of this patch was, as you mentioned just to report
> EFI_MEMORY_CPU_CRYPTO in a per node level.
> 
> Now, I think I will need to check for tme/sme and only if those are
> active then show the file in sysfs, otherwise not show it at all,
> because it would be misleading. Any other idea?

Well, I still think this is not going to work in all cases. SME/TME can
be enabled but the kernel can go - and for whatever reason - map a bunch
of memory unencrypted.

So I don't know what the goal of this fwupd checking whether users have
configured memory encryption properly is. It might end up giving that
false sense of security...

> You mean that EFI_MEMORY_CPU_CRYPTO means nothing on an AMD system?

I mean, you still can disable memory encryption.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette