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]

Date:   Fri, 19 Jun 2020 12:41:14 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Richard Hughes <hughsient@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Daniel Gutson <daniel@...ypsium.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
        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, Jun 19, 2020 at 9:47 AM Richard Hughes <hughsient@...il.com> wrote:
>
> On Fri, 19 Jun 2020 at 17:41, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > > Yes. I want to show the user *why* TME is not available.
> > So even if it is "available" that's fine, even if it is not being used?
>
> No, it's just one more thing we can check and report. For instance,
> "Full memory encryption: NO [firmware-disabled, unencrypted-swap, EFI
> memory map incomplete]

The list is bigger than this, and it will probably get even bigger in
the future.  For example, if the specific thing you care about is "is
my memory encrypted on the DIMM", choices include:

 - Yes, mostly, TME
 - Yes, mostly, SME
 - Yes, mostly, SEV (which comes in several variants)
 - Yes, because this is actually a Graphene SGX enclave or similar.
 - No, your memory controller can't do this.
 - No.  Although your memory controller can do this, it isn't right
now, because [reason].
 - (in the future, maybe) Partially, because *MK* TME is enabled and
encryption depends on the specific policy.
 - (in the future, maybe) No, but you think yes, because MKTME is
enabled and you used a fixed key that is stored somewhere.
 - (in the future, maybe) Maybe, because some memory is encrypted and
some isn't.

But if what you *actually* care about is whether someone who resets
the system and takes over gets to learn the contents of the DIMMs
(i.e. a "cold-boot attack"), then there are more answers:

 - Protected because of TXT: the memory controller will not allow
reads until the DIMMs are cleared.
 - Protected because of whatever AMD's equivalent is.
 - Protected to some extent because the installed firmware will wipe
memory on reset.

If you care about whether the contents of anonymous memory will be
encrypted at rest on swap, then you care about what the swap backing
store is *and* where the key came from.

If you care about whether and to what degree the contents of anonymous
memory are protected from a malicious hypervisor, the answer is
complicated.

I don't object in principle to Linux giving userspace more visibility
into what's going on, but I'm not convinced that adding a new
must-support-for-a-long-time interface that only solves 5% of your
problem is worth it.  Especially if, some day, the shiny new interface
says "TME is on", but this really means "MKTME is on and the
administrator configured it to only encrypt specific things for
performance reasons".