From: "David F." <df7729@gmail.com>
To: "Gao, Liming" <liming.gao@intel.com>
Cc: Gary Lin <glin@suse.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: StartImage with Secure Boot on Self-Signed App
Date: Thu, 5 Oct 2017 17:27:52 -0700 [thread overview]
Message-ID: <CAGRSmLtoxfO9s+m5u98rF02cKOHLd677mibQ=0z=4SK7XKg_UA@mail.gmail.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E13A935@SHSMSX104.ccr.corp.intel.com>
Is there a protocol with a simple to use function to check if the
certificate of a PE binary image in memory is valid based on the
machine keys installed?
On Tue, Sep 12, 2017 at 12:32 AM, Gao, Liming <liming.gao@intel.com> wrote:
> You can load and start the image based on PeCoffLib APIs in BasePeCoffLib instead of LoadImage() and StartImage() service.
>
>>-----Original Message-----
>>From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>>David F.
>>Sent: Friday, September 08, 2017 11:34 PM
>>To: Gary Lin <glin@suse.com>
>>Cc: edk2-devel@lists.01.org
>>Subject: Re: [edk2] Fwd: StartImage with Secure Boot on Self-Signed App
>>
>>Actually, even a StartImageEx() would be fine with parameter to allow options.
>>
>>On Thu, Sep 7, 2017 at 7:51 PM, David F. <df7729@gmail.com> wrote:
>>> Thanks, looking forward, can the people on the board dealing with the
>>> specification please consider revising EFI_LOADED_IMAGE_PROTOCOL to
>>> include a new "Flags" field and one of the bits allows StartImage to
>>> start the image even if LoadImage reported a EFI_SECURITY_VIOLATION
>>> was reported. defined bit name could be #define
>>> EFI_LOADED_IMAGE_PROTOCOL_FLAG_SELF_VALIDATED
>>0x0000000000000001ULL.
>>> This provides a clean interface for applications without having to
>>> hack StartImage() with a potential conflict with future changes to the
>>> internal firmware.
>>>
>>>
>>> On Thu, Sep 7, 2017 at 7:11 PM, Gary Lin <glin@suse.com> wrote:
>>>> On Thu, Sep 07, 2017 at 01:00:03PM -0700, David F. wrote:
>>>>> Hello,
>>>>>
>>>>> What is the proper way to allow running another app that is verified
>>>>> with a self-signed certificate?
>>>>>
>>>>> Example, App1 is signed with one that allows secure boot booting (in
>>>>> firmware) and has a public key embedded in the signed code, App2 is
>>>>> verified by App1 and so is allowed to run, but because the key is not
>>>>> in secure boot firmware, StartImage will not run it (although
>>>>> LoadImage did what it needed to do and already reported the security
>>>>> violation potential). Do we have to roll our own StartImage? or is
>>>>> something already in place? I can't rely on changing an internal
>>>>> private structure field to allow StartImage to work since each
>>>>> firmware platform may change the way it all works, looking for the
>>>>> proper method as designed.
>>>>>
>>>> The major linux distros are using shim(*) to verify the bootloaders and
>>>> kernels signed by ourselves, and shim implements its own StartImage.
>>>>
>>>> If your application is going to be deployed to the newer UEFI, instead
>>>> of using the built-in openssl, you can try EFI_PKCS7_VERIFY_PROTOCOL to
>>>> verify the UEFI images. It will make your application much slimmer and
>>>> easier to maintain.
>>>>
>>>> Cheers,
>>>>
>>>> Gary Lin
>>>>
>>>> (*) https://github.com/rhboot/shim
>>_______________________________________________
>>edk2-devel mailing list
>>edk2-devel@lists.01.org
>>https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2017-10-06 0:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGRSmLuQ3prdU1D_PDfzZpWHdnMjQfzKzzU8EpvOMX4BWvcxQA@mail.gmail.com>
2017-09-07 20:00 ` StartImage with Secure Boot on Self-Signed App David F.
2017-09-08 2:11 ` Gary Lin
2017-09-08 2:51 ` David F.
2017-09-08 15:33 ` David F.
2017-09-12 7:32 ` Gao, Liming
2017-10-06 0:27 ` David F. [this message]
2017-10-09 6:56 ` Gao, Liming
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='CAGRSmLtoxfO9s+m5u98rF02cKOHLd677mibQ=0z=4SK7XKg_UA@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