Re: [PATCH 2/2] efi/esrt: mark ESRT memory region as nomap

[Ard Biesheuvel]

Hi Tyler,

On 23 February 2018 at 19:42, Tyler Baicar <tbaicar@xxxxxxxxxxxxxx> wrote:
> The ESRT memory region is being exposed as System RAM in /proc/iomem
> which is wrong because it cannot be overwritten. This memory is needed
> for kexec kernels in order to properly initialize ESRT, so if it is
> overwritten it will cause ESRT failures in the kexec kernel. Mark this
> region as nomap so that it is not overwritten.
>

This is not the right fix. We should only mark regions NOMAP if it is
uncertain whether the firmware may have a mapping of the same region
with mismatched attributes. NOMAP regions punch holes in the linear
region, increasing its TLB footprint significantly, so we should avoid
them if we can.

This same issue has come up in relation to mapping ACPI tables after
kexec. This should simply be a matter of ensuring that all
memblock_reserve()d region appear as such in /proc/iomem rather than
as 'System RAM'

> Signed-off-by: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
> Tested-by: Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx>
> ---
>  drivers/firmware/efi/esrt.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
> index 504f3c3..f5f79c7 100644
> --- a/drivers/firmware/efi/esrt.c
> +++ b/drivers/firmware/efi/esrt.c
> @@ -335,6 +335,14 @@ void __init efi_esrt_init(void)
>         pr_info("Reserving ESRT space from %pa to %pa.\n", &esrt_data, &end);
>         efi_mem_reserve(esrt_data, esrt_data_size);
>
> +       /*
> +        * Mark the ESRT memory region as nomap to avoid it being exposed as
> +        * System RAM in /proc/iomem. Otherwise this block can be overwritten
> +        * which will then cause failures in kexec'd kernels since the ESRT
> +        * information is no longer there.
> +        */
> +       memblock_mark_nomap(esrt_data, esrt_data_size);
> +
>         pr_debug("esrt-init: loaded.\n");
>  err_memunmap:
>         early_memunmap(va, size);
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project.
>