[{"id":1771668,"web_url":"http://patchwork.ozlabs.org/comment/1771668/","msgid":"<87shfhlqu1.fsf@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-20T08:25:10","subject":"Re: [Skiboot] [PATCH 1/3] libstb/stb.c: add ibm,\n\tsecureboot-v2 support","submitter":{"id":48041,"url":"http://patchwork.ozlabs.org/api/people/48041/","name":"Stewart Smith","email":"stewart@linux.vnet.ibm.com"},"content":"Claudio Carvalho writes:\n> This extends libstb to add support to 'ibm,secureboot-v2' and also\n> updates the device tree documentation accordingly.\n>\n> Signed-off-by: Claudio Carvalho \n> ---\n> .../ibm,container-verification-code.rst | 57 ++++++++++++\n> doc/device-tree/ibm,secureboot.rst | 83 +++++++++++------\n> libstb/stb.c | 101 +++++++++++++++++++++\n> 3 files changed, 211 insertions(+), 30 deletions(-)\n> create mode 100644 doc/device-tree/ibm,container-verification-code.rst\n>\n> diff --git a/doc/device-tree/ibm,container-verification-code.rst b/doc/device-tree/ibm,container-verification-code.rst\n> new file mode 100644\n> index 0000000..9d92e7c\n> --- /dev/null\n> +++ b/doc/device-tree/ibm,container-verification-code.rst\n> @@ -0,0 +1,57 @@\n> +.. _device-tree/ibm,container-verification-code:\n> +\n> +ibm,container-verification-code\n> +===============================\n> +\n> +This describes the container-verification-code from ``ibm,secureboot-v2``\n> +onwards. Each ``ibm,code-offset`` child node defines an offset of the\n> +container-verification-code.\n> +\n> +Required properties\n> +-------------------\n> +\n> +.. code-block:: none\n> +\n> + compatible: Either one of the following values:\n> +\n> + ibm,cvc-container-v1 : container-verification-code used\n> + to verify containers version 1.\n> +\n> + memory-region: this points to the hostboot reserved memory where the\n> + container-verification-code is stored.\n> +\n> +Example\n> +-------\n> +\n> +.. code-block:: dts\n> +\n> +\tibm,secureboot {\n\nThis would be separate from the ibm,secureboot node, just by convention\ncomes under it.\n\nI question the need of having this information in the device tree\nthough, is it something an OS would *ever* be interested in?\n\n\n> +\t\tphandle = <0x5b>;\n> +\t\tcompatible = \"ibm,secureboot-v2\";\n> +\t\ttrusted-enabled;\n> +\t\thw-key-hash-size = <0x40>;\n> +\t\thw-key-hash = <0x40d487ff 0x7380ed6a 0xd54775d5 0x795fea0d\n> + 0xe2f541fe 0xa9db06b8 0x466a42a3 0x20e65f75\n> + 0xb4866546 0x17d907 0x515dc2a5 0xf9fc5095\n> + 0x4d6ee0c9 0xb67d219d 0xfb708535 0x1d01d6d1>;\n> +\n> +\t\tibm,container-verification-code {\n> +\t\t\tphandle = <0xd9>;\n> +\t\t\t#address-cells = <0x1>;\n> +\t\t\t#size-cells = <0x0>;\n> +\t\t\tcompatible = \"ibm,cvc-container-v1\";\n> +\t\t\tmemory-region = <0x81>;\n> +\n> +\t\t\tibm,code-offset@40 {\n> +\t\t\t\tphandle = <0xda>;\n> +\t\t\t\tcompatible = \"ibm,sha512-hash\";\n> +\t\t\t\treg = <0x40>;\n> +\t\t\t};\n> +\n> +\t\t\tibm,code-offset@50 {\n> +\t\t\t\tphandle = <0xdb>;\n> +\t\t\t\tcompatible = \"ibm,container-verify\";\n> +\t\t\t\treg = <0x50>;\n> +\t\t\t};\n> +\t\t};\n> +\t};\n> diff --git a/doc/device-tree/ibm,secureboot.rst b/doc/device-tree/ibm,secureboot.rst\n> index 948c7e0..9681199 100644\n> --- a/doc/device-tree/ibm,secureboot.rst\n> +++ b/doc/device-tree/ibm,secureboot.rst\n> @@ -3,54 +3,77 @@\n> ibm,secureboot\n> ==============\n> \n> -Secure boot and trusted boot relies on a code stored in the secure ROM at\n> -manufacture time to verify and measure other codes before they are executed.\n> -This ROM code is also referred to as ROM verification code.\n> -\n> -On POWER8, the presence of the ROM code is announced to skiboot (by Hostboot)\n> -by the ``ibm,secureboot`` device tree node.\n> -\n> -If the system is booting up in secure mode, the ROM code is called for secure\n> -boot to verify the integrity and authenticity of an image before it is executed.\n> -\n> -If the system is booting up in trusted mode, the ROM code is called for trusted\n> -boot to calculate the SHA512 hash of an image only if the image is not a secure boot\n> -container or the system is not booting up in secure mode.\n> -\n> -For further information about secure boot and trusted boot please refer to\n> -:ref:`stb-overview`.\n> +The ``ìbm,secureboot`` node provides secure boot and trusted boot information\n> +up to the target OS.\n> \n> +Further secure and trusted boot information can be found in :ref:`stb-overview`.\n> \n> Required properties\n> -------------------\n> \n> .. code-block:: none\n> \n> - compatible: ibm,secureboot version. It is related to the ROM code version.\n> - \n> - hash-algo: hash algorithm used for the hw-key-hash. Aspects such as the size\n> - of the hw-key-hash can be infered from this property.\n> -\n> - secure-enabled: this property exists if the system is booting in secure mode.\n> + compatible: Either one of the following values:\n> +\n> + ibm,secureboot-v1 : The container-verification-code\n> + is stored in a secure ROM memory.\n> +\n> + ibm,secureboot-v2 : The container-verification-code\n> + is described by the\n> + ibm,container-verification-code\n> + child node, which points to the\n> + hostboot reserved memory where\n> + the container-verification-code\n> + is stored.\n\nI don't think we need to have a v2 here, it seems that everything would\nstill fit in the API to the OS we have with 'ibm,secureboot-v1'.\n\nOur API out to the OS is just 'secure-enabled' and 'trusted-enabled' in\norder to indicate what it should do, that is, enforce secure boot and\nmeasure things in the TPM. This continues to be the case, we've just\nchanged some of the firmware implementation of doing that.\n\n> +\n> + secure-enabled: this property exists if the firmware stack is booting\n> + in secure mode (hardware secure boot jumper asserted).\n> + In this mode, the authenticity and integrity of every\n> + firmware image is verified before it is executed using\n> + the container-verification-code. If the verification\n> + fails, the boot is halted.\n> +\n> + trusted-enabled: this property exists if the firmware stack is booting\n> + in trusted mode. In this mode, every firmware image is\n> + measured before it is executed using the\n> + container-verification-code to calculate the SHA512\n> + hash of the image. Interested parties can subsequently\n> + assess the measurements to check whether or not only\n> + trusted events happened during the boot.\n> +\n> + hw-key-hash: hash of the tree hardware public keys trusted by\n> + firmware. The three hardware keys used to sign the\n> + firmware image are stored in the secure boot headers\n> + prepended to the image. At runtime, the\n> + container-verification-code compares the hash of these\n> + three public keys against the hw-key-hash to check if\n> + the image was signed using the hardware keys trusted by\n> + firmware.\n> +\n> + hw-key-hash-size: size of hw-key-hash. Added on 'ibm,secureboot-v2'. The\n> + container-verification-code used to verify containers\n> + version 1, expect this to be equal to the SHA512 hash\n> + size.\n\nWhy no longer have the hash-algorithm?\n\ndo we need hash-size? Or is there a truncation thing going on?\n\n> +Obsolete properties\n> +-------------------\n> \n> - trusted-enabled: this property exists if the system is booting in trusted mode.\n> +.. code-block:: none\n> \n> - hw-key-hash: hash of three concatenated hardware public key. This is required\n> - by the ROM code to verify images.\n> + hash-algo: Superseeded by the hw-key-hash-size property in\n> + 'ibm,secureboot-v2'.\n> \n> Example\n> -------\n> \n> -For the first version ``ibm,secureboot-v1``, the ROM code expects the *hw-key-hash*\n> -to be a SHA512 hash.\n> -\n> .. code-block:: dts\n> \n> ibm,secureboot {\n> - compatible = \"ibm,secureboot-v1\";\n> - hash-algo = \"sha512\";\n> + compatible = \"ibm,secureboot-v2\";\n> secure-enabled;\n> trusted-enabled;\n> + hw-key-hash-size = <0x40>\n> hw-key-hash = <0x40d487ff 0x7380ed6a 0xd54775d5 0x795fea0d 0xe2f541fe\n> 0xa9db06b8 0x466a42a3 0x20e65f75 0xb4866546 0x17d907\n> 0x515dc2a5 0xf9fc5095 0x4d6ee0c9 0xb67d219d 0xfb708535\n> diff --git a/libstb/stb.c b/libstb/stb.c\n> index da0c534..eab04eb 100644\n> --- a/libstb/stb.c\n> +++ b/libstb/stb.c\n> @@ -114,6 +114,105 @@ static void cvc_free(void)\n> \t}\n> }\n> \n> +static int c1vc_offsets(struct dt_node *parent)\n\nWhat is c1vc?\n\n> +{\n> +\tstruct dt_node *mem_node, *node;\n> +\tuint32_t mem_phandle, offset;\n> +\tuint64_t mem_addr;\n> +\n> +\tc1vc = malloc(sizeof(struct container_verification_code));\n> +\tassert(c1vc);\n> +\n> +\tmem_phandle = dt_prop_get_u32(parent, \"memory-region\");\n> +\tmem_node = dt_find_by_phandle(dt_root, mem_phandle);\n> +\tassert(mem_node);\n> +\n> +\tmem_addr = dt_get_address(mem_node, 0, NULL);\n> +\n> +\tdt_for_each_child(parent, node) {\n> +\n> +\t\tif (dt_node_is_compatible(node, \"ibm,sha512-hash\")) {\n> +\t\t\toffset = dt_prop_get_u32(node, \"reg\");\n> +\t\t\toffset = be32_to_cpu(offset);\n> +\t\t\tc1vc->sha512_addr = mem_addr + offset;\n> +\t\t\tc1vc->sha512 = c1vc_sha512;\n> +\t\t}\n> +\t\telse if (dt_node_is_compatible(node, \"ibm,container-verify\")) {\n> +\t\t\toffset = dt_prop_get_u32(node, \"reg\");\n> +\t\t\toffset = be32_to_cpu(offset);\n> +\t\t\tc1vc->verify_addr = mem_addr + offset;\n> +\t\t\tc1vc->verify = c1vc_verify;\n> +\t\t} else {\n> +\t\t\tprlog(PR_INFO, \"unknown cvc offset %s\\n\", node->name);\n> +\t\t}\n> +\t}\n> +\n> +\tif (!c1vc->sha512 || !c1vc->verify) {\n> +\t\t/**\n> +\t\t * @fwts-label CVCV1OffsetsNotFound\n> +\t\t * @fwts-advice This is a bug. The sha512 and verify offsets are\n> +\t\t * required, but they were not found in the\n> +\t\t * ibm,container-verification-code device tree node.\n> +\t\t */\n> +\t\tprerror(\"STB: 'ibm,cvc-container-v1' init FAILED, offsets not found\\n\");\n> +\t\tgoto out_error;\n> +\t}\n> +\n> +\tprlog(PR_INFO, \"STB: 'ibm,secureboot-v2' initialized\\n\");\n> +\treturn 0;\n> +\n> +out_error:\n> +\tfree(c1vc);\n> +\tc1vc = NULL;\n> +\treturn -1;\n> +}\n> +\n> +static int cvc_reserved_mem_init(struct dt_node *parent)\n> +{\n> +\tstruct dt_node *node;\n> +\tint rc = -1;\n> +\n> +\thw_key_hash_size = dt_prop_get_u32(parent, \"hw-key-hash-size\");\n> +\tif (hw_key_hash_size != SHA512_DIGEST_LENGTH) {\n> +\t\t/**\n> +\t\t * @fwts-label CVCHashSizeInvalid\n> +\t\t * @fwts-advice The hash algorithm used in secure boot container\n> +\t\t * version 1 is sha512, which means that the hash size should be\n> +\t\t * 64 bytes. Hostboot may not have indicated that correctly in\n> +\t\t * the HDAT or skiboot may not have interpreted the HDAT\n> +\t\t * correctly.\n> +\t\t */\n> +\t\tprerror(\"STB: %s FAILED, hw-key-hash-size=%zd not supported\\n\",\n> +\t\t\t__func__, hw_key_hash_size);\n> +\t\treturn -1;\n> +\t}\n> +\thw_key_hash = dt_prop_get_def_size(parent, \"hw-key-hash\", NULL,\n> +\t\t\t\t\t &hw_key_hash_size);\n> +\tassert(hw_key_hash);\n> +\n> +\tdt_for_each_child(parent, node) {\n> +\t\tif (dt_node_is_compatible(node, \"ibm,container-v1-verification-code\"))\n> +\t\t\trc = c1vc_offsets(node);\n> +\t\telse\n> +\t\t\tprlog(PR_INFO, \"STB: %s unknown ibm,secureboot child\\n\",\n> +\t\t\t node->name);\n> +\t}\n> +\n> +\tif (rc) {\n> +\t\t/**\n> +\t\t * @fwts-label CompatibleCVCNotFound\n> +\t\t * @fwts-advice Compatible Container-Verification-Code driver\n> +\t\t * not found. If you're running the latest skiboot version, so\n> +\t\t * probably there is a bug in either the HDAT received from\n> +\t\t * hostboot or the HDAT parser in skiboot.\n> +\t\t */\n> +\t\tprerror(\"STB: COULD NOT FIND a compatible \"\n> +\t\t\t\"container-verification-code driver\\n\");\n> +\t\treturn -1;\n> +\t}\n> +\treturn 0;\n> +}\n> +\n> static int c1vc_mbedtls_init(struct dt_node *node)\n> {\n> \tconst char* hash_algo;\n> @@ -237,6 +336,8 @@ void stb_init(void)\n> \t\trc = c1vc_rom_init(node);\n> \t} else if (dt_node_is_compatible(node, \"ibm,secureboot-v1-softrom\")) {\n> \t\trc = c1vc_mbedtls_init(node);\n> +\t} else if (dt_node_is_compatible(node, \"ibm,secureboot-v2\")) {\n> +\t\trc = cvc_reserved_mem_init(node);\n> \t} else {\n> \t\t/**\n> \t\t * @fwts-label SecureBootNotCompatible\n> -- \n> 2.7.4\n>\n> _______________________________________________\n> Skiboot mailing list\n> Skiboot@lists.ozlabs.org\n> https://lists.ozlabs.org/listinfo/skiboot \n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","skiboot@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","skiboot@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxt940cZqz9s7p\n\tfor ;\n\tWed, 20 Sep 2017 18:25:28 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xxt935pnVzDqTc\n\tfor ;\n\tWed, 20 Sep 2017 18:25:27 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xxt8w35d5zDqBd\n\tfor ; Wed, 20 Sep 2017 18:25:20 +1000 (AEST)","from pps.filterd (m0098409.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8K8P8Ja038256\n\tfor ; Wed, 20 Sep 2017 04:25:17 -0400","from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d3mpyrd5u-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 20 Sep 2017 04:25:17 -0400","from localhost\n\tby e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 20 Sep 2017 02:25:16 -0600","from b03cxnp08025.gho.boulder.ibm.com (9.17.130.17)\n\tby e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 20 Sep 2017 02:25:14 -0600","from b03ledav003.gho.boulder.ibm.com\n\t(b03ledav003.gho.boulder.ibm.com [9.17.130.234])\n\tby b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8K8PEMY000364; Wed, 20 Sep 2017 01:25:14 -0700","from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 151146A03F;\n\tWed, 20 Sep 2017 02:25:14 -0600 (MDT)","from birb.localdomain (unknown [9.185.16.148])\n\tby b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTP id 717166A041;\n\tWed, 20 Sep 2017 02:25:13 -0600 (MDT)","by birb.localdomain (Postfix, from userid 1000)\n\tid 18DC04F0F8F; Wed, 20 Sep 2017 18:25:10 +1000 (AEST)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=stewart@linux.vnet.ibm.com; receiver=)","From":"Stewart Smith ","To":"Claudio Carvalho , skiboot@lists.ozlabs.org","In-Reply-To":"<1504166040-16531-2-git-send-email-cclaudio@linux.vnet.ibm.com>","References":"<1504166040-16531-1-git-send-email-cclaudio@linux.vnet.ibm.com>\n\t<1504166040-16531-2-git-send-email-cclaudio@linux.vnet.ibm.com>","Date":"Wed, 20 Sep 2017 18:25:10 +1000","MIME-Version":"1.0","X-TM-AS-GCONF":"00","x-cbid":"17092008-0012-0000-0000-00001508623F","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007766; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000230; SDB=6.00919662; UDB=6.00462048;\n\tIPR=6.00699889; \n\tBA=6.00005598; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017219;\n\tXFM=3.00000015; UTC=2017-09-20 08:25:15","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092008-0013-0000-0000-00004F8F8E80","Message-Id":"<87shfhlqu1.fsf@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-20_02:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=5\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709200115","Subject":"Re: [Skiboot] [PATCH 1/3] libstb/stb.c: add ibm,\n\tsecureboot-v2 support","X-BeenThere":"skiboot@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Mailing list for skiboot development ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"skiboot-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"Skiboot\"\n\t"}}]