| Message ID | 20170914193153.18520-1-ard.biesheuvel@linaro.org |
|---|---|
| State | Accepted |
| Commit | 1e9de1d2207d67b97bb0b62e38454b663d6542fa |
| Headers | show |
| Series | arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set | expand |
On 14 September 2017 at 12:31, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > The UEFI memory map *spec* > 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 <sboyd@codeaurora.org> > Cc: Matt Fleming <matt@codeblueprint.co.uk> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > --- > arch/arm64/kernel/efi.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c > index 82cd07592519..f85ac58d08a3 100644 > --- a/arch/arm64/kernel/efi.c > +++ b/arch/arm64/kernel/efi.c > @@ -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 > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/14, Ard Biesheuvel wrote: > 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 <sboyd@codeaurora.org> Reported-by: Stephen Boyd <sboyd@codeaurora.org> I will test early next week and provide a tested-by. Thanks. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 15 September 2017 at 11:53, Stephen Boyd <sboyd@codeaurora.org> wrote: > On 09/14, Ard Biesheuvel wrote: >> 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 <sboyd@codeaurora.org> > > Reported-by: Stephen Boyd <sboyd@codeaurora.org> > > I will test early next week and provide a tested-by. Thanks. > Great, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/15, Ard Biesheuvel wrote: > On 15 September 2017 at 11:53, Stephen Boyd <sboyd@codeaurora.org> wrote: > > On 09/14, Ard Biesheuvel wrote: > >> 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 <sboyd@codeaurora.org> > > > > Reported-by: Stephen Boyd <sboyd@codeaurora.org> > > > > I will test early next week and provide a tested-by. Thanks. > > > > Great, thanks. > Tested-by: Stephen Boyd <sboyd@codeaurora.org> -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c index 82cd07592519..f85ac58d08a3 100644 --- a/arch/arm64/kernel/efi.c +++ b/arch/arm64/kernel/efi.c @@ -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 */
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 <sboyd@codeaurora.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> --- arch/arm64/kernel/efi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html