From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 12E39222A334C for ; Wed, 24 Jan 2018 08:07:50 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C13C8C05972A; Wed, 24 Jan 2018 16:13:18 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-13.rdu2.redhat.com [10.10.121.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0AADB5C890; Wed, 24 Jan 2018 16:13:16 +0000 (UTC) To: "Wu, Jiaxin" , "Fu, Siyuan" , "Ye, Ting" , "Long, Qin" , "Yao, Jiewen" , "Hsiung, Harry L" Cc: edk2-devel-01 References: <5307d880-d016-ad91-04f5-6b83eb40f905@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635E571@SHSMSX103.ccr.corp.intel.com> <7b529d2c-1e46-3bd5-d8a6-9225a630f23b@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F0B5@SHSMSX103.ccr.corp.intel.com> <366c3083-0eb1-ecb4-2050-654c09135f8a@redhat.com> <93bf358e-7e57-a0f0-b8ba-239e72036c27@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F6BC@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B72741635F7FE@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B72741635F9AF@SHSMSX103.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <925c091e-af14-2449-e3ba-f8d6302dea49@redhat.com> Date: Wed, 24 Jan 2018 17:13:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <895558F6EA4E3B41AC93A00D163B72741635F9AF@SHSMSX103.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 24 Jan 2018 16:13:18 +0000 (UTC) Subject: Re: setting the TLS cipher list for HTTPS booting X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 16:07:51 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/24/18 07:50, Wu, Jiaxin wrote: > Hi Laszlo, > > After the discussion with team member, we still prefer to use the PCD > solution. In HttpDxe driver, we don't want to locate/use a > nonstandard protocol. We think It's not a general solution for the > UEFI driver. Ah, I totally missed that NetworkPkg/HttpDxe was a UEFI_DRIVER! :) In that case, I think *neither* the LocateProtocol() call for an edk2-specific protocol, *nor* a PcdGetPtr() call are appropriate. UEFI_DRIVER modules should preferably only use facilities from the UEFI spec, and the protocol for the dynamic PCDs comes from the PI spec, not the UEFI spec. (This would be different if HttpDxe was a DXE_DRIVER -- in that case both approaches would be valid. I assumed HttpDxe was a DXE_DRIVER, not sure why.) (1) So, given that HttpDxe is a UEFI_DRIVER, I think the right approach would be -- which I believe I also mentioned earlier -- to introduce another UEFI variable for the list of cipher suites, similarly to "TlsCaCertificate" (in a custom variable namespace GUID). This would stay within the framework of the UEFI spec. (2) Regarding the order between setting these UEFI variables in OVMF, and consuming them in HttpDxe, I think your argument is good. We can set the variables in some platform code (DXE_DRIVER) in OVMF, before End-of-DXE, and HttpDxe will only read them later in BDS. "OvmfPkg/PlatformDxe" seems like a good candidate for setting these variables (both considering PlatformDxe's purpose, and because it already depends on "gEfiVariableWriteArchProtocolGuid"). (3) Regardig the format (EFI_TLS_CIPHER): I agree with you. It seems we can modify the host environment to pass QEMU (and OVMF) a cipher list that is already in EFI_TLS_CIPHER format. So I think the only remaining question is if you like a new UEFI variable instead of the dynamic PCD, for the cipher list. Thanks! Laszlo > > Thanks, > Jiaxin > >> -----Original Message----- >> From: Wu, Jiaxin >> Sent: Wednesday, January 24, 2018 11:40 AM >> To: Wu, Jiaxin ; Laszlo Ersek ; Fu, >> Siyuan ; Ye, Ting ; Long, Qin >> ; Yao, Jiewen ; Hsiung, Harry L >> >> Cc: edk2-devel-01 >> Subject: RE: setting the TLS cipher list for HTTPS booting >> >> Hi Laszlo, >> >> More comments: >> >>> >>> Dynamic PCDs is just one of the solutions for the required settings, just like >> the >>> platform protocol (HTTPS_CONFIG_PROTOCOL), provides the capability to >>> support the global HTTPS configuration. >>> >>> Each solutions have its own advantages and disadvantages: >>> 1) PCD can simplify the problem and it's easy to use for the other platform >> not >>> only OVMF, but as you said, it's perhaps overkill. >>> 2) The additional platform protocol looks flexible and reasonably, but it >> makes >>> the specific platform have the optional dependency ["OVMF hooks a NULL- >> class >>> library into HttpDxe that introduces a new DEPEX on the protocol. Other >>> platforms would not delay HttpDxe."]. If the user doesn't want HTTPS feature >>> but only HTTP, it has to include one NULL protocol. >>> >> >> I checked the PciHostBridgeDxe driver to call the EDKII_IOMMU_PROTOCOL, >> which makes me better understanding your comments. >> >> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf { >> >> ... >> NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf >> } >> >> So, as you said, it's just the platform behavior so as to hook the platform >> produces the EDKII_IOMMU_PROTOCOL protocol first, then dispatch >> PciHostBridgeDxe driver. That's good to me. >> >> For HTTPS configuration, the HttpDxe configuration is only happened during the >> protocol instance calling, which is created by service binding protocol. So, it >> looks only happened after EndofDxe phase. If so, it will be no such optional >> dependency to wait for the platform DXE driver produces the >> EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL. >> >> Anyway, for above two solutions, I need review them with other colleagues and >> help to collect the comments for both of them, then feedback to you. Thank you >> so such. >> >> >>> Now, I think we are discussing the most appropriate way for the HTTPS >>> controlling. It's NOT related to who should be responsible for the solution >>> coding, you know we are always thinking from the user's perspective:). >>> >>> >>>>> >>>>> If you really think that HttpDxe should only care about these two items >>>>> (CA cert and cipher list), then I have another question: do you think it >>>>> makes sense to introduce another non-volatile UEFI variable, for the >>>>> cipher suites too? This would make things uniform, and perhaps >>>>> TlsAuthConfigDxe could expose the cipher suites too, as a list of >>>>> checkboxes. Just an idea. >>>> >>>> So, apparently we indeed care about these two options mostly, i.e., the >>>> CA certs, and the cipher suites. >>>> >>>> However, I was informed that OVMF should simply forward the *textual* >>>> cipher list representation, with preferably no processing at all before >>>> the string reaches the OpenSSL code. In other words, OVMF should set the >>>> PCD -- or, even better, variable -- to a *character string* like this: >>>> >>>> >>> >> "kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!EXP:!DES:!RC4:!RC2:!IDEA:!SEE >>>> D:!eNULL:!aNULL:!MD5:!SSLv2" >>>> >>>> Is this feasible? >>> >>> It looks impossible to simply forward the *textual*cipher list to OpenSSL from >>> the aspect of EFI_TLS_PROTOCOL. >>> >>> //************************************************************ >>> // EFI_TLS_CIPHER >>> //************************************************************ >>> typedef struct { >>> UINT8 Data1; >>> UINT8 Data2; >>> } EFI_TLS_CIPHER; >>> Note: The definition of EFI_TLS_CIPHER is from RFC 5246 A.4.1.Hello >> Messages. >>> The value of >>> EFI_TLS_CIPHER is from TLS Cipher Suite Registry of IANA. >>> >>> >>>> >>>> Thanks, >>>> Laszlo >>> >>> >> >> >> Thanks, >> Jiaxin >