From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-3467994-1525400993-2-17293577505605412409 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no ("Email failed DMARC policy for domain") X-Spam-charsets: plain='UTF-8' X-IgnoreVacation: yes ("Email failed DMARC policy for domain") X-Resolved-to: linux@kroah.com X-Delivered-to: linux@kroah.com X-Mail-from: linux-security-module-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=fm2; t= 1525400993; b=l7jwOWfQYmZeCHsDQv/5AdzuspRU+BgMX37GivDmuzy1JaeDwO Zzv9eymSgrxUIZuDropDIhKyQQ1Kyk6cAFkiG9rQwsBWXEaObCeAdS+viN14WFVx y+uMQtR2cksGJSGVbNmoBI1xOo+qJjDpUHcU1dZcgX74EGNdtUQbI7juY+e4uF/i Wm4rFCSbFXTAnZSreObtryyeb+OTnCuxdhplMyiZIpPiWCMaLVDjlftyR63muJYG ObXX71X7fiUZMDqvi2mIUOIWtaAaDHP2jX9sLNJvWIyKvWIVURUvA/VAoizNpOQp quBMQ3hX5QYiiEzadNqEHGfX4GSIRT07LRQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding :message-id:sender:list-id; s=fm2; t=1525400993; bh=ehyoViVmalOw u4GLbuFylWLDuwvEGqgU0T23ofjuLYE=; b=lTrZELcKp2XfH6A9VErqmSiomax0 BYCfc3G19Oask0vPRTLIRuh51QDWIMF3JZrBXEvfMkRA67kJ45HCRi0x//ROvM06 Hbmb6DgQAUeqro5+bX3TGTlr0JwApWxnHJCaVAWXPxtDGxpNGbkatwbjQbjKpITi 6hgr9k0u3X6DC5xoETz1DWypgYOP30nAqxZyUG9bgJ2M1mpPYxXSz+kgvNQWkSC+ t4Sv3WF9gaU06QgSuVU5xzuDs39NgAtC2XOzGgMcoubgpQ7OHsh9EIzsjn+UkSh3 4xLYKwz0K5PuLjSBDR7Ge0gczczA0nwFD3JWRvQSS72M1Y00Dq6Rwo8kaw== ARC-Authentication-Results: i=1; mx1.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=fail (p=none,has-list-id=yes,d=none) header.from=linux.vnet.ibm.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-security-module-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-cm=none score=0; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=linux.vnet.ibm.com header.result=pass header_org.domain=ibm.com header_org.result=pass header_is_org_domain=no; x-vs=clean score=-100 state=0 Authentication-Results: mx1.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=fail (p=none,has-list-id=yes,d=none) header.from=linux.vnet.ibm.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-security-module-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-cm=none score=0; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=linux.vnet.ibm.com header.result=pass header_org.domain=ibm.com header_org.result=pass header_is_org_domain=no; x-vs=clean score=-100 state=0 X-ME-VSCategory: clean X-CM-Envelope: MS4wfE3xkPX0owPRauPzbFSAEyplum8rgrfkR2DPV88cEVoPC60JbVFGTUfkYdC/MwheZVgzGGYopiD6n/uioMKk2TnJGvz1VEr351ZhSXRmYbNRFROvG7Al 7mz5I82wiWPkHl4bH4evqtChB0JZiEhXGi9EvSvKoClB9kCAqhCCgWROesYHgf1Vdq/MvZ/bMnG+XKe/o0r944pPwVZTu1o7Ct8iEkEDw0s5lKJilFN5MEwF BuQqz+Cn1Ei08ZM6IdWasg== X-CM-Analysis: v=2.3 cv=WaUilXpX c=1 sm=1 tr=0 a=UK1r566ZdBxH71SXbqIOeA==:117 a=UK1r566ZdBxH71SXbqIOeA==:17 a=IkcTkHD0fZMA:10 a=VUJBJC2UJ8kA:10 a=VnNF1IyMAAAA:8 a=VwQbUJbxAAAA:8 a=2xhMSbFQTtTxrfdvk3kA:9 a=9yt3iPXVMMyElQPM:21 a=ifY9Sr3a1q6qj8k9:21 a=QEXdDO2ut3YA:10 a=x8gzFH9gYPwA:10 a=AjGcO6oz07-iQ99wixmX:22 X-ME-CMScore: 0 X-ME-CMCategory: none Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751240AbeEDC3s (ORCPT ); Thu, 3 May 2018 22:29:48 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:37948 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751236AbeEDC3r (ORCPT ); Thu, 3 May 2018 22:29:47 -0400 Subject: Re: [PATCH 0/3] kexec: limit kexec_load syscall From: Mimi Zohar To: "Eric W. Biederman" Cc: Kees Cook , David Howells , Matthew Garrett , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Date: Thu, 03 May 2018 22:29:37 -0400 In-Reply-To: <87fu38jq98.fsf@xmission.com> References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <87r2mso5up.fsf@xmission.com> <1525383075.3539.67.camel@linux.vnet.ibm.com> <87d0yco1vy.fsf@xmission.com> <1525384675.3539.89.camel@linux.vnet.ibm.com> <87fu38jq98.fsf@xmission.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18050402-0008-0000-0000-000004F2C83F X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18050402-0009-0000-0000-00001E86F269 Message-Id: <1525400977.3539.199.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-03_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805040020 Sender: owner-linux-security-module@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu, 2018-05-03 at 18:03 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Thu, 2018-05-03 at 16:38 -0500, Eric W. Biederman wrote: > >> Mimi Zohar writes: > >> > >> > [Cc'ing Kees and kernel-hardening] > >> > > >> > On Thu, 2018-05-03 at 15:13 -0500, Eric W. Biederman wrote: > >> >> Mimi Zohar writes: > >> >> > >> >> > In environments that require the kexec kernel image to be signed, prevent > >> >> > using the kexec_load syscall. In order for LSMs and IMA to differentiate > >> >> > between kexec_load and kexec_file_load syscalls, this patch set adds a > >> >> > call to security_kernel_read_file() in kexec_load_check(). > >> >> > >> >> Having thought about it some more this justification for these changes > >> >> does not work. The functionality of kexec_load is already root-only. > >> >> So in environments that require the kernel image to be signed just don't > >> >> use kexec_load. Possibly even compile kexec_load out to save space > >> >> because you will never need it. You don't need a new security hook to > >> >> do any of that. Userspace is a very fine mechanism for being the > >> >> instrument of policy. > >> > > >> > True, for those building their own kernel, they can disable the old > >> > syscalls.  The concern is not for those building their own kernels, > >> > but for those using stock kernels.   > >> > > >> > By adding an LSM hook here in the kexec_load syscall, as opposed to an > >> > IMA specific hook, other LSMs can piggy back on top of it.  Currently, > >> > both load_pin and SELinux are gating the kernel module syscalls based > >> > on security_kernel_read_file. > >> > > >> > If there was a similar option for the kernel image, I'm pretty sure > >> > other LSMs would use it. > >> > > >> > From an IMA perspective, there needs to be some method for only > >> > allowing signed code to be loaded, executed, etc. - kernel modules, > >> > kernel image/initramfs, firmware, policies. > >> > >> What is the IMA perspective. Why can't IMA trust appropriately > >> authorized userspace? > > > > Suppose a system owner wants to define a system wide policy that > > requires all code be signed - kernel modules, firmware, kexec image & > > initramfs, executables, mmapped files, etc - without having to rebuild > > the kernel.  Without a call in kexec_load that isn't possible. > > Of course it is. You just make it a requirement that before an > executable will be signed it will be audited to see that it doesn't > call sys_kexec_load. Signing presumably means something. So it should > not be hard to enforce a policy like that on a specialty system call > that most applications will never call. Initially I'm hoping that files will simply come signed, providing file provenance.  Anything else is gravy. > >> >> If you don't trust userspace that needs to be spelled out very clearly. > >> >> You need to talk about what your threat models are. > >> >> > >> >> If the only justification is so that that we can't boot windows if > >> >> someone hacks into userspace it has my nack because that is another kind > >> >> of complete non-sense. > >> > > >> > The usecase is the ability to gate the kexec_load usage in stock > >> > kernels. > >> > >> But kexec_load is already gated. It requires CAP_SYS_BOOT. > > > > It isn't a matter of kexec_load already being gated, but of wanting a > > single place for defining a system wide policy, as described above. > > Signing is only a tool to enforce a policy. Signing by itself is not a > policy. Enforcing any quality controls in the signed executables should > trivially prevent kexec_load from being used. Existing kernels might not support the newer kexec_file_load syscall, so packages are currently being built to try one syscall and fallback to using the other one.  In this case, it has nothing to do with quality control. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Thu, 03 May 2018 22:29:37 -0400 Subject: [PATCH 0/3] kexec: limit kexec_load syscall In-Reply-To: <87fu38jq98.fsf@xmission.com> References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <87r2mso5up.fsf@xmission.com> <1525383075.3539.67.camel@linux.vnet.ibm.com> <87d0yco1vy.fsf@xmission.com> <1525384675.3539.89.camel@linux.vnet.ibm.com> <87fu38jq98.fsf@xmission.com> Message-ID: <1525400977.3539.199.camel@linux.vnet.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Thu, 2018-05-03 at 18:03 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Thu, 2018-05-03 at 16:38 -0500, Eric W. Biederman wrote: > >> Mimi Zohar writes: > >> > >> > [Cc'ing Kees and kernel-hardening] > >> > > >> > On Thu, 2018-05-03 at 15:13 -0500, Eric W. Biederman wrote: > >> >> Mimi Zohar writes: > >> >> > >> >> > In environments that require the kexec kernel image to be signed, prevent > >> >> > using the kexec_load syscall. In order for LSMs and IMA to differentiate > >> >> > between kexec_load and kexec_file_load syscalls, this patch set adds a > >> >> > call to security_kernel_read_file() in kexec_load_check(). > >> >> > >> >> Having thought about it some more this justification for these changes > >> >> does not work. The functionality of kexec_load is already root-only. > >> >> So in environments that require the kernel image to be signed just don't > >> >> use kexec_load. Possibly even compile kexec_load out to save space > >> >> because you will never need it. You don't need a new security hook to > >> >> do any of that. Userspace is a very fine mechanism for being the > >> >> instrument of policy. > >> > > >> > True, for those building their own kernel, they can disable the old > >> > syscalls. ?The concern is not for those building their own kernels, > >> > but for those using stock kernels. ? > >> > > >> > By adding an LSM hook here in the kexec_load syscall, as opposed to an > >> > IMA specific hook, other LSMs can piggy back on top of it. ?Currently, > >> > both load_pin and SELinux are gating the kernel module syscalls based > >> > on security_kernel_read_file. > >> > > >> > If there was a similar option for the kernel image, I'm pretty sure > >> > other LSMs would use it. > >> > > >> > From an IMA perspective, there needs to be some method for only > >> > allowing signed code to be loaded, executed, etc. - kernel modules, > >> > kernel image/initramfs, firmware, policies. > >> > >> What is the IMA perspective. Why can't IMA trust appropriately > >> authorized userspace? > > > > Suppose a system owner wants to define a system wide policy that > > requires all code be signed - kernel modules, firmware, kexec image & > > initramfs, executables, mmapped files, etc - without having to rebuild > > the kernel. ?Without a call in kexec_load that isn't possible. > > Of course it is. You just make it a requirement that before an > executable will be signed it will be audited to see that it doesn't > call sys_kexec_load. Signing presumably means something. So it should > not be hard to enforce a policy like that on a specialty system call > that most applications will never call. Initially I'm hoping that files will simply come signed, providing file provenance. ?Anything else is gravy. > >> >> If you don't trust userspace that needs to be spelled out very clearly. > >> >> You need to talk about what your threat models are. > >> >> > >> >> If the only justification is so that that we can't boot windows if > >> >> someone hacks into userspace it has my nack because that is another kind > >> >> of complete non-sense. > >> > > >> > The usecase is the ability to gate the kexec_load usage in stock > >> > kernels. > >> > >> But kexec_load is already gated. It requires CAP_SYS_BOOT. > > > > It isn't a matter of kexec_load already being gated, but of wanting a > > single place for defining a system wide policy, as described above. > > Signing is only a tool to enforce a policy. Signing by itself is not a > policy. Enforcing any quality controls in the signed executables should > trivially prevent kexec_load from being used. Existing kernels might not support the newer kexec_file_load syscall, so packages are currently being built to try one syscall and fallback to using the other one. ?In this case, it has nothing to do with quality control. Mimi -- 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 mx0b-001b2d01.pphosted.com ([148.163.158.5]:47160 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751229AbeEDC3q (ORCPT ); Thu, 3 May 2018 22:29:46 -0400 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w442Tfd8062410 for ; Thu, 3 May 2018 22:29:46 -0400 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0b-001b2d01.pphosted.com with ESMTP id 2hrb9fpbmy-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 03 May 2018 22:29:46 -0400 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 May 2018 03:29:44 +0100 Subject: Re: [PATCH 0/3] kexec: limit kexec_load syscall From: Mimi Zohar To: "Eric W. Biederman" Cc: Kees Cook , David Howells , Matthew Garrett , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Date: Thu, 03 May 2018 22:29:37 -0400 In-Reply-To: <87fu38jq98.fsf@xmission.com> References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <87r2mso5up.fsf@xmission.com> <1525383075.3539.67.camel@linux.vnet.ibm.com> <87d0yco1vy.fsf@xmission.com> <1525384675.3539.89.camel@linux.vnet.ibm.com> <87fu38jq98.fsf@xmission.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1525400977.3539.199.camel@linux.vnet.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Thu, 2018-05-03 at 18:03 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Thu, 2018-05-03 at 16:38 -0500, Eric W. Biederman wrote: > >> Mimi Zohar writes: > >> > >> > [Cc'ing Kees and kernel-hardening] > >> > > >> > On Thu, 2018-05-03 at 15:13 -0500, Eric W. Biederman wrote: > >> >> Mimi Zohar writes: > >> >> > >> >> > In environments that require the kexec kernel image to be signed, prevent > >> >> > using the kexec_load syscall. In order for LSMs and IMA to differentiate > >> >> > between kexec_load and kexec_file_load syscalls, this patch set adds a > >> >> > call to security_kernel_read_file() in kexec_load_check(). > >> >> > >> >> Having thought about it some more this justification for these changes > >> >> does not work. The functionality of kexec_load is already root-only. > >> >> So in environments that require the kernel image to be signed just don't > >> >> use kexec_load. Possibly even compile kexec_load out to save space > >> >> because you will never need it. You don't need a new security hook to > >> >> do any of that. Userspace is a very fine mechanism for being the > >> >> instrument of policy. > >> > > >> > True, for those building their own kernel, they can disable the old > >> > syscalls. The concern is not for those building their own kernels, > >> > but for those using stock kernels. > >> > > >> > By adding an LSM hook here in the kexec_load syscall, as opposed to an > >> > IMA specific hook, other LSMs can piggy back on top of it. Currently, > >> > both load_pin and SELinux are gating the kernel module syscalls based > >> > on security_kernel_read_file. > >> > > >> > If there was a similar option for the kernel image, I'm pretty sure > >> > other LSMs would use it. > >> > > >> > From an IMA perspective, there needs to be some method for only > >> > allowing signed code to be loaded, executed, etc. - kernel modules, > >> > kernel image/initramfs, firmware, policies. > >> > >> What is the IMA perspective. Why can't IMA trust appropriately > >> authorized userspace? > > > > Suppose a system owner wants to define a system wide policy that > > requires all code be signed - kernel modules, firmware, kexec image & > > initramfs, executables, mmapped files, etc - without having to rebuild > > the kernel. Without a call in kexec_load that isn't possible. > > Of course it is. You just make it a requirement that before an > executable will be signed it will be audited to see that it doesn't > call sys_kexec_load. Signing presumably means something. So it should > not be hard to enforce a policy like that on a specialty system call > that most applications will never call. Initially I'm hoping that files will simply come signed, providing file provenance. Anything else is gravy. > >> >> If you don't trust userspace that needs to be spelled out very clearly. > >> >> You need to talk about what your threat models are. > >> >> > >> >> If the only justification is so that that we can't boot windows if > >> >> someone hacks into userspace it has my nack because that is another kind > >> >> of complete non-sense. > >> > > >> > The usecase is the ability to gate the kexec_load usage in stock > >> > kernels. > >> > >> But kexec_load is already gated. It requires CAP_SYS_BOOT. > > > > It isn't a matter of kexec_load already being gated, but of wanting a > > single place for defining a system wide policy, as described above. > > Signing is only a tool to enforce a policy. Signing by itself is not a > policy. Enforcing any quality controls in the signed executables should > trivially prevent kexec_load from being used. Existing kernels might not support the newer kexec_file_load syscall, so packages are currently being built to try one syscall and fallback to using the other one. In this case, it has nothing to do with quality control. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5] helo=mx0a-001b2d01.pphosted.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fEQTt-00052w-Bi for kexec@lists.infradead.org; Fri, 04 May 2018 02:29:58 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w442OBDr177227 for ; Thu, 3 May 2018 22:29:46 -0400 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0b-001b2d01.pphosted.com with ESMTP id 2hr8xjkcdf-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 03 May 2018 22:29:46 -0400 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 May 2018 03:29:44 +0100 Subject: Re: [PATCH 0/3] kexec: limit kexec_load syscall From: Mimi Zohar Date: Thu, 03 May 2018 22:29:37 -0400 In-Reply-To: <87fu38jq98.fsf@xmission.com> References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <87r2mso5up.fsf@xmission.com> <1525383075.3539.67.camel@linux.vnet.ibm.com> <87d0yco1vy.fsf@xmission.com> <1525384675.3539.89.camel@linux.vnet.ibm.com> <87fu38jq98.fsf@xmission.com> Mime-Version: 1.0 Message-Id: <1525400977.3539.199.camel@linux.vnet.ibm.com> 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: "Eric W. Biederman" Cc: Kees Cook , kernel-hardening@lists.openwall.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Matthew Garrett , David Howells , linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org T24gVGh1LCAyMDE4LTA1LTAzIGF0IDE4OjAzIC0wNTAwLCBFcmljIFcuIEJpZWRlcm1hbiB3cm90 ZToKPiBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC52bmV0LmlibS5jb20+IHdyaXRlczoKPiAKPiA+ IE9uIFRodSwgMjAxOC0wNS0wMyBhdCAxNjozOCAtMDUwMCwgRXJpYyBXLiBCaWVkZXJtYW4gd3Jv dGU6Cj4gPj4gTWltaSBab2hhciA8em9oYXJAbGludXgudm5ldC5pYm0uY29tPiB3cml0ZXM6Cj4g Pj4gCj4gPj4gPiBbQ2MnaW5nIEtlZXMgYW5kIGtlcm5lbC1oYXJkZW5pbmddCj4gPj4gPgo+ID4+ ID4gT24gVGh1LCAyMDE4LTA1LTAzIGF0IDE1OjEzIC0wNTAwLCBFcmljIFcuIEJpZWRlcm1hbiB3 cm90ZToKPiA+PiA+PiBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC52bmV0LmlibS5jb20+IHdyaXRl czoKPiA+PiA+PiAKPiA+PiA+PiA+IEluIGVudmlyb25tZW50cyB0aGF0IHJlcXVpcmUgdGhlIGtl eGVjIGtlcm5lbCBpbWFnZSB0byBiZSBzaWduZWQsIHByZXZlbnQKPiA+PiA+PiA+IHVzaW5nIHRo ZSBrZXhlY19sb2FkIHN5c2NhbGwuICBJbiBvcmRlciBmb3IgTFNNcyBhbmQgSU1BIHRvIGRpZmZl cmVudGlhdGUKPiA+PiA+PiA+IGJldHdlZW4ga2V4ZWNfbG9hZCBhbmQga2V4ZWNfZmlsZV9sb2Fk IHN5c2NhbGxzLCB0aGlzIHBhdGNoIHNldCBhZGRzIGEKPiA+PiA+PiA+IGNhbGwgdG8gc2VjdXJp dHlfa2VybmVsX3JlYWRfZmlsZSgpIGluIGtleGVjX2xvYWRfY2hlY2soKS4KPiA+PiA+PiAKPiA+ PiA+PiBIYXZpbmcgdGhvdWdodCBhYm91dCBpdCBzb21lIG1vcmUgdGhpcyBqdXN0aWZpY2F0aW9u IGZvciB0aGVzZSBjaGFuZ2VzCj4gPj4gPj4gZG9lcyBub3Qgd29yay4gIFRoZSBmdW5jdGlvbmFs aXR5IG9mIGtleGVjX2xvYWQgaXMgYWxyZWFkeSByb290LW9ubHkuCj4gPj4gPj4gU28gaW4gZW52 aXJvbm1lbnRzIHRoYXQgcmVxdWlyZSB0aGUga2VybmVsIGltYWdlIHRvIGJlIHNpZ25lZCBqdXN0 IGRvbid0Cj4gPj4gPj4gdXNlIGtleGVjX2xvYWQuICBQb3NzaWJseSBldmVuIGNvbXBpbGUga2V4 ZWNfbG9hZCBvdXQgdG8gc2F2ZSBzcGFjZQo+ID4+ID4+IGJlY2F1c2UgeW91IHdpbGwgbmV2ZXIg bmVlZCBpdC4gIFlvdSBkb24ndCBuZWVkIGEgbmV3IHNlY3VyaXR5IGhvb2sgdG8KPiA+PiA+PiBk byBhbnkgb2YgdGhhdC4gIFVzZXJzcGFjZSBpcyBhIHZlcnkgZmluZSBtZWNoYW5pc20gZm9yIGJl aW5nIHRoZQo+ID4+ID4+IGluc3RydW1lbnQgb2YgcG9saWN5Lgo+ID4+ID4KPiA+PiA+IFRydWUs IGZvciB0aG9zZSBidWlsZGluZyB0aGVpciBvd24ga2VybmVsLCB0aGV5IGNhbiBkaXNhYmxlIHRo ZSBvbGQKPiA+PiA+IHN5c2NhbGxzLiDCoFRoZSBjb25jZXJuIGlzIG5vdCBmb3IgdGhvc2UgYnVp bGRpbmcgdGhlaXIgb3duIGtlcm5lbHMsCj4gPj4gPiBidXQgZm9yIHRob3NlIHVzaW5nIHN0b2Nr IGtlcm5lbHMuIMKgCj4gPj4gPgo+ID4+ID4gQnkgYWRkaW5nIGFuIExTTSBob29rIGhlcmUgaW4g dGhlIGtleGVjX2xvYWQgc3lzY2FsbCwgYXMgb3Bwb3NlZCB0byBhbgo+ID4+ID4gSU1BIHNwZWNp ZmljIGhvb2ssIG90aGVyIExTTXMgY2FuIHBpZ2d5IGJhY2sgb24gdG9wIG9mIGl0LiDCoEN1cnJl bnRseSwKPiA+PiA+IGJvdGggbG9hZF9waW4gYW5kIFNFTGludXggYXJlIGdhdGluZyB0aGUga2Vy bmVsIG1vZHVsZSBzeXNjYWxscyBiYXNlZAo+ID4+ID4gb24gc2VjdXJpdHlfa2VybmVsX3JlYWRf ZmlsZS4KPiA+PiA+Cj4gPj4gPiBJZiB0aGVyZSB3YXMgYSBzaW1pbGFyIG9wdGlvbiBmb3IgdGhl IGtlcm5lbCBpbWFnZSwgSSdtIHByZXR0eSBzdXJlCj4gPj4gPiBvdGhlciBMU01zIHdvdWxkIHVz ZSBpdC4KPiA+PiA+Cj4gPj4gPiBGcm9tIGFuIElNQSBwZXJzcGVjdGl2ZSwgdGhlcmUgbmVlZHMg dG8gYmUgc29tZSBtZXRob2QgZm9yIG9ubHkKPiA+PiA+IGFsbG93aW5nIHNpZ25lZCBjb2RlIHRv IGJlIGxvYWRlZCwgZXhlY3V0ZWQsIGV0Yy4gLSBrZXJuZWwgbW9kdWxlcywKPiA+PiA+IGtlcm5l bCBpbWFnZS9pbml0cmFtZnMsIGZpcm13YXJlLCBwb2xpY2llcy4KPiA+PiAKPiA+PiBXaGF0IGlz IHRoZSBJTUEgcGVyc3BlY3RpdmUuICBXaHkgY2FuJ3QgSU1BIHRydXN0IGFwcHJvcHJpYXRlbHkK PiA+PiBhdXRob3JpemVkIHVzZXJzcGFjZT8KPiA+Cj4gPiBTdXBwb3NlIGEgc3lzdGVtIG93bmVy IHdhbnRzIHRvIGRlZmluZSBhIHN5c3RlbSB3aWRlIHBvbGljeSB0aGF0Cj4gPiByZXF1aXJlcyBh bGwgY29kZSBiZSBzaWduZWQgLSBrZXJuZWwgbW9kdWxlcywgZmlybXdhcmUsIGtleGVjIGltYWdl ICYKPiA+IGluaXRyYW1mcywgZXhlY3V0YWJsZXMsIG1tYXBwZWQgZmlsZXMsIGV0YyAtIHdpdGhv dXQgaGF2aW5nIHRvIHJlYnVpbGQKPiA+IHRoZSBrZXJuZWwuIMKgV2l0aG91dCBhIGNhbGwgaW4g a2V4ZWNfbG9hZCB0aGF0IGlzbid0IHBvc3NpYmxlLgo+IAo+IE9mIGNvdXJzZSBpdCBpcy4gIFlv dSBqdXN0IG1ha2UgaXQgYSByZXF1aXJlbWVudCB0aGF0IGJlZm9yZSBhbgo+IGV4ZWN1dGFibGUg d2lsbCBiZSBzaWduZWQgaXQgd2lsbCBiZSBhdWRpdGVkIHRvIHNlZSB0aGF0IGl0IGRvZXNuJ3QK PiBjYWxsIHN5c19rZXhlY19sb2FkLiAgU2lnbmluZyBwcmVzdW1hYmx5IG1lYW5zIHNvbWV0aGlu Zy4gIFNvIGl0IHNob3VsZAo+IG5vdCBiZSBoYXJkIHRvIGVuZm9yY2UgYSBwb2xpY3kgbGlrZSB0 aGF0IG9uIGEgc3BlY2lhbHR5IHN5c3RlbSBjYWxsCj4gdGhhdCBtb3N0IGFwcGxpY2F0aW9ucyB3 aWxsIG5ldmVyIGNhbGwuCgpJbml0aWFsbHkgSSdtIGhvcGluZyB0aGF0IGZpbGVzIHdpbGwgc2lt cGx5IGNvbWUgc2lnbmVkLCBwcm92aWRpbmcKZmlsZSBwcm92ZW5hbmNlLiDCoEFueXRoaW5nIGVs c2UgaXMgZ3JhdnkuCgo+ID4+ID4+IElmIHlvdSBkb24ndCB0cnVzdCB1c2Vyc3BhY2UgdGhhdCBu ZWVkcyB0byBiZSBzcGVsbGVkIG91dCB2ZXJ5IGNsZWFybHkuCj4gPj4gPj4gWW91IG5lZWQgdG8g dGFsayBhYm91dCB3aGF0IHlvdXIgdGhyZWF0IG1vZGVscyBhcmUuCj4gPj4gPj4gCj4gPj4gPj4g SWYgdGhlIG9ubHkganVzdGlmaWNhdGlvbiBpcyBzbyB0aGF0IHRoYXQgd2UgY2FuJ3QgYm9vdCB3 aW5kb3dzIGlmCj4gPj4gPj4gc29tZW9uZSBoYWNrcyBpbnRvIHVzZXJzcGFjZSBpdCBoYXMgbXkg bmFjayBiZWNhdXNlIHRoYXQgaXMgYW5vdGhlciBraW5kCj4gPj4gPj4gb2YgY29tcGxldGUgbm9u LXNlbnNlLgo+ID4+ID4KPiA+PiA+IFRoZSB1c2VjYXNlIGlzIHRoZSBhYmlsaXR5IHRvIGdhdGUg dGhlIGtleGVjX2xvYWQgdXNhZ2UgaW4gc3RvY2sKPiA+PiA+IGtlcm5lbHMuCj4gPj4gCj4gPj4g QnV0IGtleGVjX2xvYWQgaXMgYWxyZWFkeSBnYXRlZC4gIEl0IHJlcXVpcmVzIENBUF9TWVNfQk9P VC4KPiA+Cj4gPiBJdCBpc24ndCBhIG1hdHRlciBvZiBrZXhlY19sb2FkIGFscmVhZHkgYmVpbmcg Z2F0ZWQsIGJ1dCBvZiB3YW50aW5nIGEKPiA+IHNpbmdsZSBwbGFjZSBmb3IgZGVmaW5pbmcgYSBz eXN0ZW0gd2lkZSBwb2xpY3ksIGFzIGRlc2NyaWJlZCBhYm92ZS4KPiAKPiBTaWduaW5nIGlzIG9u bHkgYSB0b29sIHRvIGVuZm9yY2UgYSBwb2xpY3kuICBTaWduaW5nIGJ5IGl0c2VsZiBpcyBub3Qg YQo+IHBvbGljeS4gIEVuZm9yY2luZyBhbnkgcXVhbGl0eSBjb250cm9scyBpbiB0aGUgc2lnbmVk IGV4ZWN1dGFibGVzIHNob3VsZAo+IHRyaXZpYWxseSBwcmV2ZW50IGtleGVjX2xvYWQgZnJvbSBi ZWluZyB1c2VkLgoKRXhpc3Rpbmcga2VybmVscyBtaWdodCBub3Qgc3VwcG9ydCB0aGUgbmV3ZXIg a2V4ZWNfZmlsZV9sb2FkIHN5c2NhbGwsCnNvIHBhY2thZ2VzIGFyZSBjdXJyZW50bHkgYmVpbmcg YnVpbHQgdG8gdHJ5IG9uZSBzeXNjYWxsIGFuZCBmYWxsYmFjawp0byB1c2luZyB0aGUgb3RoZXIg b25lLiDCoEluIHRoaXMgY2FzZSwgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aApxdWFsaXR5IGNv bnRyb2wuCgpNaW1pCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18Ka2V4ZWMgbWFpbGluZyBsaXN0CmtleGVjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDov L2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9rZXhlYwo=