From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01471C433FE for ; Wed, 8 Dec 2021 09:55:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231250AbhLHJ6u (ORCPT ); Wed, 8 Dec 2021 04:58:50 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:35018 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231236AbhLHJ6t (ORCPT ); Wed, 8 Dec 2021 04:58:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638957317; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RbXsax9ldMWCPX0huGTH/ykVh4lOIdMfM3HnOVtd9Sg=; b=aIngM+RNlDJYqmFVsxxa/oDJnNiNn9DbRcV1bedZrbJoegN7HM4sl68oOoNS5OtMBiHZPZ +9VnOhbTUpfLg+4+W7TaUhK5oWXD7mYxvh3Kf/s3RfcImuIz1SRGQWreGeFlFK94l7QSXV 38KpndJoC2fotNGC0rhLRX6MPZmDVTw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-413-MBArii7hOAGNVhEwT_QDGA-1; Wed, 08 Dec 2021 04:55:12 -0500 X-MC-Unique: MBArii7hOAGNVhEwT_QDGA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8C4231023F4D; Wed, 8 Dec 2021 09:55:07 +0000 (UTC) Received: from rhtmp (unknown [10.39.193.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id A1B142B178; Wed, 8 Dec 2021 09:54:57 +0000 (UTC) Date: Wed, 8 Dec 2021 10:54:55 +0100 From: Philipp Rudo To: Michal =?UTF-8?B?U3VjaMOhbmVr?= Cc: keyrings@vger.kernel.org, kexec@lists.infradead.org, Mimi Zohar , Nayna , Rob Herring , linux-s390@vger.kernel.org, Vasily Gorbik , Lakshmi Ramasubramanian , Heiko Carstens , Jessica Yu , linux-kernel@vger.kernel.org, David Howells , Christian Borntraeger , Luis Chamberlain , Paul Mackerras , Hari Bathini , Alexander Gordeev , linuxppc-dev@lists.ozlabs.org, Frank van der Linden , Thiago Jung Bauermann , Daniel Axtens , buendgen@de.ibm.com, Michael Ellerman , Benjamin Herrenschmidt , Christian Borntraeger , Herbert Xu , "David S. Miller" , Dmitry Kasatkin , James Morris , "Serge E. Hallyn" , Sven Schnelle , Baoquan He , linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH v2 0/6] KEXEC_SIG with appended signature Message-ID: <20211208105455.00085532@rhtmp> In-Reply-To: <20211207173221.GM117207@kunlun.suse.cz> References: <20211207171014.2cfc4a54@rhtmp> <20211207173221.GM117207@kunlun.suse.cz> Organization: Red Hat inc. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi Michal, On Tue, 7 Dec 2021 18:32:21 +0100 Michal Such=C3=A1nek wrote: > On Tue, Dec 07, 2021 at 05:10:14PM +0100, Philipp Rudo wrote: > > Hi Michal, > >=20 > > i finally had the time to take a closer look at the series. Except for > > the nit in patch 4 and my personal preference in patch 6 the code looks > > good to me. > >=20 > > What I don't like are the commit messages on the first commits. In my > > opinion they are so short that they are almost useless. For example in > > patch 2 there is absolutely no explanation why you can simply copy the > > s390 over to ppc. =20 >=20 > They use the same signature format. I suppose I can add a note saying > that. The note is what I was asking for. For me the commit message is an important piece of documentation for other developers (or yourself in a year). That's why in my opinion it's important to describe _why_ you do something in it as you cannot get the _why_ by reading the code. > > Or in patch 3 you are silently changing the error > > code in kexec from EKEYREJECT to ENODATA. So I would appreciate it if = =20 >=20 > Not sure what I should do about this. The different implementations use > different random error codes, and when they are unified the error code > clearly changes for one or the other. My complaint wasn't that you change the return code. There's no way to avoid choosing one over the other. It's again that you don't document the change in the commit message for others. > Does anything depend on a particular error code returned? Not that I know of. At least in the kexec-tools ENODATA and EKEYREJECT are handled the same way. Thanks Philipp > Thanks >=20 > Michal >=20 > > you could improve them a little. > >=20 > > Thanks > > Philipp > >=20 > > On Thu, 25 Nov 2021 19:02:38 +0100 > > Michal Suchanek wrote: > > =20 > > > Hello, > > >=20 > > > This is resend of the KEXEC_SIG patchset. > > >=20 > > > The first patch is new because it'a a cleanup that does not require a= ny > > > change to the module verification code. > > >=20 > > > The second patch is the only one that is intended to change any > > > functionality. > > >=20 > > > The rest only deduplicates code but I did not receive any review on t= hat > > > part so I don't know if it's desirable as implemented. > > >=20 > > > The first two patches can be applied separately without the rest. > > >=20 > > > Thanks > > >=20 > > > Michal > > >=20 > > > Michal Suchanek (6): > > > s390/kexec_file: Don't opencode appended signature check. > > > powerpc/kexec_file: Add KEXEC_SIG support. > > > kexec_file: Don't opencode appended signature verification. > > > module: strip the signature marker in the verification function. > > > module: Use key_being_used_for for log messages in > > > verify_appended_signature > > > module: Move duplicate mod_check_sig users code to mod_parse_sig > > >=20 > > > arch/powerpc/Kconfig | 11 +++++ > > > arch/powerpc/kexec/elf_64.c | 14 ++++++ > > > arch/s390/kernel/machine_kexec_file.c | 42 ++---------------- > > > crypto/asymmetric_keys/asymmetric_type.c | 1 + > > > include/linux/module_signature.h | 1 + > > > include/linux/verification.h | 4 ++ > > > kernel/module-internal.h | 2 - > > > kernel/module.c | 12 +++-- > > > kernel/module_signature.c | 56 ++++++++++++++++++++++= +- > > > kernel/module_signing.c | 33 +++++++------- > > > security/integrity/ima/ima_modsig.c | 22 ++-------- > > > 11 files changed, 113 insertions(+), 85 deletions(-) > > > =20 > > =20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AA210C433F5 for ; Wed, 8 Dec 2021 09:56:03 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4J8CGn5TsCz3c8h for ; Wed, 8 Dec 2021 20:56:01 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=KaqJZb0L; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=X+MevUrU; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=170.10.129.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=prudo@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=KaqJZb0L; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=X+MevUrU; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4J8CG22168z2yn2 for ; Wed, 8 Dec 2021 20:55:20 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638957315; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RbXsax9ldMWCPX0huGTH/ykVh4lOIdMfM3HnOVtd9Sg=; b=KaqJZb0LuY6NBB85KJKxRCDEGPQqTOzRRoqTS4G7LPBT4vm3WjnhZpcylNFngD8Qk8lY/S EFSjWOsmpTNDKDmsyIEgvlWacrolFfNc475yPA++v8uXc2YqqnJWD2VuJqKAQpMavLMhYx a74SJlBDVs5KGalvyVFVxXFNUCQF868= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638957316; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RbXsax9ldMWCPX0huGTH/ykVh4lOIdMfM3HnOVtd9Sg=; b=X+MevUrUIpSz/TFVO3MRs96NhmBShsaiIs4603iHsj5M6WUTT/wF6XuJ4n3QmHfj6lFCp+ PmVSdMRXB0toDKVx4AWcc0S1s8jnm9V9+/EE4otBT3f7fwSUuydmGEzZ79cz2wLMlQvtxp YLh67+6xdDrP/mFNhLqGcyyTWP6NDRQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-413-MBArii7hOAGNVhEwT_QDGA-1; Wed, 08 Dec 2021 04:55:12 -0500 X-MC-Unique: MBArii7hOAGNVhEwT_QDGA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8C4231023F4D; Wed, 8 Dec 2021 09:55:07 +0000 (UTC) Received: from rhtmp (unknown [10.39.193.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id A1B142B178; Wed, 8 Dec 2021 09:54:57 +0000 (UTC) Date: Wed, 8 Dec 2021 10:54:55 +0100 From: Philipp Rudo To: Michal =?UTF-8?B?U3VjaMOhbmVr?= Subject: Re: [PATCH v2 0/6] KEXEC_SIG with appended signature Message-ID: <20211208105455.00085532@rhtmp> In-Reply-To: <20211207173221.GM117207@kunlun.suse.cz> References: <20211207171014.2cfc4a54@rhtmp> <20211207173221.GM117207@kunlun.suse.cz> Organization: Red Hat inc. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nayna , Mimi Zohar , David Howells , keyrings@vger.kernel.org, Paul Mackerras , Alexander Gordeev , Rob Herring , Herbert Xu , Baoquan He , Christian Borntraeger , James Morris , Lakshmi Ramasubramanian , Christian Borntraeger , "Serge E. Hallyn" , Vasily Gorbik , linux-s390@vger.kernel.org, Heiko Carstens , linux-crypto@vger.kernel.org, Hari Bathini , Daniel Axtens , Dmitry Kasatkin , Frank van der Linden , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Luis Chamberlain , Sven Schnelle , linux-security-module@vger.kernel.org, Jessica Yu , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "David S. Miller" , Thiago Jung Bauermann , buendgen@de.ibm.com Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Michal, On Tue, 7 Dec 2021 18:32:21 +0100 Michal Such=C3=A1nek wrote: > On Tue, Dec 07, 2021 at 05:10:14PM +0100, Philipp Rudo wrote: > > Hi Michal, > >=20 > > i finally had the time to take a closer look at the series. Except for > > the nit in patch 4 and my personal preference in patch 6 the code looks > > good to me. > >=20 > > What I don't like are the commit messages on the first commits. In my > > opinion they are so short that they are almost useless. For example in > > patch 2 there is absolutely no explanation why you can simply copy the > > s390 over to ppc. =20 >=20 > They use the same signature format. I suppose I can add a note saying > that. The note is what I was asking for. For me the commit message is an important piece of documentation for other developers (or yourself in a year). That's why in my opinion it's important to describe _why_ you do something in it as you cannot get the _why_ by reading the code. > > Or in patch 3 you are silently changing the error > > code in kexec from EKEYREJECT to ENODATA. So I would appreciate it if = =20 >=20 > Not sure what I should do about this. The different implementations use > different random error codes, and when they are unified the error code > clearly changes for one or the other. My complaint wasn't that you change the return code. There's no way to avoid choosing one over the other. It's again that you don't document the change in the commit message for others. > Does anything depend on a particular error code returned? Not that I know of. At least in the kexec-tools ENODATA and EKEYREJECT are handled the same way. Thanks Philipp > Thanks >=20 > Michal >=20 > > you could improve them a little. > >=20 > > Thanks > > Philipp > >=20 > > On Thu, 25 Nov 2021 19:02:38 +0100 > > Michal Suchanek wrote: > > =20 > > > Hello, > > >=20 > > > This is resend of the KEXEC_SIG patchset. > > >=20 > > > The first patch is new because it'a a cleanup that does not require a= ny > > > change to the module verification code. > > >=20 > > > The second patch is the only one that is intended to change any > > > functionality. > > >=20 > > > The rest only deduplicates code but I did not receive any review on t= hat > > > part so I don't know if it's desirable as implemented. > > >=20 > > > The first two patches can be applied separately without the rest. > > >=20 > > > Thanks > > >=20 > > > Michal > > >=20 > > > Michal Suchanek (6): > > > s390/kexec_file: Don't opencode appended signature check. > > > powerpc/kexec_file: Add KEXEC_SIG support. > > > kexec_file: Don't opencode appended signature verification. > > > module: strip the signature marker in the verification function. > > > module: Use key_being_used_for for log messages in > > > verify_appended_signature > > > module: Move duplicate mod_check_sig users code to mod_parse_sig > > >=20 > > > arch/powerpc/Kconfig | 11 +++++ > > > arch/powerpc/kexec/elf_64.c | 14 ++++++ > > > arch/s390/kernel/machine_kexec_file.c | 42 ++---------------- > > > crypto/asymmetric_keys/asymmetric_type.c | 1 + > > > include/linux/module_signature.h | 1 + > > > include/linux/verification.h | 4 ++ > > > kernel/module-internal.h | 2 - > > > kernel/module.c | 12 +++-- > > > kernel/module_signature.c | 56 ++++++++++++++++++++++= +- > > > kernel/module_signing.c | 33 +++++++------- > > > security/integrity/ima/ima_modsig.c | 22 ++-------- > > > 11 files changed, 113 insertions(+), 85 deletions(-) > > > =20 > > =20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mutfW-00C0Rx-16 for kexec@lists.infradead.org; Wed, 08 Dec 2021 09:55:23 +0000 Date: Wed, 8 Dec 2021 10:54:55 +0100 From: Philipp Rudo Subject: Re: [PATCH v2 0/6] KEXEC_SIG with appended signature Message-ID: <20211208105455.00085532@rhtmp> In-Reply-To: <20211207173221.GM117207@kunlun.suse.cz> References: <20211207171014.2cfc4a54@rhtmp> <20211207173221.GM117207@kunlun.suse.cz> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Michal =?UTF-8?B?U3VjaMOhbmVr?= Cc: keyrings@vger.kernel.org, kexec@lists.infradead.org, Mimi Zohar , Nayna , Rob Herring , linux-s390@vger.kernel.org, Vasily Gorbik , Lakshmi Ramasubramanian , Heiko Carstens , Jessica Yu , linux-kernel@vger.kernel.org, David Howells , Christian Borntraeger , Luis Chamberlain , Paul Mackerras , Hari Bathini , Alexander Gordeev , linuxppc-dev@lists.ozlabs.org, Frank van der Linden , Thiago Jung Bauermann , Daniel Axtens , buendgen@de.ibm.com, Michael Ellerman , Benjamin Herrenschmidt , Christian Borntraeger , Herbert Xu , "David S. Miller" , Dmitry Kasatkin , James Morris , "Serge E. Hallyn" , Sven Schnelle , Baoquan He , linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org SGkgTWljaGFsLAoKT24gVHVlLCA3IERlYyAyMDIxIDE4OjMyOjIxICswMTAwCk1pY2hhbCBTdWNo w6FuZWsgPG1zdWNoYW5la0BzdXNlLmRlPiB3cm90ZToKCj4gT24gVHVlLCBEZWMgMDcsIDIwMjEg YXQgMDU6MTA6MTRQTSArMDEwMCwgUGhpbGlwcCBSdWRvIHdyb3RlOgo+ID4gSGkgTWljaGFsLAo+ ID4gCj4gPiBpIGZpbmFsbHkgaGFkIHRoZSB0aW1lIHRvIHRha2UgYSBjbG9zZXIgbG9vayBhdCB0 aGUgc2VyaWVzLiBFeGNlcHQgZm9yCj4gPiB0aGUgbml0IGluIHBhdGNoIDQgYW5kIG15IHBlcnNv bmFsIHByZWZlcmVuY2UgaW4gcGF0Y2ggNiB0aGUgY29kZSBsb29rcwo+ID4gZ29vZCB0byBtZS4K PiA+IAo+ID4gV2hhdCBJIGRvbid0IGxpa2UgYXJlIHRoZSBjb21taXQgbWVzc2FnZXMgb24gdGhl IGZpcnN0IGNvbW1pdHMuIEluIG15Cj4gPiBvcGluaW9uIHRoZXkgYXJlIHNvIHNob3J0IHRoYXQg dGhleSBhcmUgYWxtb3N0IHVzZWxlc3MuIEZvciBleGFtcGxlIGluCj4gPiBwYXRjaCAyIHRoZXJl IGlzIGFic29sdXRlbHkgbm8gZXhwbGFuYXRpb24gd2h5IHlvdSBjYW4gc2ltcGx5IGNvcHkgdGhl Cj4gPiBzMzkwIG92ZXIgdG8gcHBjLiAgCj4gCj4gVGhleSB1c2UgdGhlIHNhbWUgc2lnbmF0dXJl IGZvcm1hdC4gSSBzdXBwb3NlIEkgY2FuIGFkZCBhIG5vdGUgc2F5aW5nCj4gdGhhdC4KClRoZSBu b3RlIGlzIHdoYXQgSSB3YXMgYXNraW5nIGZvci4gRm9yIG1lIHRoZSBjb21taXQgbWVzc2FnZSBp cyBhbgppbXBvcnRhbnQgcGllY2Ugb2YgZG9jdW1lbnRhdGlvbiBmb3Igb3RoZXIgZGV2ZWxvcGVy cyAob3IgeW91cnNlbGYgaW4gYQp5ZWFyKS4gVGhhdCdzIHdoeSBpbiBteSBvcGluaW9uIGl0J3Mg aW1wb3J0YW50IHRvIGRlc2NyaWJlIF93aHlfIHlvdSBkbwpzb21ldGhpbmcgaW4gaXQgYXMgeW91 IGNhbm5vdCBnZXQgdGhlIF93aHlfIGJ5IHJlYWRpbmcgdGhlIGNvZGUuCgo+ID4gT3IgaW4gcGF0 Y2ggMyB5b3UgYXJlIHNpbGVudGx5IGNoYW5naW5nIHRoZSBlcnJvcgo+ID4gY29kZSBpbiBrZXhl YyBmcm9tIEVLRVlSRUpFQ1QgdG8gRU5PREFUQS4gU28gSSB3b3VsZCBhcHByZWNpYXRlIGl0IGlm ICAKPiAKPiBOb3Qgc3VyZSB3aGF0IEkgc2hvdWxkIGRvIGFib3V0IHRoaXMuIFRoZSBkaWZmZXJl bnQgaW1wbGVtZW50YXRpb25zIHVzZQo+IGRpZmZlcmVudCByYW5kb20gZXJyb3IgY29kZXMsIGFu ZCB3aGVuIHRoZXkgYXJlIHVuaWZpZWQgdGhlIGVycm9yIGNvZGUKPiBjbGVhcmx5IGNoYW5nZXMg Zm9yIG9uZSBvciB0aGUgb3RoZXIuCgpNeSBjb21wbGFpbnQgd2Fzbid0IHRoYXQgeW91IGNoYW5n ZSB0aGUgcmV0dXJuIGNvZGUuIFRoZXJlJ3Mgbm8gd2F5IHRvCmF2b2lkIGNob29zaW5nIG9uZSBv dmVyIHRoZSBvdGhlci4gSXQncyBhZ2FpbiB0aGF0IHlvdSBkb24ndCBkb2N1bWVudAp0aGUgY2hh bmdlIGluIHRoZSBjb21taXQgbWVzc2FnZSBmb3Igb3RoZXJzLgoKPiBEb2VzIGFueXRoaW5nIGRl cGVuZCBvbiBhIHBhcnRpY3VsYXIgZXJyb3IgY29kZSByZXR1cm5lZD8KCk5vdCB0aGF0IEkga25v dyBvZi4gQXQgbGVhc3QgaW4gdGhlIGtleGVjLXRvb2xzIEVOT0RBVEEgYW5kIEVLRVlSRUpFQ1QK YXJlIGhhbmRsZWQgdGhlIHNhbWUgd2F5LgoKVGhhbmtzClBoaWxpcHAKCgo+IFRoYW5rcwo+IAo+ IE1pY2hhbAo+IAo+ID4geW91IGNvdWxkIGltcHJvdmUgdGhlbSBhIGxpdHRsZS4KPiA+IAo+ID4g VGhhbmtzCj4gPiBQaGlsaXBwCj4gPiAKPiA+IE9uIFRodSwgMjUgTm92IDIwMjEgMTk6MDI6Mzgg KzAxMDAKPiA+IE1pY2hhbCBTdWNoYW5layA8bXN1Y2hhbmVrQHN1c2UuZGU+IHdyb3RlOgo+ID4g ICAKPiA+ID4gSGVsbG8sCj4gPiA+IAo+ID4gPiBUaGlzIGlzIHJlc2VuZCBvZiB0aGUgS0VYRUNf U0lHIHBhdGNoc2V0Lgo+ID4gPiAKPiA+ID4gVGhlIGZpcnN0IHBhdGNoIGlzIG5ldyBiZWNhdXNl IGl0J2EgYSBjbGVhbnVwIHRoYXQgZG9lcyBub3QgcmVxdWlyZSBhbnkKPiA+ID4gY2hhbmdlIHRv IHRoZSBtb2R1bGUgdmVyaWZpY2F0aW9uIGNvZGUuCj4gPiA+IAo+ID4gPiBUaGUgc2Vjb25kIHBh dGNoIGlzIHRoZSBvbmx5IG9uZSB0aGF0IGlzIGludGVuZGVkIHRvIGNoYW5nZSBhbnkKPiA+ID4g ZnVuY3Rpb25hbGl0eS4KPiA+ID4gCj4gPiA+IFRoZSByZXN0IG9ubHkgZGVkdXBsaWNhdGVzIGNv ZGUgYnV0IEkgZGlkIG5vdCByZWNlaXZlIGFueSByZXZpZXcgb24gdGhhdAo+ID4gPiBwYXJ0IHNv IEkgZG9uJ3Qga25vdyBpZiBpdCdzIGRlc2lyYWJsZSBhcyBpbXBsZW1lbnRlZC4KPiA+ID4gCj4g PiA+IFRoZSBmaXJzdCB0d28gcGF0Y2hlcyBjYW4gYmUgYXBwbGllZCBzZXBhcmF0ZWx5IHdpdGhv dXQgdGhlIHJlc3QuCj4gPiA+IAo+ID4gPiBUaGFua3MKPiA+ID4gCj4gPiA+IE1pY2hhbAo+ID4g PiAKPiA+ID4gTWljaGFsIFN1Y2hhbmVrICg2KToKPiA+ID4gICBzMzkwL2tleGVjX2ZpbGU6IERv bid0IG9wZW5jb2RlIGFwcGVuZGVkIHNpZ25hdHVyZSBjaGVjay4KPiA+ID4gICBwb3dlcnBjL2tl eGVjX2ZpbGU6IEFkZCBLRVhFQ19TSUcgc3VwcG9ydC4KPiA+ID4gICBrZXhlY19maWxlOiBEb24n dCBvcGVuY29kZSBhcHBlbmRlZCBzaWduYXR1cmUgdmVyaWZpY2F0aW9uLgo+ID4gPiAgIG1vZHVs ZTogc3RyaXAgdGhlIHNpZ25hdHVyZSBtYXJrZXIgaW4gdGhlIHZlcmlmaWNhdGlvbiBmdW5jdGlv bi4KPiA+ID4gICBtb2R1bGU6IFVzZSBrZXlfYmVpbmdfdXNlZF9mb3IgZm9yIGxvZyBtZXNzYWdl cyBpbgo+ID4gPiAgICAgdmVyaWZ5X2FwcGVuZGVkX3NpZ25hdHVyZQo+ID4gPiAgIG1vZHVsZTog TW92ZSBkdXBsaWNhdGUgbW9kX2NoZWNrX3NpZyB1c2VycyBjb2RlIHRvIG1vZF9wYXJzZV9zaWcK PiA+ID4gCj4gPiA+ICBhcmNoL3Bvd2VycGMvS2NvbmZpZyAgICAgICAgICAgICAgICAgICAgIHwg MTEgKysrKysKPiA+ID4gIGFyY2gvcG93ZXJwYy9rZXhlYy9lbGZfNjQuYyAgICAgICAgICAgICAg fCAxNCArKysrKysKPiA+ID4gIGFyY2gvczM5MC9rZXJuZWwvbWFjaGluZV9rZXhlY19maWxlLmMg ICAgfCA0MiArKy0tLS0tLS0tLS0tLS0tLS0KPiA+ID4gIGNyeXB0by9hc3ltbWV0cmljX2tleXMv YXN5bW1ldHJpY190eXBlLmMgfCAgMSArCj4gPiA+ICBpbmNsdWRlL2xpbnV4L21vZHVsZV9zaWdu YXR1cmUuaCAgICAgICAgIHwgIDEgKwo+ID4gPiAgaW5jbHVkZS9saW51eC92ZXJpZmljYXRpb24u aCAgICAgICAgICAgICB8ICA0ICsrCj4gPiA+ICBrZXJuZWwvbW9kdWxlLWludGVybmFsLmggICAg ICAgICAgICAgICAgIHwgIDIgLQo+ID4gPiAga2VybmVsL21vZHVsZS5jICAgICAgICAgICAgICAg ICAgICAgICAgICB8IDEyICsrKy0tCj4gPiA+ICBrZXJuZWwvbW9kdWxlX3NpZ25hdHVyZS5jICAg ICAgICAgICAgICAgIHwgNTYgKysrKysrKysrKysrKysrKysrKysrKystCj4gPiA+ICBrZXJuZWwv bW9kdWxlX3NpZ25pbmcuYyAgICAgICAgICAgICAgICAgIHwgMzMgKysrKysrKy0tLS0tLS0KPiA+ ID4gIHNlY3VyaXR5L2ludGVncml0eS9pbWEvaW1hX21vZHNpZy5jICAgICAgfCAyMiArKy0tLS0t LS0tCj4gPiA+ICAxMSBmaWxlcyBjaGFuZ2VkLCAxMTMgaW5zZXJ0aW9ucygrKSwgODUgZGVsZXRp b25zKC0pCj4gPiA+ICAgCj4gPiAgIAo+IAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmtleGVjIG1haWxpbmcgbGlzdAprZXhlY0BsaXN0cy5pbmZyYWRl YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8va2V4ZWMK