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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C89FEC5CFEB for ; Mon, 9 Jul 2018 19:41:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8F44820870 for ; Mon, 9 Jul 2018 19:41:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F44820870 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933012AbeGITlq (ORCPT ); Mon, 9 Jul 2018 15:41:46 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:34302 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932827AbeGITlo (ORCPT ); Mon, 9 Jul 2018 15:41:44 -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 w69JdLCY019456 for ; Mon, 9 Jul 2018 15:41:43 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0b-001b2d01.pphosted.com with ESMTP id 2k4c88err5-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 09 Jul 2018 15:41:43 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Jul 2018 20:41:41 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 9 Jul 2018 20:41:37 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w69JfaA643122784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 9 Jul 2018 19:41:36 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9B3254C044; Mon, 9 Jul 2018 22:41:59 +0100 (BST) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 074854C046; Mon, 9 Jul 2018 22:41:58 +0100 (BST) Received: from dhcp-9-31-103-18.watson.ibm.com (unknown [9.31.103.18]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 9 Jul 2018 22:41:57 +0100 (BST) Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) From: Mimi Zohar To: Ard Biesheuvel , Mimi Zohar Cc: linux-integrity , linux-security-module , Linux Kernel Mailing List , David Howells , "Luis R . Rodriguez" , Eric Biederman , Kexec Mailing List , Andres Rodriguez , Greg Kroah-Hartman , "Luis R . Rodriguez" , Kees Cook , "Serge E . Hallyn" , Stephen Boyd , Bjorn Andersson Date: Mon, 09 Jul 2018 15:41:34 -0400 In-Reply-To: References: <1530542283-26145-1-git-send-email-zohar@linux.vnet.ibm.com> <1530542283-26145-8-git-send-email-zohar@linux.vnet.ibm.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: 18070919-0028-0000-0000-000002D9CA4F X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18070919-0029-0000-0000-0000239167C8 Message-Id: <1531165294.3332.40.camel@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-09_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=3 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-1807090222 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-07-02 at 17:30 +0200, Ard Biesheuvel wrote: > On 2 July 2018 at 16:38, Mimi Zohar wrote: > > Some systems are memory constrained but they need to load very large > > firmwares. The firmware subsystem allows drivers to request this > > firmware be loaded from the filesystem, but this requires that the > > entire firmware be loaded into kernel memory first before it's provided > > to the driver. This can lead to a situation where we map the firmware > > twice, once to load the firmware into kernel memory and once to copy the > > firmware into the final resting place. > > > > To resolve this problem, commit a098ecd2fa7d ("firmware: support loading > > into a pre-allocated buffer") introduced request_firmware_into_buf() API > > that allows drivers to request firmware be loaded directly into a > > pre-allocated buffer. (Based on the mailing list discussions, calling > > dma_alloc_coherent() is unnecessary and confusing.) > > > > (Very broken/buggy) devices using pre-allocated memory run the risk of > > the firmware being accessible to the device prior to the completion of > > IMA's signature verification. For the time being, this patch emits a > > warning, but does not prevent the loading of the firmware. > > > > As I attempted to explain in the exchange with Luis, this has nothing > to do with broken or buggy devices, but is simply the reality we have > to deal with on platforms that lack IOMMUs. > Even if you load into one buffer, carry out the signature verification > and *only then* copy it to another buffer, a bus master could > potentially read it from the first buffer as well. Mapping for DMA > does *not* mean 'making the memory readable by the device' unless > IOMMUs are being used. Otherwise, a bus master can read it from the > first buffer, or even patch the code that performs the security check > in the first place. For such platforms, copying the data around to > prevent the device from reading it is simply pointless, as well as any > other mitigation in software to protect yourself from misbehaving bus > masters. Thank you for taking the time to explain this again. > So issuing a warning in this particular case is rather arbitrary. On > these platforms, all bus masters can read (and modify) all of your > memory all of the time, and as long as the firmware loader code takes > care not to provide the DMA address to the device until after the > verification is complete, it really has done all it reasonably can in > the environment that it is expected to operate in. So for the non-IOMMU system case, differentiating between pre- allocated buffers vs. using two buffers doesn't make sense. > > (The use of dma_alloc_coherent() is a bit of a red herring here, as it > incorporates the DMA map operation. However, DMA map is a no-op on > systems with cache coherent 1:1 DMA [iow, all PCs and most arm64 > platforms unless they have IOMMUs], and so there is not much > difference between memory allocated with kmalloc() or with > dma_alloc_coherent() in terms of whether the device can access it > freely)   What about systems with an IOMMU? Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.ibm.com (Mimi Zohar) Date: Mon, 09 Jul 2018 15:41:34 -0400 Subject: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) In-Reply-To: References: <1530542283-26145-1-git-send-email-zohar@linux.vnet.ibm.com> <1530542283-26145-8-git-send-email-zohar@linux.vnet.ibm.com> Message-ID: <1531165294.3332.40.camel@linux.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Mon, 2018-07-02 at 17:30 +0200, Ard Biesheuvel wrote: > On 2 July 2018 at 16:38, Mimi Zohar wrote: > > Some systems are memory constrained but they need to load very large > > firmwares. The firmware subsystem allows drivers to request this > > firmware be loaded from the filesystem, but this requires that the > > entire firmware be loaded into kernel memory first before it's provided > > to the driver. This can lead to a situation where we map the firmware > > twice, once to load the firmware into kernel memory and once to copy the > > firmware into the final resting place. > > > > To resolve this problem, commit a098ecd2fa7d ("firmware: support loading > > into a pre-allocated buffer") introduced request_firmware_into_buf() API > > that allows drivers to request firmware be loaded directly into a > > pre-allocated buffer. (Based on the mailing list discussions, calling > > dma_alloc_coherent() is unnecessary and confusing.) > > > > (Very broken/buggy) devices using pre-allocated memory run the risk of > > the firmware being accessible to the device prior to the completion of > > IMA's signature verification. For the time being, this patch emits a > > warning, but does not prevent the loading of the firmware. > > > > As I attempted to explain in the exchange with Luis, this has nothing > to do with broken or buggy devices, but is simply the reality we have > to deal with on platforms that lack IOMMUs. > Even if you load into one buffer, carry out the signature verification > and *only then* copy it to another buffer, a bus master could > potentially read it from the first buffer as well. Mapping for DMA > does *not* mean 'making the memory readable by the device' unless > IOMMUs are being used. Otherwise, a bus master can read it from the > first buffer, or even patch the code that performs the security check > in the first place. For such platforms, copying the data around to > prevent the device from reading it is simply pointless, as well as any > other mitigation in software to protect yourself from misbehaving bus > masters. Thank you for taking the time to explain this again. > So issuing a warning in this particular case is rather arbitrary. On > these platforms, all bus masters can read (and modify) all of your > memory all of the time, and as long as the firmware loader code takes > care not to provide the DMA address to the device until after the > verification is complete, it really has done all it reasonably can in > the environment that it is expected to operate in. So for the non-IOMMU system case, differentiating between pre- allocated buffers vs. using two buffers doesn't make sense. > > (The use of dma_alloc_coherent() is a bit of a red herring here, as it > incorporates the DMA map operation. However, DMA map is a no-op on > systems with cache coherent 1:1 DMA [iow, all PCs and most arm64 > platforms unless they have IOMMUs], and so there is not much > difference between memory allocated with kmalloc() or with > dma_alloc_coherent() in terms of whether the device can access it > freely) ? What about systems with an IOMMU? 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]:53686 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932764AbeGITlo (ORCPT ); Mon, 9 Jul 2018 15:41:44 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w69JdL19087496 for ; Mon, 9 Jul 2018 15:41:43 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2k4d2pbqcn-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 09 Jul 2018 15:41:43 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Jul 2018 20:41:41 +0100 Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) From: Mimi Zohar To: Ard Biesheuvel , Mimi Zohar Cc: linux-integrity , linux-security-module , Linux Kernel Mailing List , David Howells , "Luis R . Rodriguez" , Eric Biederman , Kexec Mailing List , Andres Rodriguez , Greg Kroah-Hartman , "Luis R . Rodriguez" , Kees Cook , "Serge E . Hallyn" , Stephen Boyd , Bjorn Andersson Date: Mon, 09 Jul 2018 15:41:34 -0400 In-Reply-To: References: <1530542283-26145-1-git-send-email-zohar@linux.vnet.ibm.com> <1530542283-26145-8-git-send-email-zohar@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1531165294.3332.40.camel@linux.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Mon, 2018-07-02 at 17:30 +0200, Ard Biesheuvel wrote: > On 2 July 2018 at 16:38, Mimi Zohar wrote: > > Some systems are memory constrained but they need to load very large > > firmwares. The firmware subsystem allows drivers to request this > > firmware be loaded from the filesystem, but this requires that the > > entire firmware be loaded into kernel memory first before it's provided > > to the driver. This can lead to a situation where we map the firmware > > twice, once to load the firmware into kernel memory and once to copy the > > firmware into the final resting place. > > > > To resolve this problem, commit a098ecd2fa7d ("firmware: support loading > > into a pre-allocated buffer") introduced request_firmware_into_buf() API > > that allows drivers to request firmware be loaded directly into a > > pre-allocated buffer. (Based on the mailing list discussions, calling > > dma_alloc_coherent() is unnecessary and confusing.) > > > > (Very broken/buggy) devices using pre-allocated memory run the risk of > > the firmware being accessible to the device prior to the completion of > > IMA's signature verification. For the time being, this patch emits a > > warning, but does not prevent the loading of the firmware. > > > > As I attempted to explain in the exchange with Luis, this has nothing > to do with broken or buggy devices, but is simply the reality we have > to deal with on platforms that lack IOMMUs. > Even if you load into one buffer, carry out the signature verification > and *only then* copy it to another buffer, a bus master could > potentially read it from the first buffer as well. Mapping for DMA > does *not* mean 'making the memory readable by the device' unless > IOMMUs are being used. Otherwise, a bus master can read it from the > first buffer, or even patch the code that performs the security check > in the first place. For such platforms, copying the data around to > prevent the device from reading it is simply pointless, as well as any > other mitigation in software to protect yourself from misbehaving bus > masters. Thank you for taking the time to explain this again. > So issuing a warning in this particular case is rather arbitrary. On > these platforms, all bus masters can read (and modify) all of your > memory all of the time, and as long as the firmware loader code takes > care not to provide the DMA address to the device until after the > verification is complete, it really has done all it reasonably can in > the environment that it is expected to operate in. So for the non-IOMMU system case, differentiating between pre- allocated buffers vs. using two buffers doesn't make sense. > > (The use of dma_alloc_coherent() is a bit of a red herring here, as it > incorporates the DMA map operation. However, DMA map is a no-op on > systems with cache coherent 1:1 DMA [iow, all PCs and most arm64 > platforms unless they have IOMMUs], and so there is not much > difference between memory allocated with kmalloc() or with > dma_alloc_coherent() in terms of whether the device can access it > freely) What about systems with an IOMMU? 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 1fcc2m-0006YO-Kj for kexec@lists.infradead.org; Mon, 09 Jul 2018 19:41:58 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w69JdM2W087589 for ; Mon, 9 Jul 2018 15:41:43 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2k4d2pbqcm-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 09 Jul 2018 15:41:43 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Jul 2018 20:41:41 +0100 Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) From: Mimi Zohar Date: Mon, 09 Jul 2018 15:41:34 -0400 In-Reply-To: References: <1530542283-26145-1-git-send-email-zohar@linux.vnet.ibm.com> <1530542283-26145-8-git-send-email-zohar@linux.vnet.ibm.com> Mime-Version: 1.0 Message-Id: <1531165294.3332.40.camel@linux.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: Ard Biesheuvel , Mimi Zohar Cc: Kees Cook , Stephen Boyd , Greg Kroah-Hartman , "Luis R . Rodriguez" , Kexec Mailing List , linux-security-module , Linux Kernel Mailing List , David Howells , "Luis R . Rodriguez" , Bjorn Andersson , Eric Biederman , linux-integrity , "Serge E . Hallyn" , Andres Rodriguez T24gTW9uLCAyMDE4LTA3LTAyIGF0IDE3OjMwICswMjAwLCBBcmQgQmllc2hldXZlbCB3cm90ZToK PiBPbiAyIEp1bHkgMjAxOCBhdCAxNjozOCwgTWltaSBab2hhciA8em9oYXJAbGludXgudm5ldC5p Ym0uY29tPiB3cm90ZToKPiA+IFNvbWUgc3lzdGVtcyBhcmUgbWVtb3J5IGNvbnN0cmFpbmVkIGJ1 dCB0aGV5IG5lZWQgdG8gbG9hZCB2ZXJ5IGxhcmdlCj4gPiBmaXJtd2FyZXMuICBUaGUgZmlybXdh cmUgc3Vic3lzdGVtIGFsbG93cyBkcml2ZXJzIHRvIHJlcXVlc3QgdGhpcwo+ID4gZmlybXdhcmUg YmUgbG9hZGVkIGZyb20gdGhlIGZpbGVzeXN0ZW0sIGJ1dCB0aGlzIHJlcXVpcmVzIHRoYXQgdGhl Cj4gPiBlbnRpcmUgZmlybXdhcmUgYmUgbG9hZGVkIGludG8ga2VybmVsIG1lbW9yeSBmaXJzdCBi ZWZvcmUgaXQncyBwcm92aWRlZAo+ID4gdG8gdGhlIGRyaXZlci4gIFRoaXMgY2FuIGxlYWQgdG8g YSBzaXR1YXRpb24gd2hlcmUgd2UgbWFwIHRoZSBmaXJtd2FyZQo+ID4gdHdpY2UsIG9uY2UgdG8g bG9hZCB0aGUgZmlybXdhcmUgaW50byBrZXJuZWwgbWVtb3J5IGFuZCBvbmNlIHRvIGNvcHkgdGhl Cj4gPiBmaXJtd2FyZSBpbnRvIHRoZSBmaW5hbCByZXN0aW5nIHBsYWNlLgo+ID4KPiA+IFRvIHJl c29sdmUgdGhpcyBwcm9ibGVtLCBjb21taXQgYTA5OGVjZDJmYTdkICgiZmlybXdhcmU6IHN1cHBv cnQgbG9hZGluZwo+ID4gaW50byBhIHByZS1hbGxvY2F0ZWQgYnVmZmVyIikgaW50cm9kdWNlZCBy ZXF1ZXN0X2Zpcm13YXJlX2ludG9fYnVmKCkgQVBJCj4gPiB0aGF0IGFsbG93cyBkcml2ZXJzIHRv IHJlcXVlc3QgZmlybXdhcmUgYmUgbG9hZGVkIGRpcmVjdGx5IGludG8gYQo+ID4gcHJlLWFsbG9j YXRlZCBidWZmZXIuIChCYXNlZCBvbiB0aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zLCBjYWxs aW5nCj4gPiBkbWFfYWxsb2NfY29oZXJlbnQoKSBpcyB1bm5lY2Vzc2FyeSBhbmQgY29uZnVzaW5n LikKPiA+Cj4gPiAoVmVyeSBicm9rZW4vYnVnZ3kpIGRldmljZXMgdXNpbmcgcHJlLWFsbG9jYXRl ZCBtZW1vcnkgcnVuIHRoZSByaXNrIG9mCj4gPiB0aGUgZmlybXdhcmUgYmVpbmcgYWNjZXNzaWJs ZSB0byB0aGUgZGV2aWNlIHByaW9yIHRvIHRoZSBjb21wbGV0aW9uIG9mCj4gPiBJTUEncyBzaWdu YXR1cmUgdmVyaWZpY2F0aW9uLiAgRm9yIHRoZSB0aW1lIGJlaW5nLCB0aGlzIHBhdGNoIGVtaXRz IGEKPiA+IHdhcm5pbmcsIGJ1dCBkb2VzIG5vdCBwcmV2ZW50IHRoZSBsb2FkaW5nIG9mIHRoZSBm aXJtd2FyZS4KPiA+Cj4gCj4gQXMgSSBhdHRlbXB0ZWQgdG8gZXhwbGFpbiBpbiB0aGUgZXhjaGFu Z2Ugd2l0aCBMdWlzLCB0aGlzIGhhcyBub3RoaW5nCj4gdG8gZG8gd2l0aCBicm9rZW4gb3IgYnVn Z3kgZGV2aWNlcywgYnV0IGlzIHNpbXBseSB0aGUgcmVhbGl0eSB3ZSBoYXZlCj4gdG8gZGVhbCB3 aXRoIG9uIHBsYXRmb3JtcyB0aGF0IGxhY2sgSU9NTVVzLgoKPiBFdmVuIGlmIHlvdSBsb2FkIGlu dG8gb25lIGJ1ZmZlciwgY2Fycnkgb3V0IHRoZSBzaWduYXR1cmUgdmVyaWZpY2F0aW9uCj4gYW5k ICpvbmx5IHRoZW4qIGNvcHkgaXQgdG8gYW5vdGhlciBidWZmZXIsIGEgYnVzIG1hc3RlciBjb3Vs ZAo+IHBvdGVudGlhbGx5IHJlYWQgaXQgZnJvbSB0aGUgZmlyc3QgYnVmZmVyIGFzIHdlbGwuIE1h cHBpbmcgZm9yIERNQQo+IGRvZXMgKm5vdCogbWVhbiAnbWFraW5nIHRoZSBtZW1vcnkgcmVhZGFi bGUgYnkgdGhlIGRldmljZScgdW5sZXNzCj4gSU9NTVVzIGFyZSBiZWluZyB1c2VkLiBPdGhlcndp c2UsIGEgYnVzIG1hc3RlciBjYW4gcmVhZCBpdCBmcm9tIHRoZQo+IGZpcnN0IGJ1ZmZlciwgb3Ig ZXZlbiBwYXRjaCB0aGUgY29kZSB0aGF0IHBlcmZvcm1zIHRoZSBzZWN1cml0eSBjaGVjawo+IGlu IHRoZSBmaXJzdCBwbGFjZS4gRm9yIHN1Y2ggcGxhdGZvcm1zLCBjb3B5aW5nIHRoZSBkYXRhIGFy b3VuZCB0bwo+IHByZXZlbnQgdGhlIGRldmljZSBmcm9tIHJlYWRpbmcgaXQgaXMgc2ltcGx5IHBv aW50bGVzcywgYXMgd2VsbCBhcyBhbnkKPiBvdGhlciBtaXRpZ2F0aW9uIGluIHNvZnR3YXJlIHRv IHByb3RlY3QgeW91cnNlbGYgZnJvbSBtaXNiZWhhdmluZyBidXMKPiBtYXN0ZXJzLgoKVGhhbmsg eW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gZXhwbGFpbiB0aGlzIGFnYWluLgoKPiBTbyBpc3N1 aW5nIGEgd2FybmluZyBpbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSBpcyByYXRoZXIgYXJiaXRyYXJ5 LiBPbgo+IHRoZXNlIHBsYXRmb3JtcywgYWxsIGJ1cyBtYXN0ZXJzIGNhbiByZWFkIChhbmQgbW9k aWZ5KSBhbGwgb2YgeW91cgo+IG1lbW9yeSBhbGwgb2YgdGhlIHRpbWUsIGFuZCBhcyBsb25nIGFz IHRoZSBmaXJtd2FyZSBsb2FkZXIgY29kZSB0YWtlcwo+IGNhcmUgbm90IHRvIHByb3ZpZGUgdGhl IERNQSBhZGRyZXNzIHRvIHRoZSBkZXZpY2UgdW50aWwgYWZ0ZXIgdGhlCj4gdmVyaWZpY2F0aW9u IGlzIGNvbXBsZXRlLCBpdCByZWFsbHkgaGFzIGRvbmUgYWxsIGl0IHJlYXNvbmFibHkgY2FuIGlu Cj4gdGhlIGVudmlyb25tZW50IHRoYXQgaXQgaXMgZXhwZWN0ZWQgdG8gb3BlcmF0ZSBpbi4KClNv IGZvciB0aGUgbm9uLUlPTU1VIHN5c3RlbSBjYXNlLCBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBw cmUtCmFsbG9jYXRlZCBidWZmZXJzIHZzLiB1c2luZyB0d28gYnVmZmVycyBkb2Vzbid0IG1ha2Ug c2Vuc2UuCgo+IAo+IChUaGUgdXNlIG9mIGRtYV9hbGxvY19jb2hlcmVudCgpIGlzIGEgYml0IG9m IGEgcmVkIGhlcnJpbmcgaGVyZSwgYXMgaXQKPiBpbmNvcnBvcmF0ZXMgdGhlIERNQSBtYXAgb3Bl cmF0aW9uLiBIb3dldmVyLCBETUEgbWFwIGlzIGEgbm8tb3Agb24KPiBzeXN0ZW1zIHdpdGggY2Fj aGUgY29oZXJlbnQgMToxIERNQSBbaW93LCBhbGwgUENzIGFuZCBtb3N0IGFybTY0Cj4gcGxhdGZv cm1zIHVubGVzcyB0aGV5IGhhdmUgSU9NTVVzXSwgYW5kIHNvIHRoZXJlIGlzIG5vdCBtdWNoCj4g ZGlmZmVyZW5jZSBiZXR3ZWVuIG1lbW9yeSBhbGxvY2F0ZWQgd2l0aCBrbWFsbG9jKCkgb3Igd2l0 aAo+IGRtYV9hbGxvY19jb2hlcmVudCgpIGluIHRlcm1zIG9mIHdoZXRoZXIgdGhlIGRldmljZSBj YW4gYWNjZXNzIGl0Cj4gZnJlZWx5KQogwqAKV2hhdCBhYm91dCBzeXN0ZW1zIHdpdGggYW4gSU9N TVU/CgpNaW1pCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18Ka2V4ZWMgbWFpbGluZyBsaXN0CmtleGVjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xp c3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9rZXhlYwo=