linux-kernel - Re: [PATCH v6 6/6] drivers/node: Show in sysfs node's crypto capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Feb 2022 11:49:21 -0600
From:   "Limonciello, Mario" <mario.limonciello@....com>
To:     Tom Lendacky <thomas.lendacky@....com>,
        Borislav Petkov <bp@...en8.de>
Cc:     Martin Fernandez <martin.fernandez@...ypsium.com>,
        linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
        platform-driver-x86@...r.kernel.org, linux-mm@...ck.org,
        tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
        x86@...nel.org, hpa@...or.com, ardb@...nel.org,
        dvhart@...radead.org, andy@...radead.org,
        gregkh@...uxfoundation.org, rafael@...nel.org, rppt@...nel.org,
        akpm@...ux-foundation.org, daniel.gutson@...ypsium.com,
        hughsient@...il.com, alex.bazhaniuk@...ypsium.com,
        alison.schofield@...el.com, keescook@...omium.org
Subject: Re: [PATCH v6 6/6] drivers/node: Show in sysfs node's crypto
 capabilities

On 2/4/2022 11:12, Tom Lendacky wrote:
> On 2/4/22 10:28, Borislav Petkov wrote:
>> On Fri, Feb 04, 2022 at 10:23:22AM -0600, Limonciello, Mario wrote:
>>>>>> As there is interest in seeing these capabilities from userspace, it
>>
>> This needs to be explained in a lot more detail: why, what is going to
>> use it, how, etc.
>>
>> We don't do user-visible APIs just because.

The fwupd daemon has a feature that measures various security aspects of 
the system hardware, software and firmware and reflects it out to 
consumers (fwupd clients) in an easily consumable format, in some cases 
with actionable notes.

In this case the information would be used to make a check about memory 
encryption support and enablement.  If a sysfs file was made then it 
could be something like this:

1) fwupd checks /sys/security/memory_encryption
1: You're encrypted, here's a gold star.
0: keep checking

2) fwupd checks does /proc/cpuinfo have sme, sev_es, or mktme?
No: Your hardware doesn't support encryption, tell the user.
Yes: keep going.
3)AMD?
    Check /proc/cmdline, Did user set mem_encrypt=off on explicitly? 
That's why. Tell user they can enable it with mem_encrypt=on or 
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
    mem_encrypt=on/CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT?
    We've got a kernel or hardware problem.

4) Intel?
    Document Intel's path to turn it on.

>>
>>> As Tom agreed in previous post, Boris is mistaken here.  I just double
>>> checked on my side on a workstation that supports SME and comparing
>>> /proc/cpuinfo before and after SME is enabled via mem_encrypt=on.  I
>>> confirmed that nothing changed.
>>
>> Then we should clear that "sme" flag if memory encryption is not
>> enabled. Like we do for all other flags.
> 
> If we do that, then this will have to be re-worked:
> 
> https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/process.c#L761 
> 

I guess if sme/sev/sev_es "are" torn out of cpuinfo when encryption is 
turned off then that "could" instead do the MSR read perhaps?

> 
> Thanks,
> Tom
> 
>>