Message-ID: <20170316162923.m2qh4mhkxzg3lpme@pd.tnic>
Date:   Thu, 16 Mar 2017 17:29:23 +0100
From:   Borislav Petkov <bp@...e.de>
To:     Tom Lendacky <thomas.lendacky@....com>
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 Thu, Mar 16, 2017 at 11:11:26AM -0500, Tom Lendacky wrote:
> 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.

Ok, so the kernel - by that I mean both the baremetal and guest kernel -
needs to know whether we're encrypting stuff. So it needs to know about
SME.

> "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.

Ok, so the guest needs to map its pages encrypted.

Which reminds me, KSM might be a PITA to enable with SEV but that's a
different story. :)

> 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.

Right, and I'd like to keep those areas where it differs at minimum and
nicely cordoned off from the main paths.

So looking back at the current patch in this subthread:

we do check

* CPUID 0x40000000
* 8000_001F[EAX] for SME
* 8000_001F[EBX][5:0] for the encryption bits.

So how about we generate the following CPUID picture for the guest:

CPUID_Fn8000001F_EAX = ...10b

That is, SME bit is cleared, SEV is set. This will mean for the guest
kernel that SEV is enabled and you can avoid yourself the 0x40000000
leaf check and the additional KVM feature bit glue.

10b configuration will be invalid for baremetal as - I'm assuming - you
can't have SEV=1b with SME=0b. It will be a virt-only configuration and
this way you can even avoid the hypervisor-specific detection but do
that for all.

Hmmm?

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

Powered by blists - more mailing lists