[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170316150957.dos6wp3pmhos4hkj@pd.tnic>
Date: Thu, 16 Mar 2017 16:09:57 +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 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.
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
be reused so that
* SME on baremetal
* SEV on guest
use the same logic?
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.
--
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