linux-kernel - Re: [PATCH] Ability to read the MKTME status from userspace

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]

Message-ID: <CAD2FfiEit9HR_ikc3WQXg9c_hyNHtk6b0rVnYJd-R8gJ7tbQOw@mail.gmail.com>
Date:   Fri, 19 Jun 2020 16:02:19 +0100
From:   Richard Hughes <hughsient@...il.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Daniel Gutson <daniel@...ypsium.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh@...nel.org>, Tony Luck <tony.luck@...el.com>,
        Rahul Tanwar <rahul.tanwar@...ux.intel.com>,
        Xiaoyao Li <xiaoyao.li@...el.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Ability to read the MKTME status from userspace

On Fri, 19 Jun 2020 at 15:48, Dave Hansen <dave.hansen@...el.com> wrote:
> You cut out the important part.  The "pretty sure" involves a bunch of
> preconditions and knowing what your hardware configuration is in the
> first place.

Totally agree.

> Let's take a step back.  We add read-only ABIs so that decisions can be
> made.  What decision will somebody make from the ABI being proposed here?

The question of "is my memory encrypted" is what I'm trying to decide.
To the end user (or the person marking a compliance ticksheet for a
government contract) all they want to know is the end result. At the
moment for AMD SME this seems much simpler as there are less
"preconditions".

> Someone does 'cat /proc/mktme' (or whatever) and it says "1" or
> whatever, which means yay, encryption is on.  What do they do?

I think "is my memory encrypted" for Intel has to be a superset of:

1. TME in CPU info
2. not disabled by the platform
3. not using unencrypted swap
4. not using a memory accelerator
5. entire DRAM area is marked with EFI_MEMORY_CPU_CRYPTO

It seems the only way to answer the questions and make it easy for the
consumer to know the answer is to ask the kernel for each of the 5
different questions. At the moment we can only get 1, 3, maybe 4, soon
to be 5, but not 2.

Richard.