Reserving memory using efi_mem_reserve() calls into the x86 efi_arch_mem_reserve() function. This function will insert a new EFI memory descriptor into the EFI memory map representing the area of memory to be reserved and marking it as EFI runtime memory.
As part of adding this new entry, a new EFI memory map is allocated and mapped. The mapping is where a problem can occur. This new EFI memory map is mapped using early_memremap(). If the allocated memory comes from an area that is marked as EFI_BOOT_SERVICES_DATA memory in the current EFI memory map, then it will be mapped unencrypted (see memremap_is_efi_data() and the call to efi_mem_type()).
However, during replacement of the old EFI memory map with the new EFI memory map, efi_mem_type() is disabled, resulting in the new EFI memory map always being mapped encrypted in efi.memmap. This will cause a kernel crash later in the boot.
Since it is known that the new EFI memory map will always be mapped encrypted when efi_memmap_install() is called, explicitly map the new EFI memory map as encrypted (using early_memremap_prot()) when inserting the new memory map entry.
Cc: stable@vger.kernel.org # 4.14.x Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear") Acked-by: Ard Biesheuvel ardb@kernel.org Signed-off-by: Tom Lendacky thomas.lendacky@amd.com
--- Changes for v2: - Update/expand commit message to (hopefully) make it easier to read and understand - Add a comment around the use of the early_memremap_prot() call --- arch/x86/platform/efi/quirks.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c index b15ebfe40a73..14f8f20d727a 100644 --- a/arch/x86/platform/efi/quirks.c +++ b/arch/x86/platform/efi/quirks.c @@ -277,7 +277,19 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size) return; }
- new = early_memremap(data.phys_map, data.size); + /* + * When SME is active, early_memremap() can map the memory unencrypted + * if the allocation came from EFI_BOOT_SERVICES_DATA (see + * memremap_is_efi_data() and the call to efi_mem_type()). However, + * when efi_memmap_install() is called to replace the memory map, + * efi_mem_type() is "disabled" and so the memory will always be mapped + * encrypted. To avoid this possible mismatch between the mappings, + * always map the newly allocated memmap memory as encrypted. + * + * When SME is not active, this behaves just like early_memremap(). + */ + new = early_memremap_prot(data.phys_map, data.size, + pgprot_val(pgprot_encrypted(FIXMAP_PAGE_NORMAL))); if (!new) { pr_err("Failed to map new boot services memmap\n"); return;
On 10/22/21 12:02 PM, Tom Lendacky wrote:
Reserving memory using efi_mem_reserve() calls into the x86 efi_arch_mem_reserve() function. This function will insert a new EFI memory descriptor into the EFI memory map representing the area of memory to be reserved and marking it as EFI runtime memory.
As part of adding this new entry, a new EFI memory map is allocated and mapped. The mapping is where a problem can occur. This new EFI memory map is mapped using early_memremap(). If the allocated memory comes from an area that is marked as EFI_BOOT_SERVICES_DATA memory in the current EFI memory map, then it will be mapped unencrypted (see memremap_is_efi_data() and the call to efi_mem_type()).
However, during replacement of the old EFI memory map with the new EFI memory map, efi_mem_type() is disabled, resulting in the new EFI memory map always being mapped encrypted in efi.memmap. This will cause a kernel crash later in the boot.
Since it is known that the new EFI memory map will always be mapped encrypted when efi_memmap_install() is called, explicitly map the new EFI memory map as encrypted (using early_memremap_prot()) when inserting the new memory map entry.
Cc: stable@vger.kernel.org # 4.14.x Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear") Acked-by: Ard Biesheuvel ardb@kernel.org Signed-off-by: Tom Lendacky thomas.lendacky@amd.com
Ard, are you going to take this through the EFI tree or does it need to go through another tree?
Thanks, Tom
Changes for v2:
- Update/expand commit message to (hopefully) make it easier to read and understand
- Add a comment around the use of the early_memremap_prot() call
arch/x86/platform/efi/quirks.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c index b15ebfe40a73..14f8f20d727a 100644 --- a/arch/x86/platform/efi/quirks.c +++ b/arch/x86/platform/efi/quirks.c @@ -277,7 +277,19 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size) return; }
- new = early_memremap(data.phys_map, data.size);
- /*
* When SME is active, early_memremap() can map the memory unencrypted* if the allocation came from EFI_BOOT_SERVICES_DATA (see* memremap_is_efi_data() and the call to efi_mem_type()). However,* when efi_memmap_install() is called to replace the memory map,* efi_mem_type() is "disabled" and so the memory will always be mapped* encrypted. To avoid this possible mismatch between the mappings,* always map the newly allocated memmap memory as encrypted.** When SME is not active, this behaves just like early_memremap().*/- new = early_memremap_prot(data.phys_map, data.size,
pgprot_val(pgprot_encrypted(FIXMAP_PAGE_NORMAL)));
On Wed, 27 Oct 2021 at 17:11, Tom Lendacky thomas.lendacky@amd.com wrote:
On 10/22/21 12:02 PM, Tom Lendacky wrote:
Reserving memory using efi_mem_reserve() calls into the x86 efi_arch_mem_reserve() function. This function will insert a new EFI memory descriptor into the EFI memory map representing the area of memory to be reserved and marking it as EFI runtime memory.
As part of adding this new entry, a new EFI memory map is allocated and mapped. The mapping is where a problem can occur. This new EFI memory map is mapped using early_memremap(). If the allocated memory comes from an area that is marked as EFI_BOOT_SERVICES_DATA memory in the current EFI memory map, then it will be mapped unencrypted (see memremap_is_efi_data() and the call to efi_mem_type()).
However, during replacement of the old EFI memory map with the new EFI memory map, efi_mem_type() is disabled, resulting in the new EFI memory map always being mapped encrypted in efi.memmap. This will cause a kernel crash later in the boot.
Since it is known that the new EFI memory map will always be mapped encrypted when efi_memmap_install() is called, explicitly map the new EFI memory map as encrypted (using early_memremap_prot()) when inserting the new memory map entry.
Cc: stable@vger.kernel.org # 4.14.x Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear") Acked-by: Ard Biesheuvel ardb@kernel.org Signed-off-by: Tom Lendacky thomas.lendacky@amd.com
Ard, are you going to take this through the EFI tree or does it need to go through another tree?
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?
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.
Thx.
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?
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!
Tom
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.
Thanks, Tom
Tom
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?
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
On Fri, 3 Dec 2021 at 17:22, Tom Lendacky thomas.lendacky@amd.com wrote:
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.
It does, thanks.
linux-stable-mirror@lists.linaro.org
-
Ard Biesheuvel -
Borislav Petkov -
Tom Lendacky