linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mingo@kernel.org (Ingo Molnar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] efi: fdt: avoid FDT manipulation after ExitBootServices()
Date: Wed, 1 Feb 2017 21:16:44 +0100	[thread overview]
Message-ID: <20170201201644.GA20208@gmail.com> (raw)
In-Reply-To: <CAKv+Gu9-Ug8oUv56oyzb7VxgRac2iv1xQcZ+jU-0NdcQr5226A@mail.gmail.com>


* Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> On 1 February 2017 at 19:03, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> >> Some AArch64 UEFI implementations disable the MMU in ExitBootServices(),
> >> after which unaligned accesses to RAM are no longer supported.
> >>
> >> Commit abfb7b686a3e ("efi/libstub/arm*: Pass latest memory map to the
> >> kernel") fixed an issue in the memory map handling of the stub FDT code,
> >> but inadvertently created an issue with such firmwares, by moving some
> >> of the FDT manipulation to after the invocation of ExitBootServices().
> >> Given that the stub's libfdt implementation uses the ordinary, accelerated
> >> string functions, which rely on hardware handling of unaligned accesses,
> >> manipulating the FDT with the MMU off may result in alignment faults.
> >>
> >> So fix the situation by moving the update_fdt_memmap() call into the
> >> callback function invoked by efi_exit_boot_services() right before it
> >> calls the ExitBootServices() UEFI service (which is arguably a better
> >> place for it anyway)
> >>
> >> Note that disabling the MMU in ExitBootServices() is not compliant with
> >> the UEFI spec, and carries great risk due to the fact that switching from
> >> cached to uncached memory accesses halfway through compiler generated code
> >> (i.e., involving a stack) can never be done in a way that is architecturally
> >> safe.
> >>
> >> Cc: <stable@vger.kernel.org>
> >> Fixes: abfb7b686a3e ("efi/libstub/arm*: Pass latest memory map to the kernel")
> >> Tested-by: Riku Voipio <riku.voipio@linaro.org>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> ---
> >>  drivers/firmware/efi/libstub/fdt.c | 14 +++-----------
> >>  1 file changed, 3 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
> >> index 921dfa047202..260c4b4b492e 100644
> >> --- a/drivers/firmware/efi/libstub/fdt.c
> >> +++ b/drivers/firmware/efi/libstub/fdt.c
> >> @@ -187,6 +187,7 @@ static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map)
> >>  struct exit_boot_struct {
> >>       efi_memory_desc_t *runtime_map;
> >>       int *runtime_entry_count;
> >> +     void *new_fdt_addr;
> >>  };
> >>
> >>  static efi_status_t exit_boot_func(efi_system_table_t *sys_table_arg,
> >> @@ -202,7 +203,7 @@ static efi_status_t exit_boot_func(efi_system_table_t *sys_table_arg,
> >>       efi_get_virtmap(*map->map, *map->map_size, *map->desc_size,
> >>                       p->runtime_map, p->runtime_entry_count);
> >>
> >> -     return EFI_SUCCESS;
> >> +     return update_fdt_memmap(p->new_fdt_addr, map);
> >>  }
> >>
> >>  /*
> >> @@ -300,22 +301,13 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
> >>
> >>       priv.runtime_map = runtime_map;
> >>       priv.runtime_entry_count = &runtime_entry_count;
> >> +     priv.new_fdt_addr = (void *)*new_fdt_addr;
> >
> > Nit: could the type cast by dropped?
> 
> new_fdt_addr is a pointer to unsigned long, so we can't drop the cast
> here without introducing it somewhere else.

Fair enough, I missed the dereference of new_fdt_addr.

Thanks,

	Ingo

  reply	other threads:[~2017-02-01 20:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 17:45 [GIT PULL] EFI urgent fix for v4.10 Ard Biesheuvel
2017-02-01 17:45 ` [PATCH] efi: fdt: avoid FDT manipulation after ExitBootServices() Ard Biesheuvel
2017-02-01 17:49   ` Leif Lindholm
2017-02-01 19:03   ` Ingo Molnar
2017-02-01 19:28     ` Ard Biesheuvel
2017-02-01 20:16       ` Ingo Molnar [this message]
2017-02-01 21:08   ` Jeffrey Hugo
2017-02-01 22:59     ` Jeffrey Hugo
2017-02-02 16:14       ` Ard Biesheuvel
  -- strict thread matches above, loose matches on Subject: below --
2017-02-01 13:11 Ard Biesheuvel
2017-02-01 13:39 ` Leif Lindholm
2017-02-01 13:41   ` Ard Biesheuvel
2017-02-01 14:08 ` Mark Rutland
2017-02-01 14:46 ` Riku Voipio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170201201644.GA20208@gmail.com \
    --to=mingo@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).