Skip to contentSkip to conversation

arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

PATCH New Ard Biesheuvel 2 participants 5 messages Sep 14, 2017 – Sep 22, 2017

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

The UEFI memory map is a bit vague about how to interpret the EFI_MEMORY_XP attribute when it is combined with EFI_MEMORY_RP and/or EFI_MEMORY_WP, which have retroactively been redefined as cacheability attributes rather than permission attributes.

So let's ignore EFI_MEMORY_XP if _RP and/or _WP are also set. In this case, it is likely that they are being used to describe the capability of the region (i.e., whether it has the controls to reconfigure it as non-executable) rather than the nature of the contents of the region (i.e., whether it contains data that we will never attempt to execute)

Cc Stephen Boyd <[email protected]>
Cc Matt Fleming <[email protected]>
---
 arch/arm64/kernel/efi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm64/kernel/efi.c +3 -1
index 82cd07592519..f85ac58d08a3 100644
@@ -48,7 +48,9 @@ static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)
 		return pgprot_val(PAGE_KERNEL_ROX);
 
 	/* RW- */
-	if (attr & EFI_MEMORY_XP || type != EFI_RUNTIME_SERVICES_CODE)
+	if (((attr & (EFI_MEMORY_RP | EFI_MEMORY_WP | EFI_MEMORY_XP)) ==
+	     EFI_MEMORY_XP) ||
+	    type != EFI_RUNTIME_SERVICES_CODE)
 		return pgprot_val(PAGE_KERNEL);
 
 	/* RWX */
Signature · 1 line
2.11.0
#1 lore raw

PATCH 1/1 arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

Quoted 1 line · Ard Biesheuvel

The UEFI memory map

*spec*

Quoted 36 lines

is a bit vague about how to interpret the
EFI_MEMORY_XP attribute when it is combined with EFI_MEMORY_RP and/or EFI_MEMORY_WP, which have retroactively been redefined as cacheability attributes rather than permission attributes.

So let's ignore EFI_MEMORY_XP if _RP and/or _WP are also set. In this case, it is likely that they are being used to describe the capability of the region (i.e., whether it has the controls to reconfigure it as non-executable) rather than the nature of the contents of the region (i.e., whether it contains data that we will never attempt to execute)

Cc Stephen Boyd <[email protected]>
Cc Matt Fleming <[email protected]>
---
 arch/arm64/kernel/efi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm64/kernel/efi.c +3 -2
index 82cd07592519..f85ac58d08a3 100644
@@ -48,7 +48,9 @@ static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)
                return pgprot_val(PAGE_KERNEL_ROX);
 
        /* RW- */
-       if (attr & EFI_MEMORY_XP || type != EFI_RUNTIME_SERVICES_CODE)
+       if (((attr & (EFI_MEMORY_RP | EFI_MEMORY_WP | EFI_MEMORY_XP)) ==
+            EFI_MEMORY_XP) ||
+           type != EFI_RUNTIME_SERVICES_CODE)
                return pgprot_val(PAGE_KERNEL);
 
        /* RWX */
--

2.11.0

#2 lore raw

PATCH 1/1 arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

In reply to Ard Biesheuvel
Quoted 5 lines · Ard Biesheuvel

The UEFI memory map is a bit vague about how to interpret the EFI_MEMORY_XP attribute when it is combined with EFI_MEMORY_RP and/or EFI_MEMORY_WP, which have retroactively been redefined as cacheability attributes rather than permission attributes.

Quoted 7 lines

So let's ignore EFI_MEMORY_XP if _RP and/or _WP are also set. In this case, it is likely that they are being used to describe the capability of the region (i.e., whether it has the controls to reconfigure it as non-executable) rather than the nature of the contents of the region (i.e., whether it contains data that we will never attempt to execute)

Cc Stephen Boyd <[email protected]>

I will test early next week and provide a tested-by. Thanks.

Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
#3 lore raw

PATCH 1/1 arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

Quoted 12 lines · Stephen Boyd
Quoted 11 lines · Ard Biesheuvel

The UEFI memory map is a bit vague about how to interpret the EFI_MEMORY_XP attribute when it is combined with EFI_MEMORY_RP and/or EFI_MEMORY_WP, which have retroactively been redefined as cacheability attributes rather than permission attributes.

So let's ignore EFI_MEMORY_XP if _RP and/or _WP are also set. In this case, it is likely that they are being used to describe the capability of the region (i.e., whether it has the controls to reconfigure it as non-executable) rather than the nature of the contents of the region (i.e., whether it contains data that we will never attempt to execute)

Quoted 6 lines
Quoted 1 line
Cc Stephen Boyd <[email protected]>

I will test early next week and provide a tested-by. Thanks.

Great, thanks.

#4 lore raw

PATCH 1/1 arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

Quoted 13 lines · Ard Biesheuvel
Quoted 12 lines · Stephen Boyd
Quoted 11 lines · Ard Biesheuvel

The UEFI memory map is a bit vague about how to interpret the EFI_MEMORY_XP attribute when it is combined with EFI_MEMORY_RP and/or EFI_MEMORY_WP, which have retroactively been redefined as cacheability attributes rather than permission attributes.

So let's ignore EFI_MEMORY_XP if _RP and/or _WP are also set. In this case, it is likely that they are being used to describe the capability of the region (i.e., whether it has the controls to reconfigure it as non-executable) rather than the nature of the contents of the region (i.e., whether it contains data that we will never attempt to execute)

Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Cc Stephen Boyd <[email protected]>

I will test early next week and provide a tested-by. Thanks.

Great, thanks.

Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project