From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400e:c05::22f; helo=mail-pg0-x22f.google.com; envelope-from=df7729@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3BEFF21EA15B6 for ; Thu, 5 Oct 2017 17:24:30 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id s2so924556pge.10 for ; Thu, 05 Oct 2017 17:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JA8ZssuAAQlTU8egsi398PfnPgatbIs42XUYh0QS2Do=; b=p7vK2KuQXB0rFh5U+m2PW7J+cvwbDe1zp/5+ut0HS3OOZ3va1ujspBQ/YRAAjaUndo m8Kd4YbABWTt/87mt6uRGLZCaXaJVeQvAZweMafOkbQbhJLgQ3NAeCGpcgCEDP/DBK+G hjcvm9z28e4LMji9z4lirFbWsDB3PrW1Z9rU/5s/JjgwGXDiYwL1VKcKGdnIQDThxqgb cFCP99Ioty77soQFLgbvP5uG+6l02BWaYYHgfG5eLQwckZtN3AfgdlADRHJTHxXdEnjh b1ewIf0xmQFw8dGL7z7ZQsPL4tZrJIk2B7T3XZV6bYrcoGjS11jPpP37GrMXrdlj0eiv LJXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JA8ZssuAAQlTU8egsi398PfnPgatbIs42XUYh0QS2Do=; b=gdctbGrilBQhLzr3tkuATa6aU0ZiD0EpswgxW39r60yiajQcN+WU4UTBkmgDN3YqcD vDpDqfkAqX1Il9FsgRq4JJsSpZLM+FgNmCxtyu6GlwoH+83yCKjTnIlhrhhAPCtJpSpM NJTnJd60hH0O83a0eW8KAL0sSj/eXHdhj09Y4XkH7F7d0/rg193mmj6hZvT7x+bvgYSo 7fId5I2cMaWDlLpIvZuB3yzd3jgoltOzbK9/mghdAzMoWQmZVAR06fuiuPX3/zM+vFcC a8XvEugir5IdMfctqMT8BQLRgUzJ3zQYNSZTnOemMmsu7DLQTxP0lzcdUDBE9SSlqhV7 QCQg== X-Gm-Message-State: AMCzsaWmr5oEh3U9fPJrU5keJLUea1kDU01GgkMEnR0XAbgoMlpJ0acF 5wtbREqIlEj3qW6sIHfwPIY1hefjCaQBOBHLUeE= X-Google-Smtp-Source: AOwi7QB2dt61AZQ54y7o1uM0997TuhghMNto/HyNNoMKV3XnbvvYKTl0xhCXX2QQMTXv4/cIrY7Bst7OhjED3tevWek= X-Received: by 10.84.192.37 with SMTP id b34mr331901pld.279.1507249672811; Thu, 05 Oct 2017 17:27:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.189.69 with HTTP; Thu, 5 Oct 2017 17:27:52 -0700 (PDT) In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E13A935@SHSMSX104.ccr.corp.intel.com> References: <20170908021116.6ksnrkapj3dvuder@localhost> <4A89E2EF3DFEDB4C8BFDE51014F606A14E13A935@SHSMSX104.ccr.corp.intel.com> From: "David F." Date: Thu, 5 Oct 2017 17:27:52 -0700 Message-ID: To: "Gao, Liming" Cc: Gary Lin , "edk2-devel@lists.01.org" Subject: Re: StartImage with Secure Boot on Self-Signed App X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 00:24:30 -0000 Content-Type: text/plain; charset="UTF-8" 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 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 >>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. 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 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