linux-kernel - Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV 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 for Android: free password hash cracker in your pocket

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

Message-ID: <cb1693fc-6876-a448-f485-1a6c70aa6ff5@amd.com>
Date:   Thu, 16 Mar 2017 11:11:26 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Borislav Petkov <bp@...e.de>
CC:     Brijesh Singh <brijesh.singh@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        <simon.guinot@...uanux.org>, <linux-efi@...r.kernel.org>,
        <kvm@...r.kernel.org>, <rkrcmar@...hat.com>,
        <matt@...eblueprint.co.uk>, <linux-pci@...r.kernel.org>,
        <linus.walleij@...aro.org>, <gary.hook@....com>,
        <linux-mm@...ck.org>, <paul.gortmaker@...driver.com>,
        <hpa@...or.com>, <cl@...ux.com>, <dan.j.williams@...el.com>,
        <aarcange@...hat.com>, <sfr@...b.auug.org.au>,
        <andriy.shevchenko@...ux.intel.com>, <herbert@...dor.apana.org.au>,
        <bhe@...hat.com>, <xemul@...allels.com>, <joro@...tes.org>,
        <x86@...nel.org>, <peterz@...radead.org>, <piotr.luc@...el.com>,
        <mingo@...hat.com>, <msalter@...hat.com>,
        <ross.zwisler@...ux.intel.com>, <dyoung@...hat.com>,
        <jroedel@...e.de>, <keescook@...omium.org>, <arnd@...db.de>,
        <toshi.kani@....com>, <mathieu.desnoyers@...icios.com>,
        <luto@...nel.org>, <devel@...uxdriverproject.org>,
        <bhelgaas@...gle.com>, <tglx@...utronix.de>, <mchehab@...nel.org>,
        <iamjoonsoo.kim@....com>, <labbott@...oraproject.org>,
        <tony.luck@...el.com>, <alexandre.bounine@....com>,
        <kuleshovmail@...il.com>, <linux-kernel@...r.kernel.org>,
        <mcgrof@...nel.org>, <mst@...hat.com>,
        <linux-crypto@...r.kernel.org>, <tj@...nel.org>,
        <akpm@...ux-foundation.org>, <davem@...emloft.net>
Subject: Re: [RFC PATCH v2 12/32] x86: Add early boot support when running
 with SEV active

On 3/16/2017 10:09 AM, Borislav Petkov wrote:
> On Thu, Mar 16, 2017 at 09:28:58AM -0500, Tom Lendacky wrote:
>> Because there are differences between how SME and SEV behave
>> (instruction fetches are always decrypted under SEV, DMA to an
>> encrypted location is not supported under SEV, etc.) we need to
>> determine which mode we are in so that things can be setup properly
>> during boot. For example, if SEV is active the kernel will already
>> be encrypted and so we don't perform that step or the trampoline area
>> for bringing up an AP must be decrypted for SME but encrypted for SEV.
>
> So with SEV enabled, it seems to me a guest doesn't know anything about
> encryption and can run as if SME is disabled. So sme_active() will be
> false. And then the kernel can bypass all that code dealing with SME.
>
> So a guest should simply run like on baremetal with no SME, IMHO.
>

Not quite. The guest still needs to understand about the encryption mask
so that it can protect memory by setting the encryption mask in the
pagetable entries.  It can also decide when to share memory with the
hypervisor by not setting the encryption mask in the pagetable entries.

> But then there's that part: "instruction fetches are always decrypted
> under SEV". What does that mean exactly? And how much of that code can

"Instruction fetches are always decrypted under SEV" means that,
regardless of how a virtual address is mapped, encrypted or decrypted,
if an instruction fetch is performed by the CPU from that address it
will always be decrypted. This is to prevent the hypervisor from
injecting executable code into the guest since it would have to be
valid encrypted instructions.

> be reused so that
>
> * SME on baremetal
> * SEV on guest
>
> use the same logic?

There are many areas that use the same logic, but there are certain
situations where we need to check between SME vs SEV (e.g. DMA operation
setup or decrypting the trampoline area) and act accordingly.

Thanks,
Tom

>
> Having the larger SEV preparation part on the kvm host side is perfectly
> fine. But I'd like to keep kernel initialization paths clean.
>
> Thanks.
>