From: Takahiro Akashi <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/1] efi_loader: correct parameter size in efi_allocate_pool
Date: Wed, 20 Mar 2019 09:22:44 +0900 [thread overview]
Message-ID: <20190320002243.GI9937@linaro.org> (raw)
In-Reply-To: <e235427f-154e-b114-f0fd-74e56028550e@gmx.de>
On Tue, Mar 19, 2019 at 07:59:37AM +0100, Heinrich Schuchardt wrote:
> On 3/19/19 1:19 AM, Takahiro Akashi wrote:
> > On Mon, Mar 18, 2019 at 08:32:23PM +0100, Heinrich Schuchardt wrote:
> >> efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of
> >> the assigned memory. If we pass the address of a pointer here, an illegal
> >> memory access occurs on 32bit systems.
> >>
> >> Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
> >> for sandbox")
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> ---
> >> lib/efi_loader/efi_memory.c | 5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> >> index ebd2b36c03..55622d2fb4 100644
> >> --- a/lib/efi_loader/efi_memory.c
> >> +++ b/lib/efi_loader/efi_memory.c
> >> @@ -440,6 +440,7 @@ efi_status_t efi_free_pages(uint64_t memory, efi_uintn_t pages)
> >> efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t size, void **buffer)
> >> {
> >> efi_status_t r;
> >> + u64 addr;
> >> struct efi_pool_allocation *alloc;
> >> u64 num_pages = efi_size_in_pages(size +
> >> sizeof(struct efi_pool_allocation));
> >> @@ -453,9 +454,9 @@ efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t size, void **buffer)
> >> }
> >>
> >> r = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES, pool_type, num_pages,
> >> - (uint64_t *)&alloc);
> >
> > I wonder why efi_allocate_pages() doesn't expect (void **) for the fourth
> > argument.
>
> efi_allocate_pages implements the AllocatePages() boot time service. The
> UEFI spec mandates that the parameter is of type EFI_PHYSICAL_ADDRESS *
> i.e. u64 *.
But allocate_pool() takes "void **" for the third argument. Why?
> > If this is because the type of the argument is a pointer to "physical address,"
> >
> >> -
> >> + &addr);
> >> if (r == EFI_SUCCESS) {
> >> + alloc = (struct efi_pool_allocation *)(uintptr_t)addr;
> >
> > we should use map_sysmem() here.
>
> This would create a bug on the sandbox.
>
> map_sysmem() converts an address from the sandbox virtual address space
> to the address space that can be used by EFI binaries.
>
> AllocatePool() and AllocatePages() both refer to the same address space.
>
> Cf. commit 49759743bf09 ("efi_loader: eliminate sandbox addresses")
I don't know the case of sandbox, but What I have in mind is
LPAE, that is, the system have >32-bit physical address space,
but cpu can only access it via 32-bit pointer.
Thanks,
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> >
> > Thanks,
> > -Takahiro Akashi
> >
> >> alloc->num_pages = num_pages;
> >> *buffer = alloc->data;
> >> }
> >> --
> >> 2.20.1
> >>
> >
>
next prev parent reply other threads:[~2019-03-20 0:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-18 19:32 [U-Boot] [PATCH 1/1] efi_loader: correct parameter size in efi_allocate_pool Heinrich Schuchardt
2019-03-19 0:19 ` Takahiro Akashi
2019-03-19 6:59 ` Heinrich Schuchardt
2019-03-20 0:22 ` Takahiro Akashi [this message]
2019-03-20 6:50 ` Heinrich Schuchardt
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=20190320002243.GI9937@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.de \
/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