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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 901D4C433DF for ; Wed, 19 Aug 2020 18:54:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 629BB207FF for ; Wed, 19 Aug 2020 18:54:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726749AbgHSSy3 (ORCPT ); Wed, 19 Aug 2020 14:54:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726211AbgHSSyS (ORCPT ); Wed, 19 Aug 2020 14:54:18 -0400 Received: from smtp-42af.mail.infomaniak.ch (smtp-42af.mail.infomaniak.ch [IPv6:2001:1600:3:17::42af]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71633C061757 for ; Wed, 19 Aug 2020 11:54:17 -0700 (PDT) Received: from smtp-3-0000.mail.infomaniak.ch (unknown [10.4.36.107]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4BWxlD0kK1zlhQGJ; Wed, 19 Aug 2020 20:54:00 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [94.23.54.103]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4BWxlB6m3Xzlh8TC; Wed, 19 Aug 2020 20:53:58 +0200 (CEST) Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: Mark Rutland , "Madhavan T. Venkataraman" Cc: kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, oleg@redhat.com, x86@kernel.org References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <20200731180955.GC67415@C02TD0UTHF1T.local> <6236adf7-4bed-534e-0956-fddab4fd96b6@linux.microsoft.com> <20200804143018.GB7440@C02TD0UTHF1T.local> <20200812100650.GB28154@C02TD0UTHF1T.local> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <41c4de64-68d0-6fcb-e5c3-63ebd459262e@digikod.net> Date: Wed, 19 Aug 2020 20:53:42 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <20200812100650.GB28154@C02TD0UTHF1T.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/08/2020 12:06, Mark Rutland wrote: > On Thu, Aug 06, 2020 at 12:26:02PM -0500, Madhavan T. Venkataraman wrote: >> Thanks for the lively discussion. I have tried to answer some of the >> comments below. >> >> On 8/4/20 9:30 AM, Mark Rutland wrote: >>> >>>> So, the context is - if security settings in a system disallow a page to have >>>> both write and execute permissions, how do you allow the execution of >>>> genuine trampolines that are runtime generated and placed in a data >>>> page or a stack page? >>> There are options today, e.g. >>> >>> a) If the restriction is only per-alias, you can have distinct aliases >>> where one is writable and another is executable, and you can make it >>> hard to find the relationship between the two. >>> >>> b) If the restriction is only temporal, you can write instructions into >>> an RW- buffer, transition the buffer to R--, verify the buffer >>> contents, then transition it to --X. >>> >>> c) You can have two processes A and B where A generates instrucitons into >>> a buffer that (only) B can execute (where B may be restricted from >>> making syscalls like write, mprotect, etc). >> >> The general principle of the mitigation is W^X. I would argue that >> the above options are violations of the W^X principle. If they are >> allowed today, they must be fixed. And they will be. So, we cannot >> rely on them. > > Hold on. > > Contemporary W^X means that a given virtual alias cannot be writeable > and executeable simultaneously, permitting (a) and (b). If you read the > references on the Wikipedia page for W^X you'll see the OpenBSD 3.3 > release notes and related presentation make this clear, and further they > expect (b) to occur with JITS flipping W/X with mprotect(). W^X (with "permanent" mprotect restrictions [1]) goes back to 2000 with PaX [2] (which predates partial OpenBSD implementation from 2003). [1] https://pax.grsecurity.net/docs/mprotect.txt [2] https://undeadly.org/cgi?action=article;sid=20030417082752 > > Please don't conflate your assumed stronger semantics with the general > principle. It not matching you expectations does not necessarily mean > that it is wrong. > > If you want a stronger W^X semantics, please refer to this specifically > with a distinct name. > >> a) This requires a remap operation. Two mappings point to the same >>      physical page. One mapping has W and the other one has X. This >>      is a violation of W^X. >> >> b) This is again a violation. The kernel should refuse to give execute >>      permission to a page that was writeable in the past and refuse to >>      give write permission to a page that was executable in the past. >> >> c) This is just a variation of (a). > > As above, this is not true. > > If you have a rationale for why this is desirable or necessary, please > justify that before using this as justification for additional features. > >> In general, the problem with user-level methods to map and execute >> dynamic code is that the kernel cannot tell if a genuine application is >> using them or an attacker is using them or piggy-backing on them. > > Yes, and as I pointed out the same is true for trampfd unless you can > somehow authenticate the calls are legitimate (in both callsite and the > set of arguments), and I don't see any reasonable way of doing that. > > If you relax your threat model to an attacker not being able to make > arbitrary syscalls, then your suggestion that userspace can perorm > chceks between syscalls may be sufficient, but as I pointed out that's > equally true for a sealed memfd or similar. > >> Off the top of my head, I have tried to identify some examples >> where we can have more trust on dynamic code and have the kernel >> permit its execution. >> >> 1. If the kernel can do the job, then that is one safe way. Here, the kernel >>     is the code. There is no code generation involved. This is what I >>     have presented in the patch series as the first cut. > > This is sleight-of-hand; it doesn't matter where the logic is performed > if the power is identical. Practically speaking this is equivalent to > some dynamic code generation. > > I think that it's misleading to say that because the kernel emulates > something it is safe when the provenance of the syscall arguments cannot > be verified. > > [...] > >> Anyway, these are just examples. The principle is - if we can identify >> dynamic code that has a certain measure of trust, can the kernel >> permit their execution? > > My point generally is that the kernel cannot identify this, and if > usrspace code is trusted to dynamically generate trampfd arguments it > can equally be trusted to dyncamilly generate code. > > [...] > >> As I have mentioned above, I intend to have the kernel generate code >> only if the code generation is simple enough. For more complicated cases, >> I plan to use a user-level code generator that is for exclusive kernel use. >> I have yet to work out the details on how this would work. Need time. > > This reads to me like trampfd is only dealing with a few special cases > and we know that we need a more general solution. > > I hope I am mistaken, but I get the strong impression that you're trying > to justify your existing solution rather than trying to understand the > problem space. > > To be clear, my strong opinion is that we should not be trying to do > this sort of emulation or code generation within the kernel. I do think > it's worthwhile to look at mechanisms to make it harder to subvert > dynamic userspace code generation, but I think the code generation > itself needs to live in userspace (e.g. for ABI reasons I previously > mentioned). > > Mark. > 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5EE95C433DF for ; Wed, 19 Aug 2020 18:55:19 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 32AE4207FF for ; Wed, 19 Aug 2020 18:55:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jfl6/Tci" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32AE4207FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=D8lptc/hTclJfkCuew/hl+ty9CwJmcxH9Co5WuFIJCg=; b=jfl6/TciTGN7gRsrAp+bhttUK irXlWEbQxaNsoUPK2H48CaeD3rM2EvG1CyyiVjzOdVSL+MhrPq685JOV8e6OlHRjCJqQiqjaHOu0t /dn4Z6TRQ+H2kFZHfM1JGl/68IV61IWzh/a7jHIYOSUOugikH2BNYpYfMUKJ1Z/HL33/tmM83fwgt b2WItZTukdqvuwlBXRXTdXkysqI92oW9P855qPiwckb8cIXVf5oSR6Ee7DxxId/rg1bXnkev7E/8P syhFA/FHUkJFHA1WfQPzgFadDT/9zQ8bCU/fZW6tB8v0Z0pNJ8Ppjd+FFSoD+MS0jZ/gm+f2lAme8 /XLXiViBA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8TDr-0006I2-9u; Wed, 19 Aug 2020 18:54:07 +0000 Received: from smtp-190d.mail.infomaniak.ch ([2001:1600:3:17::190d]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8TDo-0006H5-Dm for linux-arm-kernel@lists.infradead.org; Wed, 19 Aug 2020 18:54:06 +0000 Received: from smtp-3-0000.mail.infomaniak.ch (unknown [10.4.36.107]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4BWxlD0kK1zlhQGJ; Wed, 19 Aug 2020 20:54:00 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [94.23.54.103]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4BWxlB6m3Xzlh8TC; Wed, 19 Aug 2020 20:53:58 +0200 (CEST) Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: Mark Rutland , "Madhavan T. Venkataraman" References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <20200731180955.GC67415@C02TD0UTHF1T.local> <6236adf7-4bed-534e-0956-fddab4fd96b6@linux.microsoft.com> <20200804143018.GB7440@C02TD0UTHF1T.local> <20200812100650.GB28154@C02TD0UTHF1T.local> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <41c4de64-68d0-6fcb-e5c3-63ebd459262e@digikod.net> Date: Wed, 19 Aug 2020 20:53:42 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <20200812100650.GB28154@C02TD0UTHF1T.local> Content-Language: en-US X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200819_145404_708325_AD408626 X-CRM114-Status: GOOD ( 36.83 ) 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: kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Ck9uIDEyLzA4LzIwMjAgMTI6MDYsIE1hcmsgUnV0bGFuZCB3cm90ZToKPiBPbiBUaHUsIEF1ZyAw NiwgMjAyMCBhdCAxMjoyNjowMlBNIC0wNTAwLCBNYWRoYXZhbiBULiBWZW5rYXRhcmFtYW4gd3Jv dGU6Cj4+IFRoYW5rcyBmb3IgdGhlIGxpdmVseSBkaXNjdXNzaW9uLiBJIGhhdmUgdHJpZWQgdG8g YW5zd2VyIHNvbWUgb2YgdGhlCj4+IGNvbW1lbnRzIGJlbG93Lgo+Pgo+PiBPbiA4LzQvMjAgOToz MCBBTSwgTWFyayBSdXRsYW5kIHdyb3RlOgo+Pj4KPj4+PiBTbywgdGhlIGNvbnRleHQgaXMgLSBp ZiBzZWN1cml0eSBzZXR0aW5ncyBpbiBhIHN5c3RlbSBkaXNhbGxvdyBhIHBhZ2UgdG8gaGF2ZQo+ Pj4+IGJvdGggd3JpdGUgYW5kIGV4ZWN1dGUgcGVybWlzc2lvbnMsIGhvdyBkbyB5b3UgYWxsb3cg dGhlIGV4ZWN1dGlvbiBvZgo+Pj4+IGdlbnVpbmUgdHJhbXBvbGluZXMgdGhhdCBhcmUgcnVudGlt ZSBnZW5lcmF0ZWQgYW5kIHBsYWNlZCBpbiBhIGRhdGEKPj4+PiBwYWdlIG9yIGEgc3RhY2sgcGFn ZT8KPj4+IFRoZXJlIGFyZSBvcHRpb25zIHRvZGF5LCBlLmcuCj4+Pgo+Pj4gYSkgSWYgdGhlIHJl c3RyaWN0aW9uIGlzIG9ubHkgcGVyLWFsaWFzLCB5b3UgY2FuIGhhdmUgZGlzdGluY3QgYWxpYXNl cwo+Pj4gICAgd2hlcmUgb25lIGlzIHdyaXRhYmxlIGFuZCBhbm90aGVyIGlzIGV4ZWN1dGFibGUs IGFuZCB5b3UgY2FuIG1ha2UgaXQKPj4+ICAgIGhhcmQgdG8gZmluZCB0aGUgcmVsYXRpb25zaGlw IGJldHdlZW4gdGhlIHR3by4KPj4+Cj4+PiBiKSBJZiB0aGUgcmVzdHJpY3Rpb24gaXMgb25seSB0 ZW1wb3JhbCwgeW91IGNhbiB3cml0ZSBpbnN0cnVjdGlvbnMgaW50bwo+Pj4gICAgYW4gUlctIGJ1 ZmZlciwgdHJhbnNpdGlvbiB0aGUgYnVmZmVyIHRvIFItLSwgdmVyaWZ5IHRoZSBidWZmZXIKPj4+ ICAgIGNvbnRlbnRzLCB0aGVuIHRyYW5zaXRpb24gaXQgdG8gLS1YLgo+Pj4KPj4+IGMpIFlvdSBj YW4gaGF2ZSB0d28gcHJvY2Vzc2VzIEEgYW5kIEIgd2hlcmUgQSBnZW5lcmF0ZXMgaW5zdHJ1Y2l0 b25zIGludG8KPj4+ICAgIGEgYnVmZmVyIHRoYXQgKG9ubHkpIEIgY2FuIGV4ZWN1dGUgKHdoZXJl IEIgbWF5IGJlIHJlc3RyaWN0ZWQgZnJvbQo+Pj4gICAgbWFraW5nIHN5c2NhbGxzIGxpa2Ugd3Jp dGUsIG1wcm90ZWN0LCBldGMpLgo+Pgo+PiBUaGUgZ2VuZXJhbCBwcmluY2lwbGUgb2YgdGhlIG1p dGlnYXRpb24gaXMgV15YLiBJIHdvdWxkIGFyZ3VlIHRoYXQKPj4gdGhlIGFib3ZlIG9wdGlvbnMg YXJlIHZpb2xhdGlvbnMgb2YgdGhlIFdeWCBwcmluY2lwbGUuIElmIHRoZXkgYXJlCj4+IGFsbG93 ZWQgdG9kYXksIHRoZXkgbXVzdCBiZSBmaXhlZC4gQW5kIHRoZXkgd2lsbCBiZS4gU28sIHdlIGNh bm5vdAo+PiByZWx5IG9uIHRoZW0uCj4gCj4gSG9sZCBvbi4KPiAKPiBDb250ZW1wb3JhcnkgV15Y IG1lYW5zIHRoYXQgYSBnaXZlbiB2aXJ0dWFsIGFsaWFzIGNhbm5vdCBiZSB3cml0ZWFibGUKPiBh bmQgZXhlY3V0ZWFibGUgc2ltdWx0YW5lb3VzbHksIHBlcm1pdHRpbmcgKGEpIGFuZCAoYikuIElm IHlvdSByZWFkIHRoZQo+IHJlZmVyZW5jZXMgb24gdGhlIFdpa2lwZWRpYSBwYWdlIGZvciBXXlgg eW91J2xsIHNlZSB0aGUgT3BlbkJTRCAzLjMKPiByZWxlYXNlIG5vdGVzIGFuZCByZWxhdGVkIHBy ZXNlbnRhdGlvbiBtYWtlIHRoaXMgY2xlYXIsIGFuZCBmdXJ0aGVyIHRoZXkKPiBleHBlY3QgKGIp IHRvIG9jY3VyIHdpdGggSklUUyBmbGlwcGluZyBXL1ggd2l0aCBtcHJvdGVjdCgpLgoKV15YICh3 aXRoICJwZXJtYW5lbnQiIG1wcm90ZWN0IHJlc3RyaWN0aW9ucyBbMV0pIGdvZXMgYmFjayB0byAy MDAwIHdpdGgKUGFYIFsyXSAod2hpY2ggcHJlZGF0ZXMgcGFydGlhbCBPcGVuQlNEIGltcGxlbWVu dGF0aW9uIGZyb20gMjAwMykuCgpbMV0gaHR0cHM6Ly9wYXguZ3JzZWN1cml0eS5uZXQvZG9jcy9t cHJvdGVjdC50eHQKWzJdIGh0dHBzOi8vdW5kZWFkbHkub3JnL2NnaT9hY3Rpb249YXJ0aWNsZTtz aWQ9MjAwMzA0MTcwODI3NTIKCj4gCj4gUGxlYXNlIGRvbid0IGNvbmZsYXRlIHlvdXIgYXNzdW1l ZCBzdHJvbmdlciBzZW1hbnRpY3Mgd2l0aCB0aGUgZ2VuZXJhbAo+IHByaW5jaXBsZS4gSXQgbm90 IG1hdGNoaW5nIHlvdSBleHBlY3RhdGlvbnMgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbgo+IHRo YXQgaXQgaXMgd3JvbmcuCj4gCj4gSWYgeW91IHdhbnQgYSBzdHJvbmdlciBXXlggc2VtYW50aWNz LCBwbGVhc2UgcmVmZXIgdG8gdGhpcyBzcGVjaWZpY2FsbHkKPiB3aXRoIGEgZGlzdGluY3QgbmFt ZS4KPiAKPj4gYSkgVGhpcyByZXF1aXJlcyBhIHJlbWFwIG9wZXJhdGlvbi4gVHdvIG1hcHBpbmdz IHBvaW50IHRvIHRoZSBzYW1lCj4+IMKgwqDCoMKgIHBoeXNpY2FsIHBhZ2UuIE9uZSBtYXBwaW5n IGhhcyBXIGFuZCB0aGUgb3RoZXIgb25lIGhhcyBYLiBUaGlzCj4+IMKgwqDCoMKgIGlzIGEgdmlv bGF0aW9uIG9mIFdeWC4KPj4KPj4gYikgVGhpcyBpcyBhZ2FpbiBhIHZpb2xhdGlvbi4gVGhlIGtl cm5lbCBzaG91bGQgcmVmdXNlIHRvIGdpdmUgZXhlY3V0ZQo+PiDCoMKgwqDCoCBwZXJtaXNzaW9u IHRvIGEgcGFnZSB0aGF0IHdhcyB3cml0ZWFibGUgaW4gdGhlIHBhc3QgYW5kIHJlZnVzZSB0bwo+ PiDCoMKgwqDCoCBnaXZlIHdyaXRlIHBlcm1pc3Npb24gdG8gYSBwYWdlIHRoYXQgd2FzIGV4ZWN1 dGFibGUgaW4gdGhlIHBhc3QuCj4+Cj4+IGMpIFRoaXMgaXMganVzdCBhIHZhcmlhdGlvbiBvZiAo YSkuCj4gCj4gQXMgYWJvdmUsIHRoaXMgaXMgbm90IHRydWUuCj4gCj4gSWYgeW91IGhhdmUgYSBy YXRpb25hbGUgZm9yIHdoeSB0aGlzIGlzIGRlc2lyYWJsZSBvciBuZWNlc3NhcnksIHBsZWFzZQo+ IGp1c3RpZnkgdGhhdCBiZWZvcmUgdXNpbmcgdGhpcyBhcyBqdXN0aWZpY2F0aW9uIGZvciBhZGRp dGlvbmFsIGZlYXR1cmVzLgo+IAo+PiBJbiBnZW5lcmFsLCB0aGUgcHJvYmxlbSB3aXRoIHVzZXIt bGV2ZWwgbWV0aG9kcyB0byBtYXAgYW5kIGV4ZWN1dGUKPj4gZHluYW1pYyBjb2RlIGlzIHRoYXQg dGhlIGtlcm5lbCBjYW5ub3QgdGVsbCBpZiBhIGdlbnVpbmUgYXBwbGljYXRpb24gaXMKPj4gdXNp bmcgdGhlbSBvciBhbiBhdHRhY2tlciBpcyB1c2luZyB0aGVtIG9yIHBpZ2d5LWJhY2tpbmcgb24g dGhlbS4KPiAKPiBZZXMsIGFuZCBhcyBJIHBvaW50ZWQgb3V0IHRoZSBzYW1lIGlzIHRydWUgZm9y IHRyYW1wZmQgdW5sZXNzIHlvdSBjYW4KPiBzb21laG93IGF1dGhlbnRpY2F0ZSB0aGUgY2FsbHMg YXJlIGxlZ2l0aW1hdGUgKGluIGJvdGggY2FsbHNpdGUgYW5kIHRoZQo+IHNldCBvZiBhcmd1bWVu dHMpLCBhbmQgSSBkb24ndCBzZWUgYW55IHJlYXNvbmFibGUgd2F5IG9mIGRvaW5nIHRoYXQuCj4g Cj4gSWYgeW91IHJlbGF4IHlvdXIgdGhyZWF0IG1vZGVsIHRvIGFuIGF0dGFja2VyIG5vdCBiZWlu ZyBhYmxlIHRvIG1ha2UKPiBhcmJpdHJhcnkgc3lzY2FsbHMsIHRoZW4geW91ciBzdWdnZXN0aW9u IHRoYXQgdXNlcnNwYWNlIGNhbiBwZXJvcm0KPiBjaGNla3MgYmV0d2VlbiBzeXNjYWxscyBtYXkg YmUgc3VmZmljaWVudCwgYnV0IGFzIEkgcG9pbnRlZCBvdXQgdGhhdCdzCj4gZXF1YWxseSB0cnVl IGZvciBhIHNlYWxlZCBtZW1mZCBvciBzaW1pbGFyLgo+IAo+PiBPZmYgdGhlIHRvcCBvZiBteSBo ZWFkLCBJIGhhdmUgdHJpZWQgdG8gaWRlbnRpZnkgc29tZSBleGFtcGxlcwo+PiB3aGVyZSB3ZSBj YW4gaGF2ZSBtb3JlIHRydXN0IG9uIGR5bmFtaWMgY29kZSBhbmQgaGF2ZSB0aGUga2VybmVsCj4+ IHBlcm1pdCBpdHMgZXhlY3V0aW9uLgo+Pgo+PiAxLiBJZiB0aGUga2VybmVsIGNhbiBkbyB0aGUg am9iLCB0aGVuIHRoYXQgaXMgb25lIHNhZmUgd2F5LiBIZXJlLCB0aGUga2VybmVsCj4+IMKgwqDC oCBpcyB0aGUgY29kZS4gVGhlcmUgaXMgbm8gY29kZSBnZW5lcmF0aW9uIGludm9sdmVkLiBUaGlz IGlzIHdoYXQgSQo+PiDCoMKgwqAgaGF2ZSBwcmVzZW50ZWQgaW4gdGhlIHBhdGNoIHNlcmllcyBh cyB0aGUgZmlyc3QgY3V0Lgo+IAo+IFRoaXMgaXMgc2xlaWdodC1vZi1oYW5kOyBpdCBkb2Vzbid0 IG1hdHRlciB3aGVyZSB0aGUgbG9naWMgaXMgcGVyZm9ybWVkCj4gaWYgdGhlIHBvd2VyIGlzIGlk ZW50aWNhbC4gUHJhY3RpY2FsbHkgc3BlYWtpbmcgdGhpcyBpcyBlcXVpdmFsZW50IHRvCj4gc29t ZSBkeW5hbWljIGNvZGUgZ2VuZXJhdGlvbi4KPiAKPiBJIHRoaW5rIHRoYXQgaXQncyBtaXNsZWFk aW5nIHRvIHNheSB0aGF0IGJlY2F1c2UgdGhlIGtlcm5lbCBlbXVsYXRlcwo+IHNvbWV0aGluZyBp dCBpcyBzYWZlIHdoZW4gdGhlIHByb3ZlbmFuY2Ugb2YgdGhlIHN5c2NhbGwgYXJndW1lbnRzIGNh bm5vdAo+IGJlIHZlcmlmaWVkLgo+IAo+IFsuLi5dCj4gCj4+IEFueXdheSwgdGhlc2UgYXJlIGp1 c3QgZXhhbXBsZXMuIFRoZSBwcmluY2lwbGUgaXMgLSBpZiB3ZSBjYW4gaWRlbnRpZnkKPj4gZHlu YW1pYyBjb2RlIHRoYXQgaGFzIGEgY2VydGFpbiBtZWFzdXJlIG9mIHRydXN0LCBjYW4gdGhlIGtl cm5lbAo+PiBwZXJtaXQgdGhlaXIgZXhlY3V0aW9uPwo+IAo+IE15IHBvaW50IGdlbmVyYWxseSBp cyB0aGF0IHRoZSBrZXJuZWwgY2Fubm90IGlkZW50aWZ5IHRoaXMsIGFuZCBpZgo+IHVzcnNwYWNl IGNvZGUgaXMgdHJ1c3RlZCB0byBkeW5hbWljYWxseSBnZW5lcmF0ZSB0cmFtcGZkIGFyZ3VtZW50 cyBpdAo+IGNhbiBlcXVhbGx5IGJlIHRydXN0ZWQgdG8gZHluY2FtaWxseSBnZW5lcmF0ZSBjb2Rl Lgo+IAo+IFsuLi5dCj4gCj4+IEFzIEkgaGF2ZSBtZW50aW9uZWQgYWJvdmUsIEkgaW50ZW5kIHRv IGhhdmUgdGhlIGtlcm5lbCBnZW5lcmF0ZSBjb2RlCj4+IG9ubHkgaWYgdGhlIGNvZGUgZ2VuZXJh dGlvbiBpcyBzaW1wbGUgZW5vdWdoLiBGb3IgbW9yZSBjb21wbGljYXRlZCBjYXNlcywKPj4gSSBw bGFuIHRvIHVzZSBhIHVzZXItbGV2ZWwgY29kZSBnZW5lcmF0b3IgdGhhdCBpcyBmb3IgZXhjbHVz aXZlIGtlcm5lbCB1c2UuCj4+IEkgaGF2ZSB5ZXQgdG8gd29yayBvdXQgdGhlIGRldGFpbHMgb24g aG93IHRoaXMgd291bGQgd29yay4gTmVlZCB0aW1lLgo+IAo+IFRoaXMgcmVhZHMgdG8gbWUgbGlr ZSB0cmFtcGZkIGlzIG9ubHkgZGVhbGluZyB3aXRoIGEgZmV3IHNwZWNpYWwgY2FzZXMKPiBhbmQg d2Uga25vdyB0aGF0IHdlIG5lZWQgYSBtb3JlIGdlbmVyYWwgc29sdXRpb24uCj4gCj4gSSBob3Bl IEkgYW0gbWlzdGFrZW4sIGJ1dCBJIGdldCB0aGUgc3Ryb25nIGltcHJlc3Npb24gdGhhdCB5b3Un cmUgdHJ5aW5nCj4gdG8ganVzdGlmeSB5b3VyIGV4aXN0aW5nIHNvbHV0aW9uIHJhdGhlciB0aGFu IHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZQo+IHByb2JsZW0gc3BhY2UuCj4gCj4gVG8gYmUgY2xl YXIsIG15IHN0cm9uZyBvcGluaW9uIGlzIHRoYXQgd2Ugc2hvdWxkIG5vdCBiZSB0cnlpbmcgdG8g ZG8KPiB0aGlzIHNvcnQgb2YgZW11bGF0aW9uIG9yIGNvZGUgZ2VuZXJhdGlvbiB3aXRoaW4gdGhl IGtlcm5lbC4gSSBkbyB0aGluawo+IGl0J3Mgd29ydGh3aGlsZSB0byBsb29rIGF0IG1lY2hhbmlz bXMgdG8gbWFrZSBpdCBoYXJkZXIgdG8gc3VidmVydAo+IGR5bmFtaWMgdXNlcnNwYWNlIGNvZGUg Z2VuZXJhdGlvbiwgYnV0IEkgdGhpbmsgdGhlIGNvZGUgZ2VuZXJhdGlvbgo+IGl0c2VsZiBuZWVk cyB0byBsaXZlIGluIHVzZXJzcGFjZSAoZS5nLiBmb3IgQUJJIHJlYXNvbnMgSSBwcmV2aW91c2x5 Cj4gbWVudGlvbmVkKS4KPiAKPiBNYXJrLgo+IAoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgt YXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3Jn L21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=