All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>,
	linux-efi <linux-efi@vger.kernel.org>,
	platform-driver-x86@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	"# 3.4.x" <stable@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>
Subject: Re: [PATCH v2] x86/sme: Explicitly map new EFI memmap table as encrypted
Date: Fri, 3 Dec 2021 10:22:06 -0600	[thread overview]
Message-ID: <6d6b4982-ce69-4fd4-1bb8-5c35b360a95f@amd.com> (raw)
In-Reply-To: <CAMj1kXHKxObuebZJMWQQwg014rYzvoBgWPZxfCYakuf+GSoqhg@mail.gmail.com>

On 12/3/21 4:30 AM, Ard Biesheuvel wrote:
> On Wed, 1 Dec 2021 at 15:06, Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> On 10/27/21 12:04 PM, Tom Lendacky wrote:
>>>
>>>
>>> On 10/27/21 11:59 AM, Ard Biesheuvel wrote:
>>>> On Wed, 27 Oct 2021 at 18:56, Borislav Petkov <bp@alien8.de> wrote:
>>>>>
>>>>> On Wed, Oct 27, 2021 at 05:14:35PM +0200, Ard Biesheuvel wrote:
>>>>>> I could take it, but since it will ultimately go through -tip anyway,
>>>>>> perhaps better if they just take it directly? (This will change after
>>>>>> the next -rc1 though)
>>>>>>
>>>>>> Boris?
>>>>>
>>>>> Yeah, I'm being told this is not urgent enough to rush in now so you
>>>>> could queue it into your fixes branch for 5.16 once -rc1 is out and send
>>>>> it to Linus then. The stable tag is just so it gets backported to the
>>>>> respective trees.
>>>>>
>>>>> But if you prefer I should take it, then I can queue it after -rc1.
>>>>> It'll boil down to the same thing though.
>>>>>
>>>>
>>>> No, in that case, I can take it myself.
>>>>
>>>> Tom, does that work for you?
>>>
>>> Yup, that works for me. Thanks guys!
>>
>> I don't see this in any tree yet, so just a gentle reminder in case it
>> dropped off the radar.
>>
> 
> Apologies for the delay, I've pushed this out to -next now.
> 
> Before I send it to Linus, can you please confirm (for my peace of
> mind) how this only affects systems that have memory encryption
> available and enabled in the first place?

Certainly.

An early_memremap() call uses the FIXMAP_PAGE_NORMAL protection value for 
performing the mapping. Prior to performing the actual mapping though, a 
call to early_memremap_pgprot_adjust() is made to possibly alter the 
protection value, but only if memory encryption is active.

Changing the call to early_memremap_prot() and providing 
pgprot_encrypted(FIXMAP_PAGE_NORMAL) as the protection value results in an 
equivalent call to early_memremap() when memory encryption is not active. 
This is because the pgprot_encrypted() is, in effect, a NOP when memory 
encryption is not active.

So when memory encryption is not available or active, the result of an 
early_memremap_prot() call with a protection value of 
pgprot_encrypted(FIXMAP_PAGE_NORMAL) is equivalent to an early_memremap() 
call.

Let me know if that answers your question.

Thanks,
Tom

> 

  reply	other threads:[~2021-12-03 16:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-22 17:02 [PATCH v2] x86/sme: Explicitly map new EFI memmap table as encrypted Tom Lendacky
2021-10-27 15:11 ` Tom Lendacky
2021-10-27 15:14   ` Ard Biesheuvel
2021-10-27 16:56     ` Borislav Petkov
2021-10-27 16:59       ` Ard Biesheuvel
2021-10-27 17:04         ` Tom Lendacky
2021-12-01 14:05           ` Tom Lendacky
2021-12-03 10:30             ` Ard Biesheuvel
2021-12-03 16:22               ` Tom Lendacky [this message]
2021-12-03 18:13                 ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d6b4982-ce69-4fd4-1bb8-5c35b360a95f@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=andy@infradead.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dvhart@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.