From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 B120D20958BEA for ; Fri, 8 Sep 2017 08:30:59 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 188so5406999pgb.2 for ; Fri, 08 Sep 2017 08:33:52 -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=O4WxfSTe/IDStOFXedommxsGMRNgj42HBJny1JbvopE=; b=iyrV5+Fyn3ZIoXQW8wLC4zEqqFvWF4DCRlqCYE3vGQ80OeyyO+09yVUX+6fk5II8iz ZsDg5qcVFgC+c7EHVz60ZeXO3jQz70i3jLZmVWzmfWvJlGRRD8OcADo1yHvu9fsAb3Vi QCr10vGU8+yuxp9EdWjoBUumnRqygy6dkMppTDeG9Zhg7JTDBbJ/7pLcclO/3eOFwREj HCbt/WgUtbr7B/xeWnc3BiHP8zGfrN27nYEqBGOLA6maMWSawDvWxbNqDBy6H5c70Zx8 5J8WTd+fGTZaTIsknwi759+gje929FE/VIQJuCPoVkRyOmPNtJfB+ESdUfxXt0b6pd2P UrCA== 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=O4WxfSTe/IDStOFXedommxsGMRNgj42HBJny1JbvopE=; b=sPK+sNN10WCPrx+Z/3acmGEaP2wTdb1c/LT/OMKV94ludHZlOk/3NRUVOoD4C0VF+O S8NstmDjRZ4sGocjJKEZmk1bWVga8u2i6AFexisrXVHH6lh/LAdtHv8Idegg5KzyluhE 3CRQKKvv7SrzMPKw+5YBfkeTUTQIPeay3OxyMw+74JPYVX+UvxMW8mznFV9DBX0aGzRs 7fDgf/xIiinJ+UrGZZgf/hDfPd6smfzDchcbEY7u2AadzG6wOP880tH4O1VBXrCjCpWe n5n64souSRCfGC8IuGyIclFxAMZW/HLa/mAtzkU3zTlZmnpd1fpwGc+SdoU/Osgtuy3I +lGQ== X-Gm-Message-State: AHPjjUh5FaUT9TQbn/L2F1+rP9e1kEH8E9cwWM8rOJblQUWNJvKyDHJh YentPOXr41iwa/RYoeEuYfbaOgHpHjMqie19P34= X-Google-Smtp-Source: ADKCNb5Ms5zGImWxhpruQjM+1tu5TPg9dASPADgmTU3OZflM2g+fUKQiemcSvV9agmWrRvP50z8AfoYCQ1vSfA1c/+E= X-Received: by 10.98.68.206 with SMTP id m75mr3601722pfi.163.1504884831926; Fri, 08 Sep 2017 08:33:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.148.198 with HTTP; Fri, 8 Sep 2017 08:33:51 -0700 (PDT) In-Reply-To: References: <20170908021116.6ksnrkapj3dvuder@localhost> From: "David F." Date: Fri, 8 Sep 2017 08:33:51 -0700 Message-ID: To: Gary Lin Cc: 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, 08 Sep 2017 15:30:59 -0000 Content-Type: text/plain; charset="UTF-8" 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