From owner-freebsd-arch@freebsd.org Fri Jul 6 04:16:39 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AACEF1034FE5 for ; Fri, 6 Jul 2018 04:16:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E82E988943 for ; Fri, 6 Jul 2018 04:16:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6649L0M027743; Thu, 5 Jul 2018 21:16:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-transfer-encoding : date : message-id; s=PPS1017; bh=yaIJaXF7MQ+gUvsUBPJJTTVP2NUXBS2v6WbUPl25XuE=; b=2NcWksG0YZgflB5CvsWiqjhJDs8lYj3WAcuFvdXXTpQO1WlyQEsj5h2m/xdWfDI0vJDY 455x+Q34bmALf/h45s9gmBrqBjpNIrjTrF5z3617Qdjbjkrw3gmGTi8tJar3gn1ld2mx u2h3kC88zTgzZtv9atDQ8nwPPf8YfRBGFM3cEe1Y4E9ULJ2mcNQElEACgIp+KDowaukO MDlRxxNdlaEU86UP/ajC/NrHT8R7GxsHfAEIBIu1IMkz9nR41ucl/PMCmj3KGvDIe16A U11tNdbUhrWO3dzTV+y4WIHXuWezn2HCYQOz71TwzvEznHQ2/vgwZkUQLfKMxEtYpEbr mw== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0049.outbound.protection.outlook.com [216.32.181.49]) by mx0a-00273201.pphosted.com with ESMTP id 2k1vq58cnq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Jul 2018 21:16:36 -0700 Received: from SN4PR0501CA0022.namprd05.prod.outlook.com (2603:10b6:803:40::35) by CO2PR05MB619.namprd05.prod.outlook.com (2a01:111:e400:141c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.16; Fri, 6 Jul 2018 04:16:33 +0000 Received: from DM3NAM05FT048.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::201) by SN4PR0501CA0022.outlook.office365.com (2603:10b6:803:40::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.952.8 via Frontend Transport; Fri, 6 Jul 2018 04:16:33 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.13 as permitted sender) Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by DM3NAM05FT048.mail.protection.outlook.com (10.152.98.162) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.930.2 via Frontend Transport; Fri, 6 Jul 2018 04:16:32 +0000 Received: from P-EXFEND-EQX-02.jnpr.net (10.104.8.55) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 5 Jul 2018 21:16:32 -0700 Received: from P-EMFE01C-SAC.jnpr.net (172.24.192.43) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Frontend Transport; Thu, 5 Jul 2018 21:16:32 -0700 Received: from p-mailhub01.juniper.net (10.47.226.20) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 5 Jul 2018 21:16:31 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w664GUQM031189; Thu, 5 Jul 2018 21:16:31 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 934FD63F4D; Thu, 5 Jul 2018 21:16:30 -0700 (PDT) To: CC: , Subject: Re: [Differential] D16155: Add veriexec to loader In-Reply-To: <84d9b7dd268a8cb64b51e4c49753bed8@localhost.localdomain> References: <84d9b7dd268a8cb64b51e4c49753bed8@localhost.localdomain> Comments: In-reply-to: "cem (Conrad Meyer)" message dated "Fri, 06 Jul 2018 02:35:06 -0000." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jul 2018 21:16:30 -0700 Message-ID: <93705.1530850590@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.13; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39860400002)(136003)(2980300002)(199004)(189003)(55016002)(11346002)(105596002)(97876018)(8746002)(8936002)(81156014)(53416004)(81166006)(8676002)(76506005)(356003)(2351001)(106466001)(69596002)(9686003)(446003)(126002)(2810700001)(229853002)(97736004)(476003)(305945005)(486006)(7126003)(86362001)(14444005)(6266002)(53936002)(68736007)(50466002)(6246003)(50226002)(4326008)(77096007)(7696005)(186003)(76176011)(5660300001)(26005)(478600001)(2486003)(6346003)(336012)(316002)(47776003)(23676004)(54906003)(2906002)(117636001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB619; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT048; 1:jQ5uGSFAIQmgcB7aKkZxStfd6P5wctptmjLzDFcHCxYMWo9U5mXqqhG2wuY3q7t13UupcSnIN0eQ5P+867DugRarvzahQWqE7ZsVHEs4MDi2FAgkNJ2DrkHBR36a47hI X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4eb83184-204b-42a3-63a8-08d5e2f741c1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060); SRVR:CO2PR05MB619; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB619; 3:XPfifInSFM2iOjq/MhW1qaVQ6vnOuAxkVifnZSYUzMBHaOHgpk+0WD/621zWkA6seR5Kqq8OtbcG30kdrKA+8FV4h2/KkHOXvkOzioPPvkWteLRX9l1vfl+L4nhWNopdaXNg0klyk8UjajRT7oJRBGI27gl4gr3YkwTQJ2nIzsvzTGr5nSH1hIREcARtHn1cq/yYyz+duwUJ6BtLfJutZWURZ8pcYLU4mog8UjXMEWSdK3avVaKMOJoYXio7j9M2pTyiJ1Rkkw8pV7u27ux0phR5G7Te07K61ZWSOlcp7w60/GrQYEgnfKAgt4d8q53JpSMyWLS+PrXONA3Yz/A4IhhtOaSU/kdwlEQqlohXIPk=; 25:LDY7gFCKHjshNK80uHBJMW2H+6LVHyLPqiRucE739VAphldABDBChTKnEft1vDAnlHJ+hhteBBYFQOhwKlvcMa0rt6t9J2ajmkCAU2mk27xnAZHACzAuBAgg94tpjYnS5+qC5KSZgr8GVySKlX/Rf5RAGG+GTdUo/9hF9MYPhkazJ+ZpfwR5wSWGAcsIWlNgrRyFCDy5lha+44T6DLwLTR8QCDIx59fqF5lUE9HCab3D1LfQTmrmk+xWZ2cGyarkJ6mxAUlCwcC3t076KEmRw+MxpdEIFULYPSTSpEKTMsTRVJVR28bWIbrIlN1//zpF88nlHndPUb7q2m+1PKvJHg== X-MS-TrafficTypeDiagnostic: CO2PR05MB619: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB619; 31:fNIpm/cOtQt/UgEn5B9QvLl3Jneiwe4hogvuIfHpLrZSfk/jTBVDSb7RQXD1t4azNJyaU43pLrnoozfUvpLGRKm12kN+EQLLI5RRXHyEjXQAz7MiPTd4/GZVl+21YeKaJ6qKipKRKbBZdx9sI+ZJKK1LM2vrNLC4TRCdklSxiTBecoh8hfneUOTQ+72u8WvutYf7mYzf4bpVkI9MILmtRS9L84AIRLDBtJLFeHLva/A=; 20:p0mRtHAuBL1stOKBVD3aMAvpyoojpzEltmJECmDBueb5Bmhy574JvqL8NaLmgq2omXPY2vWkEG1EibSACOKAd3WHQzpRw0Pmag1Rtnua2Ri6JHiKq1hgg82h11qofrWkC3t8P1mC2mfkE4cSEKx54nxCYKPTyPRD6DVrQuwqn345SySnHPmZGvrx9jVG6omJHejji6PRaNb7j1jNxDNyaiKleZiC3Qs79OLuPAX9k1tF8D/HupBGAxfrbwEC4IqfISZiVgnKSapLi2S5Tvg/6+KjqPfb/4j9/c/vVrpv0QlxN38CQxAK1gzD0CvCCV4udoOg2dNXVfgvFq521RqL0WgcYTzaZiVOM0t1SxTo64lpQLMX3Zoc8eDgwlpo89+8lQ0DwUBpHrOfk4mtxFrGeKNUQ0Cy1wpUiaMaA8e5/VI9aDB9S22QtqhZ/f0uWUVYFfXtPdVTXCB8a048ftsENYaFbXNrR8/QL2H2BcOG0QrjZQUR0c+GEn7JSSH4Q3Z7 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93003095)(3231290)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:CO2PR05MB619; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB619; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB619; 4:OGl7XmMLhBojRPdyK9E0PUu83dBUkddbueFCusxxTp80JdjBQrkSkGgGgMFRj8+ZO5kAN9Oplv6xGmOcZjNjLPYJEWdp70+54lmf9YPLv5r4yM5mIgJBvD3DOj3BNTHdhcjjgeQFMYNNMf6/r+9QGei02FZRMKgSW3+LfAqltlIeU3+1YB/uh5DaVcOIAaBmrejfH20Y8ZX66olpl++JCCpvT1ekOkqc+xQ2iNvB5vqh7i1aFYIYV5gIedL1lS9WE45nXDTcMsnNN7AdjrZzBg== X-Forefront-PRVS: 0725D9E8D0 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUI2MTk7MjM6WE0xaHZEcm40WjZORGYzd2d1Y3RDZmlYK2Jy?= =?utf-8?B?NUJPT1AzVnhzVkt5RUNCREh5aG1EUjY3emdwaWh1RFU2d1NWLzZhUEh6ZDNI?= =?utf-8?B?QzVQOXVFektEVU11MlVBYnNwdHhaWW1ESFVDc2dMOWxwbEJSa1dubWZhQU9i?= =?utf-8?B?MjA4Nk8rTGQrZXAxck94K3dHYWFyWWFOc1V1akZWZ1lENWNDZW0rVWFwV21q?= =?utf-8?B?Uk1JVnZlMkNVSWdkUlRmZ3FUN0FzZnhyakhhdkFGS2hJMlRzVXliRVpPcGts?= =?utf-8?B?Ym1BekhheWtIS01zT2MraXdnNmZKSTVyWlByWG8yeWlEQTYvK3FRbTRGRmQy?= =?utf-8?B?ZEs5SmdPV2IzRXJCSUxUWThoQWEwdUJxYWNnbjZPU2tSaDhrWm1vbzBMbnMr?= =?utf-8?B?eDZHNmtBYnR0ZURkdXdJZjhJay9FallKeXo4eVFxTlBKQjJzZHlldk9nS2FQ?= =?utf-8?B?ZVRCRDhLOWg2eTFWMGh3TUJiQkNmRFNjdEI4bjlyUjkyY1lwbFhqWDRMK3l4?= =?utf-8?B?eXgyYXBYNjZpcUF6TWpNTTNWR0syd0NaQ09wU0U3WGxETC9wRVIweGcrMUh4?= =?utf-8?B?eVJMQWsxa3FmK3B4Q2N6d0tkSWxhSFZQVXk1VkZBKzRlckxGN2xvQUhOWURV?= =?utf-8?B?dzJpaDdhZGtlaEs3dmVlTzVtWjFrSkpCbit4UmZrRmluaWFmaWhIcDRpbm1v?= =?utf-8?B?QnUxUzBWZDNuRjJ5UGp4Q1pmYTVibVh6ckg5TXg5TnVhS29wbFcxcGRQd2Jr?= =?utf-8?B?MW9HWG1abUJiaUd6bUZtQSsvdE9hYnpCMGwwN3ZjWHFXN3F2eGlSLytLSU9x?= =?utf-8?B?U0ZXdHI3b3NoQ0RJUDNpMzByMkFaM1creVV6SlQ0cUlPRSs2Z1IrTlpZUVda?= =?utf-8?B?T01kd3FneHR5UVV3and5VHRFRmlFSkszbVRqTHgrTFFhR2ZDNzlkREZPUTdz?= =?utf-8?B?NWw0N3BNTG1qb0dUaWE2N0N1RWlEWjd5NUh3V1N3NklCbnZWOEw2dWFCVm1j?= =?utf-8?B?clZQczlCeHRXN1RsSjdzVTNwSjRxS3Nyd0xvTnBndWZTVEZGRGtBcm5WbC9u?= =?utf-8?B?RUhwNllUTU1mbUF4ak42V0Z2eXphc3JmS094b3ZKRVFUQWFsaENNNTdxSVA4?= =?utf-8?B?VGcyNDBTS0w2ZWRWaTlhaDdZY3plWU02MEJna3FGSVZ1alU0ckx3UHJnZExp?= =?utf-8?B?RDdMRHFLM2EwMWtRcUp4YlBHWWhLcmdzMFZRMmNCeC9WN2IrZjJ0REp1ZmJ0?= =?utf-8?B?NU1pREJvSXcxYWZpNVlqM1pkWTFYVCt4ZHRkN3p4RGpSYkZqdExNbGt2eXlx?= =?utf-8?B?dWU4NWlTZ2R0S21CZ043bHYvck9xN3JhWmZXcjh5ZUNPbUQwZGs0VDF4SjEr?= =?utf-8?B?ZFlMejNWVWtBK1pGelkwL0ZvbGpIdU5YOEhjNjRrMmhTalZzS29PcVVHR0RW?= =?utf-8?B?SGt4bGpzT0VNTUgyL1pHRTQvVXo0YVpLSDI3S3JuSllLQ21PYTltZkh3L0Rm?= =?utf-8?B?OTVCVlB5NmFaa0ZCYjF0eERJQVlibjdLTVJEckpKb0FOK1ozMkE5YkJxMjU4?= =?utf-8?B?N1RIL056cm5velBsM2x6UnhmS1QySUR1SEZVRHpkVC9PRndsRE5velhKL2hT?= =?utf-8?B?YVRoVnRQMmdTSE51UGxZMmZPWWVNVlZDTWpXTEk5elprS0NPMnloWU11YzVC?= =?utf-8?B?SytKRnc0alJHbm1KdU04WUoxRXhyQmROZ0ptZ2ZpcmF3Z1RKcHN0MDRONk5i?= =?utf-8?Q?7AlhVSfbujIdjdsytD2kHI7CR6rBO046lSdw=3D?= X-Microsoft-Antispam-Message-Info: m5mfTiUJYfjI38FtIocP4lFkc+nQFS1Mc57S2eCjL66p56dwfqPS0/1Clj3dmgnJZ6kght46Dug5szBpiGGebzpUhQuXmq0dLhCaGuHrPJ58UObxOaJznWh0Q03mpvj2w4KNDbP19m6auZQXHFjOn5lYQVJDzwa8znQ2jp1xoPTDljKWErMWGGmxHAFydryEgKDTDha7yWvLscHnLLbVDSByCZSYDI9DxqKEV02SlvsWI6+bXNfgXBu1DEP+jYqDv+gUIHrlJU6n0i0YOKXNZE4d06UO62+Mg6Z+eEg+5Quixp153uen6qbA9pF3EXDMtuzjXHy7/5gOeOhZjL6cl7L36cwuN4kl3SbVxwhBjik= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB619; 6:58AMWRRUJNsXjDAOStsDGIBXYWnCj4BLq37OzpYZR5CFtJC37bGwmWa7h34ZL4qyY7gwNbpWtQA37L62u6IZCNbW1TeWeyewSlEv5/ZZCW2h1swEr8Fps5Qp3J10g3fJfLeme9LAxL3CPsgJGzSKuoWFNUnzqTgjD9CvGBwn0q0MxznfohLWkigryAG1zPgsggu9xmZNOVi61W6X9T+L+xKGd5LYVf5RQaYkExdIg77c8R0u5d5uX+P3tjNElcnfM17+MXgc1ks2/jVe7SftWmGb2YYq2sa2E7muELRLQkd2BzpmA7bakT+xqB2oCWnVrTAj9s7AB4CsuJzqcG+DYGFUOKxPF114OxhB5d4iEB7OuiwaVHIOHyY2QvQDnjBMudz+Po4GJNb4p2NAUi1co6jskWLltjKVHpP7/wr986Z5B749qbj8/7nAlnethcf0EbG+5yFm4M3UOWBjzOGgYg==; 5:PsPeOfx14Z6PFr191Na+k26NpJYlM2jw4/AevpDkXoh+08MVV+xkenyo5heF6pCdiXdQUaJGVLKH8SV4oGt7hvv1BHT4ntgLB+4OSGLVx9s1MW82bgu1pdsSUz5jo7G21y6shZOVgxJPq1x64KcIR1Vmq5Izo27GbQYY0S5zd0M=; 24:/9yoeSA5v3YCYjb/K632v9xE82Z8e3HOBL9L+psasEzuQ7jLqXBqRRqPVlnx9/udA/svdCN796zxsWSYEd6EKBxp3V411cAXL/wqK4Ew2TI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB619; 7:NhQphLKrkY7/K4UD9dgHXuWNFfkaDaBeWEnifmYKFsO8spQYMAqxoNmvehiCD7Hz+XlGHVr6XK9xmadmJuO6f2PNAyVRoJBY9KElQ7+gC929CC2d4jv6Gl0bPM8qmonyWVQsY3QqfkxCZ2CzRSRxJJ/FTmItKX6bLLeXv7muxd0VROx4vTWYxtiUGsmdmqAulfsXP0rxQgBjuiqqquWsB9NkqzqVlO0S3g7XZ9neDcoQGlQIIJosjTcT/S7y2KM5 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2018 04:16:32.9223 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4eb83184-204b-42a3-63a8-08d5e2f741c1 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.13]; Helo=[P-EXFEND-EQX-02.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB619 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060044 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 04:16:39 -0000 +freebsd-arch since I refuse to top-post via phab, and this all warrants a discussion anyway... Most style(9) comments will be dealt with - no discussion here. > - Why are we using PGP in any new cryptosystem? Because lots of people in the real world want to be able to use it? Like everything else, it is optional. > - Why are we using ASN.1 / x509 =E2=80=94 a notoriously difficult schem= e to parse correctly =E2=80=94 in the kernel or loader? Because it provides a high level of flexibility. Ie. I can load a brand new version of Junos on a 10+ year old version, and it will be able to verify all the signatures. Unlike some other designs that would force me to install intermediate versions in sequence. > - Why the plethora of duplicated functionality (e.g., above)? > (Also, the five different SHA hashes. Pick one that's good enough For the above requirement I need to ensure that the s/w I shipped 10+ years ago, knows how to handle hashes that were not required then. Also there is no need to enable any hashes that you do not want. > and just use it everywhere. SHA512 provides no meaningful benefit > over SHA256, but it also isn't clear that a basic hash is the > right construct anyway. There is no reason to use SHA384 at all.) Yes, there is - if/when SHA256 is deprecated. Hopefully SHA512/256 will be approved before then. > - What alternatives to x509 or PGP were considered and dismissed? > Please make it clear that you've done your research and examined > other options.=20 I gave a talk about this at BSDCan in June. At the end of the day, you can propose and implement an alternate design and see if anyone wants it. > - Why RSA or ECDSA (both have easy ways to foot-shoot) in new > cryptosystems, vs something like Ed25519?=20 Because as a vendor who sells to US Govt I'm limited to algorithms approved for that purpose. You can of course add anything you like. > - SHA1 should not be used at all. It is optional for that reason and not enabled by default. However we are using it and will continue to until NIST ban it. > Meta issues: >=20=20=20 > - Use of strcmp() for signature comparison. You want timingsafe_memcmp= (). In the loader? It is a single threaded app. > - Have you thought about wiping key memory before releasing it? I > don't see any invocations of explicit_bzero() (or bzero/memset, > for that matter). There are no private keys involved here at all. Public keys do not need any such treatment - they are not sensitive data. > > +#define VE_GUESS -1 /* let verify_file work it out */ > > +#define VE_TRY 0 /* we don't mind if unverified */ > > +#define VE_WANT 1 /* we want this verified */ >=20 > Both of these concepts seem pretty dubious. >=20 > The loader and kernel should not be guessing signing policy =E2=80=94 per= iod. If you can propose a means whereby every bit of lua and .4th can communicate to the loader the verification requirements... > Files either have a signature or do not. If they do, they must be > verified. If they don't, they cannot be verified. Not sure what try > or want has to do with that. Please go watch my talk from BSDCan. This is all covered. Yes, anything which has a hash must verify correctly. The above all only apply when no hash is found. Whether that is acceptible depends on the caller - never acceptible for modules, but may be ok for loader.conf and other files which may need to be mutable. > > tvo.c:36 > > +{ > > + int n; > > + int fd; >=20 > indent style in this file seems wrong Will go check - might have missed during recent style9 update. =20 > > vectx.c:124 > > + if (strncmp(cp, "sha256=3D", 7) =3D=3D 0) { > > + ctx->vec_md =3D &br_sha256_vtable; > > + hashsz =3D br_sha256_SIZE; >=20 > OCF (or openssl =E2=80=94 this appears to be userspace) supports all of t= hese > hashes. Why are we using bearssl for this? No, this is not userland, this api is specificially for the loader and specific to its loading of modules and kernel. It is not currently used - that will require a significant rototill of load_elf.c OpenSSL is at least an order of magnitude too big to be used in the loader. BearSSL allows all this to be done in ~100K All covered in my BSDCan talk > > veopen.c:117 > > + } > > + LIST_FOREACH(fip, &fi_list, entries) { > > + if (nfip->fi_prefix_len >=3D fip->fi_prefix_len) { >=20 > This is not going to be pretty with any significant number of verified fi= les. The loader does not deal with significant numbers of files. Further, it only deals with each file once. =20 > > veopen.c:136-137 > > +{ > > + char pbuf[MAXPATHLEN+1]; > > + char nbuf[MAXPATHLEN+1]; > > + struct stat st; >=20 > This is a lot of stack =E2=80=94 is this file userspace-only? Yes it is (quite a lot), and no it is loader only. It has not proven to be an issue, even when using old boot2 to boot stable/6 > > veopen.c:302 > > + n =3D 2*hlen; > > + if ((rc =3D strncmp(hex, want, n))) { > > + ve_error_set("%s: %.*s !=3D %.*s", path, n, hex, n, want); >=20 > Why are we comparing a printed hash at all? Because that's what's captured in the manifest. > > veopen.c:404-412 > > + * @brief > > + * open a file if it can be verified > > + * > > + * @param[in] path > > + * pathname to open > > + * > > + * @param[in] flags >=20 > None of the previous portion of this comment adds anything of value > for the reader beyond the information already present in the function > name and parameter types and names below. The comment is for extraction to api documentation (doxygen) > > verify.c:270 > > + strcmp(cp, ".hints") =3D=3D 0) > > + return VE_TRY; > > + } >=20 > What does "try" mean in this context? It means we don't really expect this file to have a hash. So even in strict mode (eg for FIPS 140) we won't get upset if it doesn't have one. If it does have one of course, then it must match. > > verify.c:380 > > + cp++; > > + if (strncmp(cp, "loader.ve.", 10) =3D=3D 0) { > > + cp +=3D 10; >=20 > kludge? Yes and no. We are taking advantage of the fact that the pathname is verified as well as its content, so we can use the pathname to communicate tuning info to loader eg "strict" mode for FIPS-140, even "off" for folk that don't care and want to speed up boot time. Again; covered in my BSDCan talk. > > vets.c:208 > > + /* This is deprecated! do not enable unless you absoultely have to */ > > + br_x509_minimal_set_hash(&mc, br_sha1_ID, &br_sha1_vtable); > > +#endif >=20 > Just remove it. There's no reason to be using SHA1 in novel > cryptographic designs in 2018. If you use it in JunOS, keep the SHA1 > stuff in JunOS, but I'd suggest moving away from SHA1 there, too. This is not a novel design - it's 15+ years old, but in this case perhaps, was useful for testing. > > vets.c:294 > > + > > + return hex; > > +} >=20 > Ew. Is this loader-only code? Mostly, but not necessarily. >=20 > > vets.c:381 > > + if (!vrfy(sdata, slen, hash_oid, mlen, pkey, vhbuf) || > > + memcmp(vhbuf, mdata, mlen) !=3D 0) { > > + return 0; /* fail */ >=20 > should this be timingsafe_memcmp? I cannot think of a reason why... > > vets.c:497-500 > > + cn_oid[0] =3D 3; > > + cn_oid[1] =3D 0x55; > > + cn_oid[2] =3D 4; > > + cn_oid[3] =3D 3; >=20 > This is pretty magical Yes. BearSSL is a very low level library. The comment above it, indicates that this is the DER encoded OID for the commonName field. --sjg