[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <24AEA0F0-8BDA-4C96-9AC2-F12A7A06C76D@alien8.de>
Date: Tue, 26 Mar 2019 11:06:13 +0100
From: Boris Petkov <bp@...en8.de>
To: "Lendacky, Thomas" <Thomas.Lendacky@....com>,
"Singh, Brijesh" <brijesh.singh@....com>
CC: lijiang <lijiang@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"dyoung@...hat.com" <dyoung@...hat.com>,
"bhe@...hat.com" <bhe@...hat.com>
Subject: Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when SEV is active
On March 25, 2019 8:59:28 PM GMT+01:00, "Lendacky, Thomas" <Thomas.Lendacky@....com> wrote:
>Maybe what would help is to describe why there is a difference between
>SME
>and SEV in regards to kexec. During a traditional boot under SME, SME
>will
>encrypt the kernel, so the SME kexec kernel also needs to be
>un-encrypted
>in order to replicate a normal SME boot. During a traditional boot
>under
>SEV, the kernel has already been loaded encrypted, so the SEV kexec
>kernel
>needs to be encrypted in order to replicate a normal SEV boot.
Yah, that should be in a comment above that function.
Thx.
--
Sent from a small device: formatting sux and brevity is inevitable.
Powered by blists - more mailing lists