linux-kernel - Re: [PATCH] x86/efi: Access EFI MMIO data as unencrypted when SEV is active

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: <CAKv+Gu-hWz4UUvvSyG5=RzCWmheva2-yUkSyuCM0_CDERCJihQ@mail.gmail.com>
Date:   Wed, 4 Jul 2018 00:40:46 +0200
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Borislav Petkov <bp@...e.de>
Cc:     Brijesh Singh <brijesh.singh@....com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        KVM devel mailing list <kvm@...r.kernel.org>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH] x86/efi: Access EFI MMIO data as unencrypted when SEV is active

On 3 July 2018 at 23:46, Borislav Petkov <bp@...e.de> wrote:
> On Tue, Jul 03, 2018 at 04:16:57PM -0500, Brijesh Singh wrote:
>> I agree with Ard,  it may be good idea to extend the UEFI spec to
>> include encryption information. Having this information may be helpful
>> in some cases, e.g if we ever need to map a specific non IO memory as
>> unencrypted. So far we have not seen the need for it. But I will ask AMD
>> folks working closely with UEFI committee to float this and submit it as
>> enhancement in Tianocore BZ.
>
> Except that if the IO memory handling unencrypted changes in future
> incarnations, the changes to the spec become moot. I'm just saying...
>

Quite the opposite. If we allocate a EFI_MEMORY_xx bit to signify that
a region should be mapped as encrypted, we no longer have to reason
about these things in the kernel but we can simply apply the
attributes that the UEFI memory map provides us. A platform could then
describe both encrypted and unencrypted MMIO regions at will.