From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 6CAAF20957460 for ; Tue, 27 Mar 2018 19:25:17 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0EBC74000B6E; Wed, 28 Mar 2018 02:31:54 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-136.rdu2.redhat.com [10.10.120.136]) by smtp.corp.redhat.com (Postfix) with ESMTP id 232F7215CDB5; Wed, 28 Mar 2018 02:31:52 +0000 (UTC) To: "Fu, Siyuan" , "Wu, Jiaxin" Cc: edk2-devel-01 , "Daniel P. Berrange" , Star Zeng References: <32764418-f00f-2423-216d-24b3f842a3c7@redhat.com> From: Laszlo Ersek Message-ID: Date: Wed, 28 Mar 2018 04:31:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 28 Mar 2018 02:31:54 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 28 Mar 2018 02:31:54 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: internal structure of EFI_TLS_CA_CERTIFICATE_VARIABLE X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 02:25:18 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi, On 03/21/18 02:30, Fu, Siyuan wrote: > Hi, Laszlo > > The data structure of EFI_TLS_CA_CERTIFICATE_VARIABLE is > EFI_SIGNATURE_LIST and we have documented this in HTTPs Boot wiki > page: > https://github.com/tianocore/tianocore.github.io/wiki/HTTPS-Boot > > You can refer section 31.4.1 "Signature Database" in UEFI 2.7 A for a > detail description of EFI_SIGNATURE_LIST structure. I implemented a "p11-kit" extractor so that it produces a sequence of EFI_SIGNATURE_LIST objects, each siglist containing a single EFI_SIGNATURE_DATA object (with an X509 CA certificate in it). In order to test that, I started writing the OVMF enablement patches, on top of the following series (pending review): [edk2] [PATCH 0/5] NetworkPkg: HTTP and TLS updates In the OVMF platform code, I created EFI_TLS_CA_CERTIFICATE_VARIABLE as a *volatile* and boot-service only variable, so that there would be no flash impact, regardless of the number and size of the certificates that the extractor produced. Unfortunately, I still ran into a limitation here. The EFI_SIGNATURE_LIST bundle produced by the extractor is 182 KB in size (it comes from the Mozilla CA root certificate bundle, aka the "ca-certificates" package). In order to create such a large variable, I had to raise the following two PCDs for OVMF: - PcdVariableStoreSize: this controls the cumulative storage size for *volatile* variables. - PcdMaxVariableSize: this limits the individual variable size for non-authenticated variables, *regardless* of their volatility. I set PcdMaxVariableSize to 256KB (to accommodate the 182KB size mentioned above, and to leave a bit of margin). I set PcdVariableStoreSize to 512KB (so that there would be quite a bit of volatile space left after a 256KB volatile variable was created). And this is where the variable driver runs into an assertion failure: > ASSERT MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c(3809): > GetNonVolatileMaxVariableSize () < (VariableStoreLength - sizeof > (VARIABLE_STORE_HEADER)) The GetNonVolatileMaxVariableSize() function calculates the maximum of PcdMaxVariableSize and PcdMaxAuthVariableSize. This is not good because I didn't mean to raise PcdMaxVariableSize for non-volatile purposes; I only meant to raise it for volatile storage. Then the InitNonVolatileVariableStore() function attempts to fit this maximum into the *flash* storage. Obviously, individual 256KB variables (which I never meant to place into flash) don't fit into flash, and the ASSERT() fires. The issue is that the variable driver does not distinguish the max variable size between volatile and non-volatile storage, and the non-volatile availability effectively limits the volatile one. I think we should have three PCDs: - PcdMaxVariableSize: non-authenticated, non-volatile - PcdMaxAuthVariableSize: authenticated, non-volatile - PcdMaxVolatileVariableSize: non-authenticated, volatile (The fourth variation needs no PCD because authenticated volatile variables make no sense.) How can we solve this? Thanks, Laszlo