From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AB8JxZrBHW11NZrF6mRsd2iAkLroIk4Kzlaizaqgyv+1Rc7/61tu3qKTT+ENGnMzpXwkU1NZZuW/ ARC-Seal: i=1; a=rsa-sha256; t=1526655539; cv=none; d=google.com; s=arc-20160816; b=YCm1pUShZlLHeHcmeuH311WkYBYVlkKZ6nQNhq1DQgUTELqrcWAZD3LbIbY7PF9lhp PWsFpZc9PC+kMiaVnhTtaHjsXLxNK7kZRlL25+DENa3Rcv9VWt0k7dSFB3sIPGk+flOt aLNywRs/ykAjGzRpCRZhHTJM2DkX74HcucNivGv1vtUdXN/ACgVAVsnZxegGZ4f+Xlz0 TzlTwh2qZaBHcuxyLkCOP65g5MAc1wym+pnXrx6k81a7BCnlhNstvehNuY2k5aq4AkJp xV2EU7Z7cNPgtORgeCck6ZZPIzMf6DvyBvOpswYBO6Uqu4NqHebbzPoxmGwOB2r70gmz LTkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :dkim-signature:arc-authentication-results; bh=o+rpF1WG9UDz4JlTtNGVzwEHdHWe2jyYCzNqnBxHagY=; b=i1OgzAg8WLo9fCGYV4LEgcGDN3UuL/lbqfnv2kiLMQCYgZUpZupNoA0cL8aZEEpCLu utc24uaTrBUz0MhhQxb+VNMLGTUChxuPsVW+5WoeB3M75cHjAOt71VdzV2knqRA66TWz OsG9dKT/C3Xzl1RRRJejb8W+6KaG8OHhvFqIZ3CabL3FWbVOevfRw5Pj5QtCsUCnULfN 8JzoH/N36JG0fayIvAwlb7PsYam/C+ft4KqjRAmMS4JLVfzjGp7pP8P7w8RfU2veh0n3 hrVl/G5P6fnZbCEPIKyVJWcq5vwpedT8qigjrr+MGMeKutox11shfAqOLtE25onoPWK5 VRwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yahoo.com header.s=s2048 header.b=hGgt5vpe; spf=neutral (google.com: 66.163.189.89 is neither permitted nor denied by best guess record for domain of casey@schaufler-ca.com) smtp.mailfrom=casey@schaufler-ca.com Authentication-Results: mx.google.com; dkim=pass header.i=@yahoo.com header.s=s2048 header.b=hGgt5vpe; spf=neutral (google.com: 66.163.189.89 is neither permitted nor denied by best guess record for domain of casey@schaufler-ca.com) smtp.mailfrom=casey@schaufler-ca.com X-YMail-OSG: tZig9hcVM1nVYkLuROamJO4GqOtLiHQIww9rbsBErU.YE1pfWBmXPTMOxDFyo8I R50IQ5QI2qoky1Wn9Cf_fIBXJZE0p_JZnZV1oqISKAcWoCItVvoKqxq3Nd89AZdP6ieydTDlhHD3 W818TxB9Mb1myMyzVg0USkUL7txUqclp5fp._A.VBYlwJ.2_T6ruU5xO_Ik4s4HQoRprCwHgFduu 6_uWhYqOVNVS3zmrIGlse4WLkxYZ4y4sYq6qfI4xl.Q2Ngus1RjAfOZZsDZOM980Gx2NZFNjGM7J I.nbpK_D7PAaXs5Jn33N.AnheXjtgkSrHbFVzl_04kY8iJBBUNkYa8OoTOsyQcevGhG6RjU6nrlj PLyUsesRwofu6lzruy3dIJYTvIuI1lC6ezcnxRoVaveXNr5ofgoEvEyiIiSp7yIoMnC.3gx0OYb8 zPSo4Srbwv02orrxXRCDm7bIOy9nl_HvD_pz9F_dFUTXc70dUdit8fKbNtTZQa628ZVtqr8_EZBz YQVs57fYSUh8ug3GUybxOZBxhv5ejlnn43cYAMkVTx.kXN8Modzw57gGJDUGVNm0tSS7gJZ8LPEr .0CTHSFttbevhpGJTvykrh3X4.uMskyMOX3yqBGsoXs3Mf2EEcdj_nIQOPbfg2A2HpmbqMFUlnnU xd1_AoOsNxg-- Subject: Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper To: Mimi Zohar , "Eric W. Biederman" Cc: linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , "Luis R . Rodriguez" , kexec@lists.infradead.org, Andres Rodriguez , Greg Kroah-Hartman , Ard Biesheuvel , Kees Cook , Stephen Smalley References: <1526568530-9144-1-git-send-email-zohar@linux.vnet.ibm.com> <1526568530-9144-4-git-send-email-zohar@linux.vnet.ibm.com> <74c096ca-1ad1-799e-df3d-7b1b099333a7@schaufler-ca.com> <87y3ghhbws.fsf@xmission.com> <1526643050.3632.127.camel@linux.vnet.ibm.com> From: Casey Schaufler Message-ID: Date: Fri, 18 May 2018 07:58:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526643050.3632.127.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1600723179870285580?= X-GMAIL-MSGID: =?utf-8?q?1600814358737896280?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 5/18/2018 4:30 AM, Mimi Zohar wrote: > On Thu, 2018-05-17 at 22:37 -0500, Eric W. Biederman wrote: >> Casey Schaufler writes: >> >>> On 5/17/2018 7:48 AM, Mimi Zohar wrote: >>>> In order for LSMs and IMA-appraisal to differentiate between the original >>>> and new syscalls (eg. kexec, kernel modules, firmware), both the original >>>> and new syscalls must call an LSM hook. >>>> >>>> Commit 2e72d51b4ac3 ("security: introduce kernel_module_from_file hook") >>>> introduced calling security_kernel_module_from_file() in both the original >>>> and new syscalls. Commit a1db74209483 ("module: replace >>>> copy_module_from_fd with kernel version") replaced these LSM calls with >>>> security_kernel_read_file(). >>>> >>>> Commit e40ba6d56b41 ("firmware: replace call to fw_read_file_contents() >>>> with kernel version") and commit b804defe4297 ("kexec: replace call to >>>> copy_file_from_fd() with kernel version") replaced their own version of >>>> reading a file from the kernel with the generic >>>> kernel_read_file_from_path/fd() versions, which call the pre and post >>>> security_kernel_read_file LSM hooks. >>>> >>>> Missing are LSM calls in the original kexec syscall and firmware sysfs >>>> fallback method. From a technical perspective there is no justification >>>> for defining a new LSM hook, as the existing security_kernel_read_file() >>>> works just fine. The original syscalls, however, do not read a file, so >>>> the security hook name is inappropriate. Instead of defining a new LSM >>>> hook, this patch defines security_kernel_read_blob() as a wrapper for >>>> the existing LSM security_kernel_file_read() hook. >>> What a marvelous opportunity to bikeshed! >>> >>> I really dislike adding another security_ interface just because >>> the name isn't quite right. Especially a wrapper, which is just >>> code and execution overhead. Why not change security_kernel_read_file() >>> to security_kernel_read_blob() everywhere and be done? >> Nacked-by: "Eric W. Biederman" >> >> Nack on this sharing nonsense. These two interfaces do not share any >> code in their implementations other than the if statement to distinguish >> between the two cases. >> >> Casey you are wrong. We need something different here. >> >> Mimi a wrapper does not cut it. The code is not shared. Despite using >> a single function call today. >> >> If we want comprehensible and maintainable code in the security modules >> we need to split these two pieces of functionality apart. > kernel_read_file() is a common, generic method of reading a file from > the kernel, which is being called from a number of places.  The > kernel_read_file_id enumeration is needed to differentiate between the > callers.  The purpose of the new security_kernel_read_file() calls is > not for the kernel to read a file, but as a method of identifying the > original buffer based methods containing a file. > > Having to define a separate LSM hook for each of the original, non > kernel_read_file(), buffer based method callers, kind of makes sense, > as the callers themselves are specific, but is it really necessary? > Could we define a new, generic LSM hook named > security_kernel_buffer_data() for this purpose? If there are two disparate behaviors wrapped into kernel_read_file() Eric (bless him) is right. It should be broken into two hooks. I think that if we look (too) carefully we'll find other places where hooks should get broken up, or combined*. My question is just how important is it that this gets changed? --- * calling security_inode_secid() and then immediately security_secid_to_secctx() grates on my sensibilities. From mboxrd@z Thu Jan 1 00:00:00 1970 From: casey@schaufler-ca.com (Casey Schaufler) Date: Fri, 18 May 2018 07:58:55 -0700 Subject: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper In-Reply-To: <1526643050.3632.127.camel@linux.vnet.ibm.com> References: <1526568530-9144-1-git-send-email-zohar@linux.vnet.ibm.com> <1526568530-9144-4-git-send-email-zohar@linux.vnet.ibm.com> <74c096ca-1ad1-799e-df3d-7b1b099333a7@schaufler-ca.com> <87y3ghhbws.fsf@xmission.com> <1526643050.3632.127.camel@linux.vnet.ibm.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 5/18/2018 4:30 AM, Mimi Zohar wrote: > On Thu, 2018-05-17 at 22:37 -0500, Eric W. Biederman wrote: >> Casey Schaufler writes: >> >>> On 5/17/2018 7:48 AM, Mimi Zohar wrote: >>>> In order for LSMs and IMA-appraisal to differentiate between the original >>>> and new syscalls (eg. kexec, kernel modules, firmware), both the original >>>> and new syscalls must call an LSM hook. >>>> >>>> Commit 2e72d51b4ac3 ("security: introduce kernel_module_from_file hook") >>>> introduced calling security_kernel_module_from_file() in both the original >>>> and new syscalls. Commit a1db74209483 ("module: replace >>>> copy_module_from_fd with kernel version") replaced these LSM calls with >>>> security_kernel_read_file(). >>>> >>>> Commit e40ba6d56b41 ("firmware: replace call to fw_read_file_contents() >>>> with kernel version") and commit b804defe4297 ("kexec: replace call to >>>> copy_file_from_fd() with kernel version") replaced their own version of >>>> reading a file from the kernel with the generic >>>> kernel_read_file_from_path/fd() versions, which call the pre and post >>>> security_kernel_read_file LSM hooks. >>>> >>>> Missing are LSM calls in the original kexec syscall and firmware sysfs >>>> fallback method. From a technical perspective there is no justification >>>> for defining a new LSM hook, as the existing security_kernel_read_file() >>>> works just fine. The original syscalls, however, do not read a file, so >>>> the security hook name is inappropriate. Instead of defining a new LSM >>>> hook, this patch defines security_kernel_read_blob() as a wrapper for >>>> the existing LSM security_kernel_file_read() hook. >>> What a marvelous opportunity to bikeshed! >>> >>> I really dislike adding another security_ interface just because >>> the name isn't quite right. Especially a wrapper, which is just >>> code and execution overhead. Why not change security_kernel_read_file() >>> to security_kernel_read_blob() everywhere and be done? >> Nacked-by: "Eric W. Biederman" >> >> Nack on this sharing nonsense. These two interfaces do not share any >> code in their implementations other than the if statement to distinguish >> between the two cases. >> >> Casey you are wrong. We need something different here. >> >> Mimi a wrapper does not cut it. The code is not shared. Despite using >> a single function call today. >> >> If we want comprehensible and maintainable code in the security modules >> we need to split these two pieces of functionality apart. > kernel_read_file() is a common, generic method of reading a file from > the kernel, which is being called from a number of places. ?The > kernel_read_file_id enumeration is needed to differentiate between the > callers. ?The purpose of the new security_kernel_read_file() calls is > not for the kernel to read a file, but as a method of identifying the > original buffer based methods containing a file. > > Having to define a separate LSM hook for each of the original, non > kernel_read_file(), buffer based method callers, kind of makes sense, > as the callers themselves are specific, but is it really necessary? > Could we define a new, generic LSM hook named > security_kernel_buffer_data() for this purpose? If there are two disparate behaviors wrapped into kernel_read_file() Eric (bless him) is right. It should be broken into two hooks. I think that if we look (too) carefully we'll find other places where hooks should get broken up, or combined*. My question is just how important is it that this gets changed? --- * calling security_inode_secid() and then immediately security_secid_to_secctx() grates on my sensibilities. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic306-27.consmr.mail.ne1.yahoo.com ([66.163.189.89]:36883 "EHLO sonic306-27.consmr.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751009AbeERO67 (ORCPT ); Fri, 18 May 2018 10:58:59 -0400 Subject: Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper To: Mimi Zohar , "Eric W. Biederman" Cc: linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , "Luis R . Rodriguez" , kexec@lists.infradead.org, Andres Rodriguez , Greg Kroah-Hartman , Ard Biesheuvel , Kees Cook , Stephen Smalley References: <1526568530-9144-1-git-send-email-zohar@linux.vnet.ibm.com> <1526568530-9144-4-git-send-email-zohar@linux.vnet.ibm.com> <74c096ca-1ad1-799e-df3d-7b1b099333a7@schaufler-ca.com> <87y3ghhbws.fsf@xmission.com> <1526643050.3632.127.camel@linux.vnet.ibm.com> From: Casey Schaufler Message-ID: Date: Fri, 18 May 2018 07:58:55 -0700 MIME-Version: 1.0 In-Reply-To: <1526643050.3632.127.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Sender: linux-integrity-owner@vger.kernel.org List-ID: On 5/18/2018 4:30 AM, Mimi Zohar wrote: > On Thu, 2018-05-17 at 22:37 -0500, Eric W. Biederman wrote: >> Casey Schaufler writes: >> >>> On 5/17/2018 7:48 AM, Mimi Zohar wrote: >>>> In order for LSMs and IMA-appraisal to differentiate between the original >>>> and new syscalls (eg. kexec, kernel modules, firmware), both the original >>>> and new syscalls must call an LSM hook. >>>> >>>> Commit 2e72d51b4ac3 ("security: introduce kernel_module_from_file hook") >>>> introduced calling security_kernel_module_from_file() in both the original >>>> and new syscalls. Commit a1db74209483 ("module: replace >>>> copy_module_from_fd with kernel version") replaced these LSM calls with >>>> security_kernel_read_file(). >>>> >>>> Commit e40ba6d56b41 ("firmware: replace call to fw_read_file_contents() >>>> with kernel version") and commit b804defe4297 ("kexec: replace call to >>>> copy_file_from_fd() with kernel version") replaced their own version of >>>> reading a file from the kernel with the generic >>>> kernel_read_file_from_path/fd() versions, which call the pre and post >>>> security_kernel_read_file LSM hooks. >>>> >>>> Missing are LSM calls in the original kexec syscall and firmware sysfs >>>> fallback method. From a technical perspective there is no justification >>>> for defining a new LSM hook, as the existing security_kernel_read_file() >>>> works just fine. The original syscalls, however, do not read a file, so >>>> the security hook name is inappropriate. Instead of defining a new LSM >>>> hook, this patch defines security_kernel_read_blob() as a wrapper for >>>> the existing LSM security_kernel_file_read() hook. >>> What a marvelous opportunity to bikeshed! >>> >>> I really dislike adding another security_ interface just because >>> the name isn't quite right. Especially a wrapper, which is just >>> code and execution overhead. Why not change security_kernel_read_file() >>> to security_kernel_read_blob() everywhere and be done? >> Nacked-by: "Eric W. Biederman" >> >> Nack on this sharing nonsense. These two interfaces do not share any >> code in their implementations other than the if statement to distinguish >> between the two cases. >> >> Casey you are wrong. We need something different here. >> >> Mimi a wrapper does not cut it. The code is not shared. Despite using >> a single function call today. >> >> If we want comprehensible and maintainable code in the security modules >> we need to split these two pieces of functionality apart. > kernel_read_file() is a common, generic method of reading a file from > the kernel, which is being called from a number of places. The > kernel_read_file_id enumeration is needed to differentiate between the > callers. The purpose of the new security_kernel_read_file() calls is > not for the kernel to read a file, but as a method of identifying the > original buffer based methods containing a file. > > Having to define a separate LSM hook for each of the original, non > kernel_read_file(), buffer based method callers, kind of makes sense, > as the callers themselves are specific, but is it really necessary? > Could we define a new, generic LSM hook named > security_kernel_buffer_data() for this purpose? If there are two disparate behaviors wrapped into kernel_read_file() Eric (bless him) is right. It should be broken into two hooks. I think that if we look (too) carefully we'll find other places where hooks should get broken up, or combined*. My question is just how important is it that this gets changed? --- * calling security_inode_secid() and then immediately security_secid_to_secctx() grates on my sensibilities. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from sonic306-27.consmr.mail.ne1.yahoo.com ([66.163.189.89]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fJgqd-0004C9-38 for kexec@lists.infradead.org; Fri, 18 May 2018 14:59:12 +0000 Subject: Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper References: <1526568530-9144-1-git-send-email-zohar@linux.vnet.ibm.com> <1526568530-9144-4-git-send-email-zohar@linux.vnet.ibm.com> <74c096ca-1ad1-799e-df3d-7b1b099333a7@schaufler-ca.com> <87y3ghhbws.fsf@xmission.com> <1526643050.3632.127.camel@linux.vnet.ibm.com> From: Casey Schaufler Message-ID: Date: Fri, 18 May 2018 07:58:55 -0700 MIME-Version: 1.0 In-Reply-To: <1526643050.3632.127.camel@linux.vnet.ibm.com> Content-Language: en-US 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: Mimi Zohar , "Eric W. Biederman" Cc: Kees Cook , Ard Biesheuvel , Greg Kroah-Hartman , kexec@lists.infradead.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , "Luis R . Rodriguez" , Andres Rodriguez , linux-integrity@vger.kernel.org, Stephen Smalley T24gNS8xOC8yMDE4IDQ6MzAgQU0sIE1pbWkgWm9oYXIgd3JvdGU6Cj4gT24gVGh1LCAyMDE4LTA1 LTE3IGF0IDIyOjM3IC0wNTAwLCBFcmljIFcuIEJpZWRlcm1hbiB3cm90ZToKPj4gQ2FzZXkgU2No YXVmbGVyIDxjYXNleUBzY2hhdWZsZXItY2EuY29tPiB3cml0ZXM6Cj4+Cj4+PiBPbiA1LzE3LzIw MTggNzo0OCBBTSwgTWltaSBab2hhciB3cm90ZToKPj4+PiBJbiBvcmRlciBmb3IgTFNNcyBhbmQg SU1BLWFwcHJhaXNhbCB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlIG9yaWdpbmFsCj4+Pj4g YW5kIG5ldyBzeXNjYWxscyAoZWcuIGtleGVjLCBrZXJuZWwgbW9kdWxlcywgZmlybXdhcmUpLCBi b3RoIHRoZSBvcmlnaW5hbAo+Pj4+IGFuZCBuZXcgc3lzY2FsbHMgbXVzdCBjYWxsIGFuIExTTSBo b29rLgo+Pj4+Cj4+Pj4gQ29tbWl0IDJlNzJkNTFiNGFjMyAoInNlY3VyaXR5OiBpbnRyb2R1Y2Ug a2VybmVsX21vZHVsZV9mcm9tX2ZpbGUgaG9vayIpCj4+Pj4gaW50cm9kdWNlZCBjYWxsaW5nIHNl Y3VyaXR5X2tlcm5lbF9tb2R1bGVfZnJvbV9maWxlKCkgaW4gYm90aCB0aGUgb3JpZ2luYWwKPj4+ PiBhbmQgbmV3IHN5c2NhbGxzLiAgQ29tbWl0IGExZGI3NDIwOTQ4MyAoIm1vZHVsZTogcmVwbGFj ZQo+Pj4+IGNvcHlfbW9kdWxlX2Zyb21fZmQgd2l0aCBrZXJuZWwgdmVyc2lvbiIpIHJlcGxhY2Vk IHRoZXNlIExTTSBjYWxscyB3aXRoCj4+Pj4gc2VjdXJpdHlfa2VybmVsX3JlYWRfZmlsZSgpLgo+ Pj4+Cj4+Pj4gQ29tbWl0IGU0MGJhNmQ1NmI0MSAoImZpcm13YXJlOiByZXBsYWNlIGNhbGwgdG8g ZndfcmVhZF9maWxlX2NvbnRlbnRzKCkKPj4+PiB3aXRoIGtlcm5lbCB2ZXJzaW9uIikgYW5kIGNv bW1pdCBiODA0ZGVmZTQyOTcgICgia2V4ZWM6IHJlcGxhY2UgY2FsbCB0bwo+Pj4+IGNvcHlfZmls ZV9mcm9tX2ZkKCkgd2l0aCBrZXJuZWwgdmVyc2lvbiIpIHJlcGxhY2VkIHRoZWlyIG93biB2ZXJz aW9uIG9mCj4+Pj4gcmVhZGluZyBhIGZpbGUgZnJvbSB0aGUga2VybmVsIHdpdGggdGhlIGdlbmVy aWMKPj4+PiBrZXJuZWxfcmVhZF9maWxlX2Zyb21fcGF0aC9mZCgpIHZlcnNpb25zLCB3aGljaCBj YWxsIHRoZSBwcmUgYW5kIHBvc3QKPj4+PiBzZWN1cml0eV9rZXJuZWxfcmVhZF9maWxlIExTTSBo b29rcy4KPj4+Pgo+Pj4+IE1pc3NpbmcgYXJlIExTTSBjYWxscyBpbiB0aGUgb3JpZ2luYWwga2V4 ZWMgc3lzY2FsbCBhbmQgZmlybXdhcmUgc3lzZnMKPj4+PiBmYWxsYmFjayBtZXRob2QuICBGcm9t IGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlIHRoZXJlIGlzIG5vIGp1c3RpZmljYXRpb24KPj4+PiBm b3IgZGVmaW5pbmcgYSBuZXcgTFNNIGhvb2ssIGFzIHRoZSBleGlzdGluZyBzZWN1cml0eV9rZXJu ZWxfcmVhZF9maWxlKCkKPj4+PiB3b3JrcyBqdXN0IGZpbmUuICBUaGUgb3JpZ2luYWwgc3lzY2Fs bHMsIGhvd2V2ZXIsIGRvIG5vdCByZWFkIGEgZmlsZSwgc28KPj4+PiB0aGUgc2VjdXJpdHkgaG9v ayBuYW1lIGlzIGluYXBwcm9wcmlhdGUuICBJbnN0ZWFkIG9mIGRlZmluaW5nIGEgbmV3IExTTQo+ Pj4+IGhvb2ssIHRoaXMgcGF0Y2ggZGVmaW5lcyBzZWN1cml0eV9rZXJuZWxfcmVhZF9ibG9iKCkg YXMgYSB3cmFwcGVyIGZvcgo+Pj4+IHRoZSBleGlzdGluZyBMU00gc2VjdXJpdHlfa2VybmVsX2Zp bGVfcmVhZCgpIGhvb2suCj4+PiBXaGF0IGEgbWFydmVsb3VzIG9wcG9ydHVuaXR5IHRvIGJpa2Vz aGVkIQo+Pj4KPj4+IEkgcmVhbGx5IGRpc2xpa2UgYWRkaW5nIGFub3RoZXIgc2VjdXJpdHlfIGlu dGVyZmFjZSBqdXN0IGJlY2F1c2UKPj4+IHRoZSBuYW1lIGlzbid0IHF1aXRlIHJpZ2h0LiBFc3Bl Y2lhbGx5IGEgd3JhcHBlciwgd2hpY2ggaXMganVzdAo+Pj4gY29kZSBhbmQgZXhlY3V0aW9uIG92 ZXJoZWFkLiBXaHkgbm90IGNoYW5nZSBzZWN1cml0eV9rZXJuZWxfcmVhZF9maWxlKCkKPj4+IHRv IHNlY3VyaXR5X2tlcm5lbF9yZWFkX2Jsb2IoKSBldmVyeXdoZXJlIGFuZCBiZSBkb25lPwo+PiBO YWNrZWQtYnk6ICJFcmljIFcuIEJpZWRlcm1hbiIgPGViaWVkZXJtQHhtaXNzaW9uLmNvbT4KPj4K Pj4gTmFjayBvbiB0aGlzIHNoYXJpbmcgbm9uc2Vuc2UuICBUaGVzZSB0d28gaW50ZXJmYWNlcyBk byBub3Qgc2hhcmUgYW55Cj4+IGNvZGUgaW4gdGhlaXIgaW1wbGVtZW50YXRpb25zIG90aGVyIHRo YW4gdGhlIGlmIHN0YXRlbWVudCB0byBkaXN0aW5ndWlzaAo+PiBiZXR3ZWVuIHRoZSB0d28gY2Fz ZXMuCj4+Cj4+IENhc2V5IHlvdSBhcmUgd3JvbmcuICBXZSBuZWVkIHNvbWV0aGluZyBkaWZmZXJl bnQgaGVyZS4KPj4KPj4gTWltaSBhIHdyYXBwZXIgZG9lcyBub3QgY3V0IGl0LiAgIFRoZSBjb2Rl IGlzIG5vdCBzaGFyZWQuICBEZXNwaXRlIHVzaW5nCj4+IGEgc2luZ2xlIGZ1bmN0aW9uIGNhbGwg dG9kYXkuCj4+Cj4+IElmIHdlIHdhbnQgY29tcHJlaGVuc2libGUgYW5kIG1haW50YWluYWJsZSBj b2RlIGluIHRoZSBzZWN1cml0eSBtb2R1bGVzCj4+IHdlIG5lZWQgdG8gc3BsaXQgdGhlc2UgdHdv IHBpZWNlcyBvZiBmdW5jdGlvbmFsaXR5IGFwYXJ0Lgo+IGtlcm5lbF9yZWFkX2ZpbGUoKSBpcyBh IGNvbW1vbiwgZ2VuZXJpYyBtZXRob2Qgb2YgcmVhZGluZyBhIGZpbGUgZnJvbQo+IHRoZSBrZXJu ZWwsIHdoaWNoIGlzIGJlaW5nIGNhbGxlZCBmcm9tIGEgbnVtYmVyIG9mIHBsYWNlcy4gwqBUaGUK PiBrZXJuZWxfcmVhZF9maWxlX2lkIGVudW1lcmF0aW9uIGlzIG5lZWRlZCB0byBkaWZmZXJlbnRp YXRlIGJldHdlZW4gdGhlCj4gY2FsbGVycy4gwqBUaGUgcHVycG9zZSBvZiB0aGUgbmV3IHNlY3Vy aXR5X2tlcm5lbF9yZWFkX2ZpbGUoKSBjYWxscyBpcwo+IG5vdCBmb3IgdGhlIGtlcm5lbCB0byBy ZWFkIGEgZmlsZSwgYnV0IGFzIGEgbWV0aG9kIG9mIGlkZW50aWZ5aW5nIHRoZQo+IG9yaWdpbmFs IGJ1ZmZlciBiYXNlZCBtZXRob2RzIGNvbnRhaW5pbmcgYSBmaWxlLgo+Cj4gSGF2aW5nIHRvIGRl ZmluZSBhIHNlcGFyYXRlIExTTSBob29rIGZvciBlYWNoIG9mIHRoZSBvcmlnaW5hbCwgbm9uCj4g a2VybmVsX3JlYWRfZmlsZSgpLCBidWZmZXIgYmFzZWQgbWV0aG9kIGNhbGxlcnMsIGtpbmQgb2Yg bWFrZXMgc2Vuc2UsCj4gYXMgdGhlIGNhbGxlcnMgdGhlbXNlbHZlcyBhcmUgc3BlY2lmaWMsIGJ1 dCBpcyBpdCByZWFsbHkgbmVjZXNzYXJ5Pwo+IENvdWxkIHdlIGRlZmluZSBhIG5ldywgZ2VuZXJp YyBMU00gaG9vayBuYW1lZAo+IHNlY3VyaXR5X2tlcm5lbF9idWZmZXJfZGF0YSgpIGZvciB0aGlz IHB1cnBvc2U/CgpJZiB0aGVyZSBhcmUgdHdvIGRpc3BhcmF0ZSBiZWhhdmlvcnMgd3JhcHBlZCBp bnRvIGtlcm5lbF9yZWFkX2ZpbGUoKQpFcmljIChibGVzcyBoaW0pIGlzIHJpZ2h0LiBJdCBzaG91 bGQgYmUgYnJva2VuIGludG8gdHdvIGhvb2tzLiBJIHRoaW5rCnRoYXQgaWYgd2UgbG9vayAodG9v KSBjYXJlZnVsbHkgd2UnbGwgZmluZCBvdGhlciBwbGFjZXMgd2hlcmUgaG9va3MKc2hvdWxkIGdl dCBicm9rZW4gdXAsIG9yIGNvbWJpbmVkKi4gTXkgcXVlc3Rpb24gaXMganVzdCBob3cgaW1wb3J0 YW50CmlzIGl0IHRoYXQgdGhpcyBnZXRzIGNoYW5nZWQ/CgotLS0KKiBjYWxsaW5nIHNlY3VyaXR5 X2lub2RlX3NlY2lkKCkgYW5kIHRoZW4gaW1tZWRpYXRlbHkKICBzZWN1cml0eV9zZWNpZF90b19z ZWNjdHgoKSBncmF0ZXMgb24gbXkgc2Vuc2liaWxpdGllcy4KCgoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18Ka2V4ZWMgbWFpbGluZyBsaXN0CmtleGVjQGxp c3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9rZXhlYwo=