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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no 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 E50BBC73C66 for ; Mon, 15 Jul 2019 03:06:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C39F3214C6 for ; Mon, 15 Jul 2019 03:06:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728971AbfGODGt (ORCPT ); Sun, 14 Jul 2019 23:06:49 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:59706 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726916AbfGODGt (ORCPT ); Sun, 14 Jul 2019 23:06:49 -0400 X-UUID: d5814ede6d58453e95a0b6c0fcd31521-20190715 X-UUID: d5814ede6d58453e95a0b6c0fcd31521-20190715 Received: from mtkexhb01.mediatek.inc [(172.21.101.102)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1205297470; Mon, 15 Jul 2019 11:06:42 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs07n1.mediatek.inc (172.21.101.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jul 2019 11:06:41 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 15 Jul 2019 11:06:40 +0800 Message-ID: <1563160001.4793.4.camel@mtksdccf07> Subject: Re: [PATCH v3] kasan: add memory corruption identification for software tag-based mode From: Walter Wu To: Andrey Ryabinin CC: Dmitry Vyukov , Alexander Potapenko , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Matthias Brugger , "Martin Schwidefsky" , Arnd Bergmann , "Vasily Gorbik" , Andrey Konovalov , "Jason A . Donenfeld" , Miles Chen , kasan-dev , LKML , Linux-MM , Linux ARM , , wsd_upstream Date: Mon, 15 Jul 2019 11:06:41 +0800 In-Reply-To: <37897fb7-88c1-859a-dfcc-0a5e89a642e0@virtuozzo.com> References: <20190613081357.1360-1-walter-zh.wu@mediatek.com> <1560447999.15814.15.camel@mtksdccf07> <1560479520.15814.34.camel@mtksdccf07> <1560744017.15814.49.camel@mtksdccf07> <1560774735.15814.54.camel@mtksdccf07> <1561974995.18866.1.camel@mtksdccf07> <1562640832.9077.32.camel@mtksdccf07> <1562839579.5846.12.camel@mtksdccf07> <37897fb7-88c1-859a-dfcc-0a5e89a642e0@virtuozzo.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2019-07-12 at 13:52 +0300, Andrey Ryabinin wrote: > > On 7/11/19 1:06 PM, Walter Wu wrote: > > On Wed, 2019-07-10 at 21:24 +0300, Andrey Ryabinin wrote: > >> > >> On 7/9/19 5:53 AM, Walter Wu wrote: > >>> On Mon, 2019-07-08 at 19:33 +0300, Andrey Ryabinin wrote: > >>>> > >>>> On 7/5/19 4:34 PM, Dmitry Vyukov wrote: > >>>>> On Mon, Jul 1, 2019 at 11:56 AM Walter Wu wrote: > >> > >>>>> > >>>>> Sorry for delays. I am overwhelm by some urgent work. I afraid to > >>>>> promise any dates because the next week I am on a conference, then > >>>>> again a backlog and an intern starting... > >>>>> > >>>>> Andrey, do you still have concerns re this patch? This change allows > >>>>> to print the free stack. > >>>> > >>>> I 'm not sure that quarantine is a best way to do that. Quarantine is made to delay freeing, but we don't that here. > >>>> If we want to remember more free stacks wouldn't be easier simply to remember more stacks in object itself? > >>>> Same for previously used tags for better use-after-free identification. > >>>> > >>> > >>> Hi Andrey, > >>> > >>> We ever tried to use object itself to determine use-after-free > >>> identification, but tag-based KASAN immediately released the pointer > >>> after call kfree(), the original object will be used by another > >>> pointer, if we use object itself to determine use-after-free issue, then > >>> it has many false negative cases. so we create a lite quarantine(ring > >>> buffers) to record recent free stacks in order to avoid those false > >>> negative situations. > >> > >> I'm telling that *more* than one free stack and also tags per object can be stored. > >> If object reused we would still have information about n-last usages of the object. > >> It seems like much easier and more efficient solution than patch you proposing. > >> > > To make the object reused, we must ensure that no other pointers uses it > > after kfree() release the pointer. > > Scenario: > > 1). The object reused information is valid when no another pointer uses > > it. > > 2). The object reused information is invalid when another pointer uses > > it. > > Do you mean that the object reused is scenario 1) ? > > If yes, maybe we can change the calling quarantine_put() location. It > > will be fully use that quarantine, but at scenario 2) it looks like to > > need this patch. > > If no, maybe i miss your meaning, would you tell me how to use invalid > > object information? or? > > > > > KASAN keeps information about object with the object, right after payload in the kasan_alloc_meta struct. > This information is always valid as long as slab page allocated. Currently it keeps only one last free stacktrace. > It could be extended to record more free stacktraces and also record previously used tags which will allow you > to identify use-after-free and extract right free stacktrace. Thanks for your explanation. For extend slub object, if one record is 9B (sizeof(u8)+ sizeof(struct kasan_track)) and add five records into slub object, every slub object may add 45B usage after the system runs longer. Slub object number is easy more than 1,000,000(maybe it may be more bigger), then the extending object memory usage should be 45MB, and unfortunately it is no limit. The memory usage is more bigger than our patch. We hope tag-based KASAN advantage is smaller memory usage. If it’s possible, we should spend less memory in order to identify use-after-free. Would you accept our patch after fine tune it? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Walter Wu Subject: Re: [PATCH v3] kasan: add memory corruption identification for software tag-based mode Date: Mon, 15 Jul 2019 11:06:41 +0800 Message-ID: <1563160001.4793.4.camel@mtksdccf07> References: <20190613081357.1360-1-walter-zh.wu@mediatek.com> <1560447999.15814.15.camel@mtksdccf07> <1560479520.15814.34.camel@mtksdccf07> <1560744017.15814.49.camel@mtksdccf07> <1560774735.15814.54.camel@mtksdccf07> <1561974995.18866.1.camel@mtksdccf07> <1562640832.9077.32.camel@mtksdccf07> <1562839579.5846.12.camel@mtksdccf07> <37897fb7-88c1-859a-dfcc-0a5e89a642e0@virtuozzo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <37897fb7-88c1-859a-dfcc-0a5e89a642e0@virtuozzo.com> Sender: linux-kernel-owner@vger.kernel.org To: Andrey Ryabinin Cc: Dmitry Vyukov , Alexander Potapenko , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Matthias Brugger , Martin Schwidefsky , Arnd Bergmann , Vasily Gorbik , Andrey Konovalov , "Jason A . Donenfeld" , Miles Chen , kasan-dev , LKML , Linux-MM , Linux ARM , linux-mediatek@lists.infradead.org, wsd_upstream List-Id: linux-mediatek@lists.infradead.org On Fri, 2019-07-12 at 13:52 +0300, Andrey Ryabinin wrote: > > On 7/11/19 1:06 PM, Walter Wu wrote: > > On Wed, 2019-07-10 at 21:24 +0300, Andrey Ryabinin wrote: > >> > >> On 7/9/19 5:53 AM, Walter Wu wrote: > >>> On Mon, 2019-07-08 at 19:33 +0300, Andrey Ryabinin wrote: > >>>> > >>>> On 7/5/19 4:34 PM, Dmitry Vyukov wrote: > >>>>> On Mon, Jul 1, 2019 at 11:56 AM Walter Wu wrote: > >> > >>>>> > >>>>> Sorry for delays. I am overwhelm by some urgent work. I afraid to > >>>>> promise any dates because the next week I am on a conference, then > >>>>> again a backlog and an intern starting... > >>>>> > >>>>> Andrey, do you still have concerns re this patch? This change allows > >>>>> to print the free stack. > >>>> > >>>> I 'm not sure that quarantine is a best way to do that. Quarantine is made to delay freeing, but we don't that here. > >>>> If we want to remember more free stacks wouldn't be easier simply to remember more stacks in object itself? > >>>> Same for previously used tags for better use-after-free identification. > >>>> > >>> > >>> Hi Andrey, > >>> > >>> We ever tried to use object itself to determine use-after-free > >>> identification, but tag-based KASAN immediately released the pointer > >>> after call kfree(), the original object will be used by another > >>> pointer, if we use object itself to determine use-after-free issue, then > >>> it has many false negative cases. so we create a lite quarantine(ring > >>> buffers) to record recent free stacks in order to avoid those false > >>> negative situations. > >> > >> I'm telling that *more* than one free stack and also tags per object can be stored. > >> If object reused we would still have information about n-last usages of the object. > >> It seems like much easier and more efficient solution than patch you proposing. > >> > > To make the object reused, we must ensure that no other pointers uses it > > after kfree() release the pointer. > > Scenario: > > 1). The object reused information is valid when no another pointer uses > > it. > > 2). The object reused information is invalid when another pointer uses > > it. > > Do you mean that the object reused is scenario 1) ? > > If yes, maybe we can change the calling quarantine_put() location. It > > will be fully use that quarantine, but at scenario 2) it looks like to > > need this patch. > > If no, maybe i miss your meaning, would you tell me how to use invalid > > object information? or? > > > > > KASAN keeps information about object with the object, right after payload in the kasan_alloc_meta struct. > This information is always valid as long as slab page allocated. Currently it keeps only one last free stacktrace. > It could be extended to record more free stacktraces and also record previously used tags which will allow you > to identify use-after-free and extract right free stacktrace. Thanks for your explanation. For extend slub object, if one record is 9B (sizeof(u8)+ sizeof(struct kasan_track)) and add five records into slub object, every slub object may add 45B usage after the system runs longer. Slub object number is easy more than 1,000,000(maybe it may be more bigger), then the extending object memory usage should be 45MB, and unfortunately it is no limit. The memory usage is more bigger than our patch. We hope tag-based KASAN advantage is smaller memory usage. If it’s possible, we should spend less memory in order to identify use-after-free. Would you accept our patch after fine tune it? 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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no 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 6B90FC74A4B for ; Mon, 15 Jul 2019 03:07:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3FAA2214AE for ; Mon, 15 Jul 2019 03:07:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KBRjEWZt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FAA2214AE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GYAYHIR/Q4WL6HK4+cZtCOQTIckG9C4dILsj/kFrklA=; b=KBRjEWZtISF784 u2SeXDZrHNfVvmJoCkXEKkQWepkmEnpR5nK+jzsSHFj+AP115wy7xzA+w/3hyXX67pKWxMoze1NHG zjNBRToUmpNtzJBeKfi0FHh2BCT0xyhkVsG+mDmRd5tnoiVsZqFBekWrILq0pSTOS3R2omlTgcxzN tVcEyXv3RZ862FrIerhR1tRmc9Q2mHPVasHrpzDct3uI5EJ2I50K44urajAdDmxz5jp1Oyr35DmO+ pGkLNbCQ56IQBlXfmQACUckLQgpro3SmNnvSTbO3TyvDrnrNxu57Rs4w0kTcadujgWPGEpwg1mor8 ojKAmFrmVbRzwW9yJorw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hmrKP-0007l9-Cy; Mon, 15 Jul 2019 03:07:01 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hmrKH-0007j9-EE; Mon, 15 Jul 2019 03:06:55 +0000 X-UUID: 818553dd33224673bda5619ed769cd28-20190714 X-UUID: 818553dd33224673bda5619ed769cd28-20190714 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1448161256; Sun, 14 Jul 2019 19:06:44 -0800 Received: from mtkmbs07n1.mediatek.inc (172.21.101.16) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 14 Jul 2019 20:06:42 -0700 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs07n1.mediatek.inc (172.21.101.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jul 2019 11:06:41 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 15 Jul 2019 11:06:40 +0800 Message-ID: <1563160001.4793.4.camel@mtksdccf07> Subject: Re: [PATCH v3] kasan: add memory corruption identification for software tag-based mode From: Walter Wu To: Andrey Ryabinin Date: Mon, 15 Jul 2019 11:06:41 +0800 In-Reply-To: <37897fb7-88c1-859a-dfcc-0a5e89a642e0@virtuozzo.com> References: <20190613081357.1360-1-walter-zh.wu@mediatek.com> <1560447999.15814.15.camel@mtksdccf07> <1560479520.15814.34.camel@mtksdccf07> <1560744017.15814.49.camel@mtksdccf07> <1560774735.15814.54.camel@mtksdccf07> <1561974995.18866.1.camel@mtksdccf07> <1562640832.9077.32.camel@mtksdccf07> <1562839579.5846.12.camel@mtksdccf07> <37897fb7-88c1-859a-dfcc-0a5e89a642e0@virtuozzo.com> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190714_200653_488405_3C9A1EF1 X-CRM114-Status: GOOD ( 21.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: wsd_upstream , "Jason A . Donenfeld" , Vasily Gorbik , Arnd Bergmann , Linux-MM , Andrey Konovalov , LKML , kasan-dev , Pekka Enberg , Martin Schwidefsky , Miles Chen , Alexander Potapenko , Linux ARM , David Rientjes , Matthias Brugger , linux-mediatek@lists.infradead.org, Christoph Lameter , Joonsoo Kim , Dmitry Vyukov Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gRnJpLCAyMDE5LTA3LTEyIGF0IDEzOjUyICswMzAwLCBBbmRyZXkgUnlhYmluaW4gd3JvdGU6 Cj4gCj4gT24gNy8xMS8xOSAxOjA2IFBNLCBXYWx0ZXIgV3Ugd3JvdGU6Cj4gPiBPbiBXZWQsIDIw MTktMDctMTAgYXQgMjE6MjQgKzAzMDAsIEFuZHJleSBSeWFiaW5pbiB3cm90ZToKPiA+Pgo+ID4+ IE9uIDcvOS8xOSA1OjUzIEFNLCBXYWx0ZXIgV3Ugd3JvdGU6Cj4gPj4+IE9uIE1vbiwgMjAxOS0w Ny0wOCBhdCAxOTozMyArMDMwMCwgQW5kcmV5IFJ5YWJpbmluIHdyb3RlOgo+ID4+Pj4KPiA+Pj4+ IE9uIDcvNS8xOSA0OjM0IFBNLCBEbWl0cnkgVnl1a292IHdyb3RlOgo+ID4+Pj4+IE9uIE1vbiwg SnVsIDEsIDIwMTkgYXQgMTE6NTYgQU0gV2FsdGVyIFd1IDx3YWx0ZXItemgud3VAbWVkaWF0ZWsu Y29tPiB3cm90ZToKPiA+Pgo+ID4+Pj4+Cj4gPj4+Pj4gU29ycnkgZm9yIGRlbGF5cy4gSSBhbSBv dmVyd2hlbG0gYnkgc29tZSB1cmdlbnQgd29yay4gSSBhZnJhaWQgdG8KPiA+Pj4+PiBwcm9taXNl IGFueSBkYXRlcyBiZWNhdXNlIHRoZSBuZXh0IHdlZWsgSSBhbSBvbiBhIGNvbmZlcmVuY2UsIHRo ZW4KPiA+Pj4+PiBhZ2FpbiBhIGJhY2tsb2cgYW5kIGFuIGludGVybiBzdGFydGluZy4uLgo+ID4+ Pj4+Cj4gPj4+Pj4gQW5kcmV5LCBkbyB5b3Ugc3RpbGwgaGF2ZSBjb25jZXJucyByZSB0aGlzIHBh dGNoPyBUaGlzIGNoYW5nZSBhbGxvd3MKPiA+Pj4+PiB0byBwcmludCB0aGUgZnJlZSBzdGFjay4K PiA+Pj4+Cj4gPj4+PiBJICdtIG5vdCBzdXJlIHRoYXQgcXVhcmFudGluZSBpcyBhIGJlc3Qgd2F5 IHRvIGRvIHRoYXQuIFF1YXJhbnRpbmUgaXMgbWFkZSB0byBkZWxheSBmcmVlaW5nLCBidXQgd2Ug ZG9uJ3QgdGhhdCBoZXJlLgo+ID4+Pj4gSWYgd2Ugd2FudCB0byByZW1lbWJlciBtb3JlIGZyZWUg c3RhY2tzIHdvdWxkbid0IGJlIGVhc2llciBzaW1wbHkgdG8gcmVtZW1iZXIgbW9yZSBzdGFja3Mg aW4gb2JqZWN0IGl0c2VsZj8KPiA+Pj4+IFNhbWUgZm9yIHByZXZpb3VzbHkgdXNlZCB0YWdzIGZv ciBiZXR0ZXIgdXNlLWFmdGVyLWZyZWUgaWRlbnRpZmljYXRpb24uCj4gPj4+Pgo+ID4+Pgo+ID4+ PiBIaSBBbmRyZXksCj4gPj4+Cj4gPj4+IFdlIGV2ZXIgdHJpZWQgdG8gdXNlIG9iamVjdCBpdHNl bGYgdG8gZGV0ZXJtaW5lIHVzZS1hZnRlci1mcmVlCj4gPj4+IGlkZW50aWZpY2F0aW9uLCBidXQg dGFnLWJhc2VkIEtBU0FOIGltbWVkaWF0ZWx5IHJlbGVhc2VkIHRoZSBwb2ludGVyCj4gPj4+IGFm dGVyIGNhbGwga2ZyZWUoKSwgdGhlIG9yaWdpbmFsIG9iamVjdCB3aWxsIGJlIHVzZWQgYnkgYW5v dGhlcgo+ID4+PiBwb2ludGVyLCBpZiB3ZSB1c2Ugb2JqZWN0IGl0c2VsZiB0byBkZXRlcm1pbmUg dXNlLWFmdGVyLWZyZWUgaXNzdWUsIHRoZW4KPiA+Pj4gaXQgaGFzIG1hbnkgZmFsc2UgbmVnYXRp dmUgY2FzZXMuIHNvIHdlIGNyZWF0ZSBhIGxpdGUgcXVhcmFudGluZShyaW5nCj4gPj4+IGJ1ZmZl cnMpIHRvIHJlY29yZCByZWNlbnQgZnJlZSBzdGFja3MgaW4gb3JkZXIgdG8gYXZvaWQgdGhvc2Ug ZmFsc2UKPiA+Pj4gbmVnYXRpdmUgc2l0dWF0aW9ucy4KPiA+Pgo+ID4+IEknbSB0ZWxsaW5nIHRo YXQgKm1vcmUqIHRoYW4gb25lIGZyZWUgc3RhY2sgYW5kIGFsc28gdGFncyBwZXIgb2JqZWN0IGNh biBiZSBzdG9yZWQuCj4gPj4gSWYgb2JqZWN0IHJldXNlZCB3ZSB3b3VsZCBzdGlsbCBoYXZlIGlu Zm9ybWF0aW9uIGFib3V0IG4tbGFzdCB1c2FnZXMgb2YgdGhlIG9iamVjdC4KPiA+PiBJdCBzZWVt cyBsaWtlIG11Y2ggZWFzaWVyIGFuZCBtb3JlIGVmZmljaWVudCBzb2x1dGlvbiB0aGFuIHBhdGNo IHlvdSBwcm9wb3NpbmcuCj4gPj4KPiA+IFRvIG1ha2UgdGhlIG9iamVjdCByZXVzZWQsIHdlIG11 c3QgZW5zdXJlIHRoYXQgbm8gb3RoZXIgcG9pbnRlcnMgdXNlcyBpdAo+ID4gYWZ0ZXIga2ZyZWUo KSByZWxlYXNlIHRoZSBwb2ludGVyLgo+ID4gU2NlbmFyaW86Cj4gPiAxKS4gVGhlIG9iamVjdCBy ZXVzZWQgaW5mb3JtYXRpb24gaXMgdmFsaWQgd2hlbiBubyBhbm90aGVyIHBvaW50ZXIgdXNlcwo+ ID4gaXQuCj4gPiAyKS4gVGhlIG9iamVjdCByZXVzZWQgaW5mb3JtYXRpb24gaXMgaW52YWxpZCB3 aGVuIGFub3RoZXIgcG9pbnRlciB1c2VzCj4gPiBpdC4KPiA+IERvIHlvdSBtZWFuIHRoYXQgdGhl IG9iamVjdCByZXVzZWQgaXMgc2NlbmFyaW8gMSkgPwo+ID4gSWYgeWVzLCBtYXliZSB3ZSBjYW4g Y2hhbmdlIHRoZSBjYWxsaW5nIHF1YXJhbnRpbmVfcHV0KCkgbG9jYXRpb24uIEl0Cj4gPiB3aWxs IGJlIGZ1bGx5IHVzZSB0aGF0IHF1YXJhbnRpbmUsIGJ1dCBhdCBzY2VuYXJpbyAyKSBpdCBsb29r cyBsaWtlIHRvCj4gPiBuZWVkIHRoaXMgcGF0Y2guCj4gPiBJZiBubywgbWF5YmUgaSBtaXNzIHlv dXIgbWVhbmluZywgd291bGQgeW91IHRlbGwgbWUgaG93IHRvIHVzZSBpbnZhbGlkCj4gPiBvYmpl Y3QgaW5mb3JtYXRpb24/IG9yPwo+ID4gCj4gCj4gCj4gS0FTQU4ga2VlcHMgaW5mb3JtYXRpb24g YWJvdXQgb2JqZWN0IHdpdGggdGhlIG9iamVjdCwgcmlnaHQgYWZ0ZXIgcGF5bG9hZCBpbiB0aGUg a2FzYW5fYWxsb2NfbWV0YSBzdHJ1Y3QuCj4gVGhpcyBpbmZvcm1hdGlvbiBpcyBhbHdheXMgdmFs aWQgYXMgbG9uZyBhcyBzbGFiIHBhZ2UgYWxsb2NhdGVkLiBDdXJyZW50bHkgaXQga2VlcHMgb25s eSBvbmUgbGFzdCBmcmVlIHN0YWNrdHJhY2UuCj4gSXQgY291bGQgYmUgZXh0ZW5kZWQgdG8gcmVj b3JkIG1vcmUgZnJlZSBzdGFja3RyYWNlcyBhbmQgYWxzbyByZWNvcmQgcHJldmlvdXNseSB1c2Vk IHRhZ3Mgd2hpY2ggd2lsbCBhbGxvdyB5b3UKPiB0byBpZGVudGlmeSB1c2UtYWZ0ZXItZnJlZSBh bmQgZXh0cmFjdCByaWdodCBmcmVlIHN0YWNrdHJhY2UuCgpUaGFua3MgZm9yIHlvdXIgZXhwbGFu YXRpb24uCgpGb3IgZXh0ZW5kIHNsdWIgb2JqZWN0LCBpZiBvbmUgcmVjb3JkIGlzIDlCIChzaXpl b2YodTgpKyBzaXplb2Yoc3RydWN0Cmthc2FuX3RyYWNrKSkgYW5kIGFkZCBmaXZlIHJlY29yZHMg aW50byBzbHViIG9iamVjdCwgZXZlcnkgc2x1YiBvYmplY3QKbWF5IGFkZCA0NUIgdXNhZ2UgYWZ0 ZXIgdGhlIHN5c3RlbSBydW5zIGxvbmdlci4gClNsdWIgb2JqZWN0IG51bWJlciBpcyBlYXN5IG1v cmUgdGhhbiAxLDAwMCwwMDAobWF5YmUgaXQgbWF5IGJlIG1vcmUKYmlnZ2VyKSwgdGhlbiB0aGUg ZXh0ZW5kaW5nIG9iamVjdCBtZW1vcnkgdXNhZ2Ugc2hvdWxkIGJlIDQ1TUIsIGFuZAp1bmZvcnR1 bmF0ZWx5IGl0IGlzIG5vIGxpbWl0LiBUaGUgbWVtb3J5IHVzYWdlIGlzIG1vcmUgYmlnZ2VyIHRo YW4gb3VyCnBhdGNoLgoKV2UgaG9wZSB0YWctYmFzZWQgS0FTQU4gYWR2YW50YWdlIGlzIHNtYWxs ZXIgbWVtb3J5IHVzYWdlLiBJZiBpdOKAmXMKcG9zc2libGUsIHdlIHNob3VsZCBzcGVuZCBsZXNz IG1lbW9yeSBpbiBvcmRlciB0byBpZGVudGlmeQp1c2UtYWZ0ZXItZnJlZS4gV291bGQgeW91IGFj Y2VwdCBvdXIgcGF0Y2ggYWZ0ZXIgZmluZSB0dW5lIGl0PwoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0 CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFk ZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK