| Message ID | 1445848860-9547-1-git-send-email-ard.biesheuvel@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Mon, Oct 26, 2015 at 9:41 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > In order to prevent kernel drivers from attaching to MMIO regions > that are owned by the firmware, register them as iomem resources. > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Is this related to the flash memory discussion so that NOR flash will be part of what is considered "I/O memory" and flash protection achieved this way? Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 27 October 2015 at 21:08, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Oct 26, 2015 at 9:41 AM, Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: > >> In order to prevent kernel drivers from attaching to MMIO regions >> that are owned by the firmware, register them as iomem resources. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > Is this related to the flash memory discussion so that NOR flash > will be part of what is considered "I/O memory" Yes > and flash > protection achieved this way? > ... and no, not entirely. Note that this is not about 'protecting' the flash in a security sense. It is simply to reserve the resources that should be considered occupied by the UEFI firmware drivers. This may be NOR flash, but it may just as well be the RTC or potentially a syscon register block to do reset and/or poweroff. My QEMU mach-virt /proc/iomem looks like this with the patch applied: 04000000-07ffffff : UEFI Runtime MMIO 09000000-09000fff : /pl011@9000000 09000000-09000fff : /pl011@9000000 09010000-0901ffff : UEFI Runtime MMIO 40000000-7fffffff : System RAM 40080000-408a27d3 : Kernel code 40970000-40adffff : Kernel data where the first UEFI mmio region is the second bank of NOR flash (the first one holds the firmware image itself, so that is not claimed since the variable store driver never accesses it) and the second UEFI mmio region is the PL031 RTC. -- Ard. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 27 October 2015 at 13:31, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 27 October 2015 at 21:08, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Mon, Oct 26, 2015 at 9:41 AM, Ard Biesheuvel >> <ard.biesheuvel@linaro.org> wrote: >> >>> In order to prevent kernel drivers from attaching to MMIO regions >>> that are owned by the firmware, register them as iomem resources. >>> >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> >> Is this related to the flash memory discussion so that NOR flash >> will be part of what is considered "I/O memory" > > Yes > >> and flash >> protection achieved this way? >> > > ... and no, not entirely. Note that this is not about 'protecting' the > flash in a security sense. It is simply to reserve the resources that > should be considered occupied by the UEFI firmware drivers. This may > be NOR flash, but it may just as well be the RTC or potentially a > syscon register block to do reset and/or poweroff. > > My QEMU mach-virt /proc/iomem looks like this with the patch applied: > > 04000000-07ffffff : UEFI Runtime MMIO > 09000000-09000fff : /pl011@9000000 > 09000000-09000fff : /pl011@9000000 > 09010000-0901ffff : UEFI Runtime MMIO > 40000000-7fffffff : System RAM > 40080000-408a27d3 : Kernel code > 40970000-40adffff : Kernel data > > where the first UEFI mmio region is the second bank of NOR flash (the > first one holds the firmware image itself, so that is not claimed > since the variable store driver never accesses it) and the second UEFI > mmio region is the PL031 RTC. > Ping? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c index a48d1f477b2e..f2c6763d6c37 100644 --- a/arch/arm64/kernel/efi.c +++ b/arch/arm64/kernel/efi.c @@ -229,6 +229,22 @@ void __init efi_init(void) early_memunmap(memmap.map, params.mmap_size); } +static void __init efi_reserve_iomem_resource(efi_memory_desc_t *md) +{ + struct resource *res; + + res = kzalloc(sizeof(*res), GFP_KERNEL); + if (WARN_ON_ONCE(!res)) + return; + + res->start = md->phys_addr & PAGE_MASK; + res->end = PAGE_ALIGN(md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT)) - 1; + res->name = "UEFI Runtime MMIO"; + res->flags = IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_EXCLUSIVE; + + request_resource(&iomem_resource, res); +} + static bool __init efi_virtmap_init(void) { efi_memory_desc_t *md; @@ -239,6 +255,8 @@ static bool __init efi_virtmap_init(void) if (!(md->attribute & EFI_MEMORY_RUNTIME)) continue; + if (md->type == EFI_MEMORY_MAPPED_IO) + efi_reserve_iomem_resource(md); if (md->virt_addr == 0) return false;
In order to prevent kernel drivers from attaching to MMIO regions that are owned by the firmware, register them as iomem resources. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> --- arch/arm64/kernel/efi.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) -- 2.1.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel