public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Rafael Machado <rafaelrodrigues.machado@gmail.com>
To: "Ni, Ruiyu" <ruiyu.ni@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: UEFI App embedded on another uefi app
Date: Wed, 20 Dec 2017 17:31:42 +0000	[thread overview]
Message-ID: <CACgnt7-UjLZDzROBbyvchYtgz_bU-AshW7jpt2NeYB7k6U+WxA@mail.gmail.com> (raw)
In-Reply-To: <82e7b859-9184-bb1c-828f-ecde7772231d@Intel.com>

Hi Ruiyu

Thanks for the answer.
The case is similar. The only difference is that we are not allowed to use
some external code besides the UDK references and modules.

This is why we're trying to find a way to embed a binary on another one.

I did some tests here but I have a question.

Is it possible to create a PCD that points to an embedded binary?
For example. At the MdeModulePkg/Application/HelloWorld/HelloWorld.c we
have some example of how to access a string that is declared at the .dec
and and filled at the .uni:

Print ((CHAR16*)PcdGetPtr (PcdHelloWorldPrintString));

I was able to compile this application adding the Logo.bmp to the
HelloWorld.inf file, just to check how this would work.

So the question is. How could I create a PCD that points to a binary that
is added to a .efi?

Based on the code I believe the only what to do that is creating a .fdf and
setting the PCD to point to the binary, on the same way it's done with the:

MdeModulePkg\Logo\Logo.inf
CorebootPayloadPkg\CorebootPayloadPkg.fdf

The problem is that at our case, we need to have a single .efi that has an
embedded binary.

Any idea on how to do that? (Not sure if this is to intrusive for the PE
format. Still learning this)

Thanks and Regards
Rafael R. Machado

Em seg, 18 de dez de 2017 às 03:13, Ni, Ruiyu <ruiyu.ni@intel.com> escreveu:

> On 12/15/2017 7:45 PM, Rafael Machado wrote:
> > Hi Everyone.
> >
> > I have a limited space problem at a project.
> > To solve this we had an idea, but would like to ask to you before
> expending
> > time on trying to do it, due to some tight schedule. (We know that the
> best
> > is to try before ask, but we do not have time for that now. Sorry for
> that.)
> >
> > The idea is to create a kind of DecompressorApp.efi, that
> > uses  EFI_DECOMPRESS_PROTOCOL
> >
> > During the compilation process of the application the tasks would be:
> >
> > - Compile App.efi
> > - Compress App.efi, generating the App.efi.compressed (using
> > tianoCompress.exe)
> > - Compile the Decompressor.efi app (with the App.efi.compressed embedded)
> >         - The idea to do this is to add the compressed app as a Binary at
> > the DecompressorApp.efi .inf file using the [Binaries] tag
> >
> >
> > So during the entrypoint of the Decompressor.efi app, the application
> will
> > need to copy the compressed part of the app (App.efi.compressed), to a
> > buffer, and after that this buffer will be decompressed using the
> > EFI_DECOMPRESS_PROTOCOL. Finally the execution control is passed to the
> > App.efi decompressed (not sure how to do that yet).
> >
> > So the questions we have for know are:
> >
> > - How to detect the App.efi.compressed insyde the loaded app, so we can
> > have an address to decompress
> Is your usage case similar to the upx?
>
> If the App.efi is compressed and embedded as binary in the application,
> the application itself should know that the binary should be
> decompressed and executed.
>
>
> > - How to pass the application executions control to another app, that is
> in
> > a buffer (not sure if this can be done with the EFI Boot Service
> > LoadImage(), since this buffer does not have a valid file device path)
> Yes you could use LoadImage(). The API also accepts a PE buffer to load.
> Then you could use StartImage() to execute the PE buffer.
> Make sure you use the correct entrypoint prototype for the PE buffer.
> typedef
> EFI_STATUS
> (EFIAPI *EFI_IMAGE_ENTRY_POINT)(
>    IN  EFI_HANDLE                   ImageHandle,
>    IN  EFI_SYSTEM_TABLE             *SystemTable
>    );
>
> >
> > Could you help us on understanding if this is possible?
> >
> > Thanks and Regards
> > Rafael R. Machado
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> >
>
>
> --
> Thanks,
> Ray
>


  reply	other threads:[~2017-12-20 17:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-15 11:45 UEFI App embedded on another uefi app Rafael Machado
2017-12-18  5:13 ` Ni, Ruiyu
2017-12-20 17:31   ` Rafael Machado [this message]
2017-12-21  3:15     ` Ni, Ruiyu

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-list 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=CACgnt7-UjLZDzROBbyvchYtgz_bU-AshW7jpt2NeYB7k6U+WxA@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /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