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=-14.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 BF4DEC433E1 for ; Mon, 3 Aug 2020 17:58:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BAD7922B45 for ; Mon, 3 Aug 2020 17:58:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="RXbxzv5f" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727919AbgHCR6I (ORCPT ); Mon, 3 Aug 2020 13:58:08 -0400 Received: from linux.microsoft.com ([13.77.154.182]:57750 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726239AbgHCR6H (ORCPT ); Mon, 3 Aug 2020 13:58:07 -0400 Received: from [192.168.254.32] (unknown [47.187.206.220]) by linux.microsoft.com (Postfix) with ESMTPSA id 1BE0F20B4908; Mon, 3 Aug 2020 10:58:05 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1BE0F20B4908 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1596477485; bh=e9+Nlmg821uwNR6BTqHy8U85EfsNrcp1gJnhbkIF1W4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=RXbxzv5ftfCeBZYTZ1xOaEuahvu0ZmS3TsY3B2lI4zQPGveiClYJbXunf6jcxWTaE zFhjrT2haLCCDZOPDnzXPZzvwPGn/e9dRmYKvybo3iVmcR5qsA6AV9454a8D66mhxE NSONMrvO7N+B4rraB/9eOHnMcDsal+bCE+M/J1n0= Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: Mark Rutland Cc: Andy Lutomirski , Kernel Hardening , Linux API , linux-arm-kernel , Linux FS Devel , linux-integrity , LKML , LSM List , Oleg Nesterov , X86 ML References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <6540b4b7-3f70-adbf-c922-43886599713a@linux.microsoft.com> <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> <20200731183146.GD67415@C02TD0UTHF1T.local> From: "Madhavan T. Venkataraman" Message-ID: <86625441-80f3-2909-2f56-e18e2b60957d@linux.microsoft.com> Date: Mon, 3 Aug 2020 12:58:04 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200731183146.GD67415@C02TD0UTHF1T.local> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/31/20 1:31 PM, Mark Rutland wrote: > On Fri, Jul 31, 2020 at 12:13:49PM -0500, Madhavan T. Venkataraman wrote: >> On 7/30/20 3:54 PM, Andy Lutomirski wrote: >>> On Thu, Jul 30, 2020 at 7:24 AM Madhavan T. Venkataraman >>> wrote: >> Dealing with multiple architectures >> ----------------------------------------------- >> >> One good reason to use trampfd is multiple architecture support. The >> trampoline table in a code page approach is neat. I don't deny that at >> all. But my question is - can it be used in all cases? >> >> It requires PC-relative data references. I have not worked on all architectures. >> So, I need to study this. But do all ISAs support PC-relative data references? > Not all do, but pretty much any recent ISA will as it's a practical > necessity for fast position-independent code. So, two questions: 1. IIUC, for position independent code, we need PC-relative control transfers. I know that     PC-relative control transfers are kinda fundamental. So, I expect most architectures     support it. But to implement the trampoline table suggestion, we need PC-relative     data references. Like:     movq    X(%rip), %rax 2. Do you know which architectures do not support PC-relative data references? I am     going to study this. But if you have some information, I would appreciate it. In any case, I think we should support all of the architectures on which Linux currently runs even if they are legacy. > >> Even in an ISA that supports it, there would be a maximum supported offset >> from the current PC that can be reached for a data reference. That maximum >> needs to be at least the size of a base page in the architecture. This is because >> the code page and the data page need to be separate for security reasons. >> Do all ISAs support a sufficiently large offset? > ISAs with pc-relative addessing can usually generate PC-relative > addresses into a GPR, from which they can apply an arbitrarily large > offset. I will study this. I need to nail down the list of architectures that cannot do this. > >> When the kernel generates the code for a trampoline, it can hard code data values >> in the generated code itself so it does not need PC-relative data referencing. >> >> And, for ISAs that do support the large offset, we do have to implement and >> maintain the code page stuff for different ISAs for each application and library >> if we did not use trampfd. > Trampoline code is architecture specific today, so I don't see that as a > major issue. Common structural bits can probably be shared even if the > specifid machine code cannot. True. But an implementor may prefer a standard mechanism provided by the kernel so all of his architectures can be supported easily with less effort. If you look at the libffi reference patch I have included, the architecture specific changes to use trampfd just involve a single C function call to a common code function. So, from the point of view of adoption, IMHO, the kernel provided method is preferable. > > [...] > >> Security >> ----------- >> >> With the user level trampoline table approach, the data part of the trampoline table >> can be hacked by an attacker if an application has a vulnerability. Specifically, the >> target PC can be altered to some arbitrary location. Trampfd implements an >> "Allowed PCS" context. In the libffi changes, I have created a read-only array of >> all ABI handlers used in closures for each architecture. This read-only array >> can be used to restrict the PC values for libffi trampolines to prevent hacking. >> >> To generalize, we can implement security rules/features if the trampoline >> object is in the kernel. > I don't follow this argument. If it's possible to statically define that > in the kernel, it's also possible to do that in userspace without any > new kernel support. It is not statically defined in the kernel. Let us take the libffi example. In the 64-bit X86 arch code, there are 3 ABI handlers:     ffi_closure_unix64_sse     ffi_closure_unix64     ffi_closure_win64 I could create an "Allowed PCs" context like this: struct my_allowed_pcs {     struct trampfd_values    pcs;     __u64                             pc_values[3]; }; const struct my_allowed_pcs    my_allowed_pcs = {     { 3, 0 },     (uintptr_t) ffi_closure_unix64_sse,     (uintptr_t) ffi_closure_unix64,     (uintptr_t) ffi_closure_win64, }; I have created a read-only array of allowed ABI handlers that closures use. When I set up the context for a closure trampoline, I could do this:     pwrite(trampfd, &my_allowed_pcs, sizeof(my_allowed_pcs), TRAMPFD_ALLOWED_PCS_OFFSET);     This copies the array into the trampoline object in the kernel. When the register context is set for the trampoline, the kernel checks the PC register value against allowed PCs. Because my_allowed_pcs is read-only, a hacker cannot modify it. So, the only permitted target PCs enforced by the kernel are the ABI handlers. > > [...] > >> Trampfd is a framework that can be used to implement multiple things. May be, >> a few of those things can also be implemented in user land itself. But I think having >> just one mechanism to execute dynamic code objects is preferable to having >> multiple mechanisms not standardized across all applications. > In abstract, having a common interface sounds nice, but in practice > elements of this are always architecture-specific (e.g. interactiosn > with HW CFI), and that common interface can result in more pain as it > doesn't fit naturally into the context that ISAs were designed for (e.g. > where control-flow instructions are extended with new semantics). In the case of trampfd, the code generation is indeed architecture specific. But that is in the kernel. The application is not affected by it. Again, referring to the libffi reference patch, I have defined wrapper functions for trampfd in common code. The architecture specific code in libffi only calls the set_context function defined in common code. Even this is required only because register names are specific to each architecture and the target PC (to the ABI handler) is specific to each architecture-ABI combo. > It also meass that you can't share the rough approach across OSs which > do not implement an identical mechanism, so for code abstracting by ISA > first, then by platform/ABI, there isn't much saving. Why can you not share the same approach across OSes? In fact, I have tried to design it so that other OSes can use the same mechanism. The only thing is that I have defined the API to be based on a file descriptor since that is what is generally preferred by the Linux community for a new API. If I were to implement it as a regular system call, the same system call can be implemented in other OSes as well. Thanks. Madhavan 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 1EF8FC433DF for ; Mon, 3 Aug 2020 17:59:52 +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 4569D22B45 for ; Mon, 3 Aug 2020 17:59:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="V3DZDHt+"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="RXbxzv5f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4569D22B45 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com 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=KEtOlrfgG50BYAWsU5qGId37Qzp+MOJsOMhH6qoqT3c=; b=V3DZDHt+YFKoH9LF8xyVW2jaJ wZ8mEhBBEE8y+lM+i4E2PxK81zIXobVbUx/CopJlEl1RNgA1IkvvqJId9DCsiuHkaifHzYeyCwAxj AeLOHHUpzGoXqp7pA6EkmjNm1RAQOdwmFdR6iUGGaVVCBP/ZSYf34D2dza5TZNQkNPFORAmRuxYpE fslNL0CEYdeYRmjZcyanAvCkfzCHuOeHdMHShmTjJFEVthGs2D18V5CBZGB1Hbx4W8kPH/9PtfAgl 2VsOkOg0CwgiCIqLpKO5tJKFHvZbAUR74SDoSE6pAcece00ZChG/a9OvbRVdQEgHLkZai81bWKeX2 eCDYSC/6A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2eiw-0004vQ-PB; Mon, 03 Aug 2020 17:58:10 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2eit-0004uf-F3 for linux-arm-kernel@lists.infradead.org; Mon, 03 Aug 2020 17:58:08 +0000 Received: from [192.168.254.32] (unknown [47.187.206.220]) by linux.microsoft.com (Postfix) with ESMTPSA id 1BE0F20B4908; Mon, 3 Aug 2020 10:58:05 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1BE0F20B4908 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1596477485; bh=e9+Nlmg821uwNR6BTqHy8U85EfsNrcp1gJnhbkIF1W4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=RXbxzv5ftfCeBZYTZ1xOaEuahvu0ZmS3TsY3B2lI4zQPGveiClYJbXunf6jcxWTaE zFhjrT2haLCCDZOPDnzXPZzvwPGn/e9dRmYKvybo3iVmcR5qsA6AV9454a8D66mhxE NSONMrvO7N+B4rraB/9eOHnMcDsal+bCE+M/J1n0= Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor To: Mark Rutland References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <6540b4b7-3f70-adbf-c922-43886599713a@linux.microsoft.com> <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> <20200731183146.GD67415@C02TD0UTHF1T.local> From: "Madhavan T. Venkataraman" Message-ID: <86625441-80f3-2909-2f56-e18e2b60957d@linux.microsoft.com> Date: Mon, 3 Aug 2020 12:58:04 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200731183146.GD67415@C02TD0UTHF1T.local> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200803_135807_648452_83340C44 X-CRM114-Status: GOOD ( 34.62 ) 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 , Linux API , X86 ML , LKML , Oleg Nesterov , LSM List , Andy Lutomirski , Linux FS Devel , linux-integrity , linux-arm-kernel 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 CgpPbiA3LzMxLzIwIDE6MzEgUE0sIE1hcmsgUnV0bGFuZCB3cm90ZToKPiBPbiBGcmksIEp1bCAz MSwgMjAyMCBhdCAxMjoxMzo0OVBNIC0wNTAwLCBNYWRoYXZhbiBULiBWZW5rYXRhcmFtYW4gd3Jv dGU6Cj4+IE9uIDcvMzAvMjAgMzo1NCBQTSwgQW5keSBMdXRvbWlyc2tpIHdyb3RlOgo+Pj4gT24g VGh1LCBKdWwgMzAsIDIwMjAgYXQgNzoyNCBBTSBNYWRoYXZhbiBULiBWZW5rYXRhcmFtYW4KPj4+ IDxtYWR2ZW5rYUBsaW51eC5taWNyb3NvZnQuY29tPiB3cm90ZToKPj4gRGVhbGluZyB3aXRoIG11 bHRpcGxlIGFyY2hpdGVjdHVyZXMKPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KPj4KPj4gT25lIGdvb2QgcmVhc29uIHRvIHVzZSB0cmFtcGZkIGlzIG11 bHRpcGxlIGFyY2hpdGVjdHVyZSBzdXBwb3J0LiBUaGUKPj4gdHJhbXBvbGluZSB0YWJsZSBpbiBh IGNvZGUgcGFnZSBhcHByb2FjaCBpcyBuZWF0LiBJIGRvbid0IGRlbnkgdGhhdCBhdAo+PiBhbGwu IEJ1dCBteSBxdWVzdGlvbiBpcyAtIGNhbiBpdCBiZSB1c2VkIGluIGFsbCBjYXNlcz8KPj4KPj4g SXQgcmVxdWlyZXMgUEMtcmVsYXRpdmUgZGF0YSByZWZlcmVuY2VzLiBJIGhhdmUgbm90IHdvcmtl ZCBvbiBhbGwgYXJjaGl0ZWN0dXJlcy4KPj4gU28sIEkgbmVlZCB0byBzdHVkeSB0aGlzLiBCdXQg ZG8gYWxsIElTQXMgc3VwcG9ydCBQQy1yZWxhdGl2ZSBkYXRhIHJlZmVyZW5jZXM/Cj4gTm90IGFs bCBkbywgYnV0IHByZXR0eSBtdWNoIGFueSByZWNlbnQgSVNBIHdpbGwgYXMgaXQncyBhIHByYWN0 aWNhbAo+IG5lY2Vzc2l0eSBmb3IgZmFzdCBwb3NpdGlvbi1pbmRlcGVuZGVudCBjb2RlLgoKU28s IHR3byBxdWVzdGlvbnM6CgoxLiBJSVVDLCBmb3IgcG9zaXRpb24gaW5kZXBlbmRlbnQgY29kZSwg d2UgbmVlZCBQQy1yZWxhdGl2ZSBjb250cm9sIHRyYW5zZmVycy4gSSBrbm93IHRoYXQKwqDCoMKg IFBDLXJlbGF0aXZlIGNvbnRyb2wgdHJhbnNmZXJzIGFyZSBraW5kYSBmdW5kYW1lbnRhbC4gU28s IEkgZXhwZWN0IG1vc3QgYXJjaGl0ZWN0dXJlcwrCoMKgwqAgc3VwcG9ydCBpdC4gQnV0IHRvIGlt cGxlbWVudCB0aGUgdHJhbXBvbGluZSB0YWJsZSBzdWdnZXN0aW9uLCB3ZSBuZWVkIFBDLXJlbGF0 aXZlCsKgwqDCoCBkYXRhIHJlZmVyZW5jZXMuIExpa2U6CgrCoMKgwqAgbW92ccKgwqDCoCBYKCVy aXApLCAlcmF4CgoyLiBEbyB5b3Uga25vdyB3aGljaCBhcmNoaXRlY3R1cmVzIGRvIG5vdCBzdXBw b3J0IFBDLXJlbGF0aXZlIGRhdGEgcmVmZXJlbmNlcz8gSSBhbQrCoMKgwqAgZ29pbmcgdG8gc3R1 ZHkgdGhpcy4gQnV0IGlmIHlvdSBoYXZlIHNvbWUgaW5mb3JtYXRpb24sIEkgd291bGQgYXBwcmVj aWF0ZSBpdC4KCkluIGFueSBjYXNlLCBJIHRoaW5rIHdlIHNob3VsZCBzdXBwb3J0IGFsbCBvZiB0 aGUgYXJjaGl0ZWN0dXJlcyBvbiB3aGljaCBMaW51eCBjdXJyZW50bHkKcnVucyBldmVuIGlmIHRo ZXkgYXJlIGxlZ2FjeS4KCj4KPj4gRXZlbiBpbiBhbiBJU0EgdGhhdCBzdXBwb3J0cyBpdCwgdGhl cmUgd291bGQgYmUgYSBtYXhpbXVtIHN1cHBvcnRlZCBvZmZzZXQKPj4gZnJvbSB0aGUgY3VycmVu dCBQQyB0aGF0IGNhbiBiZSByZWFjaGVkIGZvciBhIGRhdGEgcmVmZXJlbmNlLiBUaGF0IG1heGlt dW0KPj4gbmVlZHMgdG8gYmUgYXQgbGVhc3QgdGhlIHNpemUgb2YgYSBiYXNlIHBhZ2UgaW4gdGhl IGFyY2hpdGVjdHVyZS4gVGhpcyBpcyBiZWNhdXNlCj4+IHRoZSBjb2RlIHBhZ2UgYW5kIHRoZSBk YXRhIHBhZ2UgbmVlZCB0byBiZSBzZXBhcmF0ZSBmb3Igc2VjdXJpdHkgcmVhc29ucy4KPj4gRG8g YWxsIElTQXMgc3VwcG9ydCBhIHN1ZmZpY2llbnRseSBsYXJnZSBvZmZzZXQ/Cj4gSVNBcyB3aXRo IHBjLXJlbGF0aXZlIGFkZGVzc2luZyBjYW4gdXN1YWxseSBnZW5lcmF0ZSBQQy1yZWxhdGl2ZQo+ IGFkZHJlc3NlcyBpbnRvIGEgR1BSLCBmcm9tIHdoaWNoIHRoZXkgY2FuIGFwcGx5IGFuIGFyYml0 cmFyaWx5IGxhcmdlCj4gb2Zmc2V0LgoKSSB3aWxsIHN0dWR5IHRoaXMuIEkgbmVlZCB0byBuYWls IGRvd24gdGhlIGxpc3Qgb2YgYXJjaGl0ZWN0dXJlcyB0aGF0IGNhbm5vdCBkbyB0aGlzLgoKPgo+ PiBXaGVuIHRoZSBrZXJuZWwgZ2VuZXJhdGVzIHRoZSBjb2RlIGZvciBhIHRyYW1wb2xpbmUsIGl0 IGNhbiBoYXJkIGNvZGUgZGF0YSB2YWx1ZXMKPj4gaW4gdGhlIGdlbmVyYXRlZCBjb2RlIGl0c2Vs ZiBzbyBpdCBkb2VzIG5vdCBuZWVkIFBDLXJlbGF0aXZlIGRhdGEgcmVmZXJlbmNpbmcuCj4+Cj4+ IEFuZCwgZm9yIElTQXMgdGhhdCBkbyBzdXBwb3J0IHRoZSBsYXJnZSBvZmZzZXQsIHdlIGRvIGhh dmUgdG8gaW1wbGVtZW50IGFuZAo+PiBtYWludGFpbiB0aGUgY29kZSBwYWdlIHN0dWZmIGZvciBk aWZmZXJlbnQgSVNBcyBmb3IgZWFjaCBhcHBsaWNhdGlvbiBhbmQgbGlicmFyeQo+PiBpZiB3ZSBk aWQgbm90IHVzZSB0cmFtcGZkLgo+IFRyYW1wb2xpbmUgY29kZSBpcyBhcmNoaXRlY3R1cmUgc3Bl Y2lmaWMgdG9kYXksIHNvIEkgZG9uJ3Qgc2VlIHRoYXQgYXMgYQo+IG1ham9yIGlzc3VlLiBDb21t b24gc3RydWN0dXJhbCBiaXRzIGNhbiBwcm9iYWJseSBiZSBzaGFyZWQgZXZlbiBpZiB0aGUKPiBz cGVjaWZpZCBtYWNoaW5lIGNvZGUgY2Fubm90LgoKVHJ1ZS4gQnV0IGFuIGltcGxlbWVudG9yIG1h eSBwcmVmZXIgYSBzdGFuZGFyZCBtZWNoYW5pc20gcHJvdmlkZWQgYnkKdGhlIGtlcm5lbCBzbyBh bGwgb2YgaGlzIGFyY2hpdGVjdHVyZXMgY2FuIGJlIHN1cHBvcnRlZCBlYXNpbHkgd2l0aCBsZXNz CmVmZm9ydC4KCklmIHlvdSBsb29rIGF0IHRoZSBsaWJmZmkgcmVmZXJlbmNlIHBhdGNoIEkgaGF2 ZSBpbmNsdWRlZCwgdGhlIGFyY2hpdGVjdHVyZQpzcGVjaWZpYyBjaGFuZ2VzIHRvIHVzZSB0cmFt cGZkIGp1c3QgaW52b2x2ZSBhIHNpbmdsZSBDIGZ1bmN0aW9uIGNhbGwgdG8KYSBjb21tb24gY29k ZSBmdW5jdGlvbi4KClNvLCBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGFkb3B0aW9uLCBJTUhP LCB0aGUga2VybmVsIHByb3ZpZGVkIG1ldGhvZAppcyBwcmVmZXJhYmxlLgoKPgo+IFsuLi5dCj4K Pj4gU2VjdXJpdHkKPj4gLS0tLS0tLS0tLS0KPj4KPj4gV2l0aCB0aGUgdXNlciBsZXZlbCB0cmFt cG9saW5lIHRhYmxlIGFwcHJvYWNoLCB0aGUgZGF0YSBwYXJ0IG9mIHRoZSB0cmFtcG9saW5lIHRh YmxlCj4+IGNhbiBiZSBoYWNrZWQgYnkgYW4gYXR0YWNrZXIgaWYgYW4gYXBwbGljYXRpb24gaGFz IGEgdnVsbmVyYWJpbGl0eS4gU3BlY2lmaWNhbGx5LCB0aGUKPj4gdGFyZ2V0IFBDIGNhbiBiZSBh bHRlcmVkIHRvIHNvbWUgYXJiaXRyYXJ5IGxvY2F0aW9uLiBUcmFtcGZkIGltcGxlbWVudHMgYW4K Pj4gIkFsbG93ZWQgUENTIiBjb250ZXh0LiBJbiB0aGUgbGliZmZpIGNoYW5nZXMsIEkgaGF2ZSBj cmVhdGVkIGEgcmVhZC1vbmx5IGFycmF5IG9mCj4+IGFsbCBBQkkgaGFuZGxlcnMgdXNlZCBpbiBj bG9zdXJlcyBmb3IgZWFjaCBhcmNoaXRlY3R1cmUuIFRoaXMgcmVhZC1vbmx5IGFycmF5Cj4+IGNh biBiZSB1c2VkIHRvIHJlc3RyaWN0IHRoZSBQQyB2YWx1ZXMgZm9yIGxpYmZmaSB0cmFtcG9saW5l cyB0byBwcmV2ZW50IGhhY2tpbmcuCj4+Cj4+IFRvIGdlbmVyYWxpemUsIHdlIGNhbiBpbXBsZW1l bnQgc2VjdXJpdHkgcnVsZXMvZmVhdHVyZXMgaWYgdGhlIHRyYW1wb2xpbmUKPj4gb2JqZWN0IGlz IGluIHRoZSBrZXJuZWwuCj4gSSBkb24ndCBmb2xsb3cgdGhpcyBhcmd1bWVudC4gSWYgaXQncyBw b3NzaWJsZSB0byBzdGF0aWNhbGx5IGRlZmluZSB0aGF0Cj4gaW4gdGhlIGtlcm5lbCwgaXQncyBh bHNvIHBvc3NpYmxlIHRvIGRvIHRoYXQgaW4gdXNlcnNwYWNlIHdpdGhvdXQgYW55Cj4gbmV3IGtl cm5lbCBzdXBwb3J0LgpJdCBpcyBub3Qgc3RhdGljYWxseSBkZWZpbmVkIGluIHRoZSBrZXJuZWwu CgpMZXQgdXMgdGFrZSB0aGUgbGliZmZpIGV4YW1wbGUuIEluIHRoZSA2NC1iaXQgWDg2IGFyY2gg Y29kZSwgdGhlcmUgYXJlIDMKQUJJIGhhbmRsZXJzOgoKwqDCoMKgIGZmaV9jbG9zdXJlX3VuaXg2 NF9zc2UKwqDCoMKgIGZmaV9jbG9zdXJlX3VuaXg2NArCoMKgwqAgZmZpX2Nsb3N1cmVfd2luNjQK CkkgY291bGQgY3JlYXRlIGFuICJBbGxvd2VkIFBDcyIgY29udGV4dCBsaWtlIHRoaXM6CgpzdHJ1 Y3QgbXlfYWxsb3dlZF9wY3MgewrCoMKgwqAgc3RydWN0IHRyYW1wZmRfdmFsdWVzIMKgwqAgcGNz OwrCoMKgwqAgX191NjTCoMKgwqAgwqDCoMKgIMKgwqDCoCDCoMKgwqAgwqDCoMKgIMKgwqDCoMKg IMKgwqDCoCBwY192YWx1ZXNbM107Cn07Cgpjb25zdCBzdHJ1Y3QgbXlfYWxsb3dlZF9wY3PCoMKg wqAgbXlfYWxsb3dlZF9wY3MgPSB7CsKgwqDCoCB7IDMsIDAgfSwKwqDCoMKgICh1aW50cHRyX3Qp IGZmaV9jbG9zdXJlX3VuaXg2NF9zc2UsCsKgwqDCoCAodWludHB0cl90KSBmZmlfY2xvc3VyZV91 bml4NjQsCsKgwqDCoCAodWludHB0cl90KSBmZmlfY2xvc3VyZV93aW42NCwKfTsKCkkgaGF2ZSBj cmVhdGVkIGEgcmVhZC1vbmx5IGFycmF5IG9mIGFsbG93ZWQgQUJJIGhhbmRsZXJzIHRoYXQgY2xv c3VyZXMgdXNlLgoKV2hlbiBJIHNldCB1cCB0aGUgY29udGV4dCBmb3IgYSBjbG9zdXJlIHRyYW1w b2xpbmUsIEkgY291bGQgZG8gdGhpczoKCsKgwqDCoCBwd3JpdGUodHJhbXBmZCwgJm15X2FsbG93 ZWRfcGNzLCBzaXplb2YobXlfYWxsb3dlZF9wY3MpLCBUUkFNUEZEX0FMTE9XRURfUENTX09GRlNF VCk7CsKgwqDCoApUaGlzIGNvcGllcyB0aGUgYXJyYXkgaW50byB0aGUgdHJhbXBvbGluZSBvYmpl Y3QgaW4gdGhlIGtlcm5lbC4KV2hlbiB0aGUgcmVnaXN0ZXIgY29udGV4dCBpcyBzZXQgZm9yIHRo ZSB0cmFtcG9saW5lLCB0aGUga2VybmVsIGNoZWNrcwp0aGUgUEMgcmVnaXN0ZXIgdmFsdWUgYWdh aW5zdCBhbGxvd2VkIFBDcy4KCkJlY2F1c2UgbXlfYWxsb3dlZF9wY3MgaXMgcmVhZC1vbmx5LCBh IGhhY2tlciBjYW5ub3QgbW9kaWZ5IGl0LiBTbywgdGhlIG9ubHkKcGVybWl0dGVkIHRhcmdldCBQ Q3MgZW5mb3JjZWQgYnkgdGhlIGtlcm5lbCBhcmUgdGhlIEFCSSBoYW5kbGVycy4KPgo+IFsuLi5d Cj4KPj4gVHJhbXBmZCBpcyBhIGZyYW1ld29yayB0aGF0IGNhbiBiZSB1c2VkIHRvIGltcGxlbWVu dCBtdWx0aXBsZSB0aGluZ3MuIE1heSBiZSwKPj4gYSBmZXcgb2YgdGhvc2UgdGhpbmdzIGNhbiBh bHNvIGJlIGltcGxlbWVudGVkIGluIHVzZXIgbGFuZCBpdHNlbGYuIEJ1dCBJIHRoaW5rIGhhdmlu Zwo+PiBqdXN0IG9uZSBtZWNoYW5pc20gdG8gZXhlY3V0ZSBkeW5hbWljIGNvZGUgb2JqZWN0cyBp cyBwcmVmZXJhYmxlIHRvIGhhdmluZwo+PiBtdWx0aXBsZSBtZWNoYW5pc21zIG5vdCBzdGFuZGFy ZGl6ZWQgYWNyb3NzIGFsbCBhcHBsaWNhdGlvbnMuCj4gSW4gYWJzdHJhY3QsIGhhdmluZyBhIGNv bW1vbiBpbnRlcmZhY2Ugc291bmRzIG5pY2UsIGJ1dCBpbiBwcmFjdGljZQo+IGVsZW1lbnRzIG9m IHRoaXMgYXJlIGFsd2F5cyBhcmNoaXRlY3R1cmUtc3BlY2lmaWMgKGUuZy4gaW50ZXJhY3Rpb3Nu Cj4gd2l0aCBIVyBDRkkpLCBhbmQgdGhhdCBjb21tb24gaW50ZXJmYWNlIGNhbiByZXN1bHQgaW4g bW9yZSBwYWluIGFzIGl0Cj4gZG9lc24ndCBmaXQgbmF0dXJhbGx5IGludG8gdGhlIGNvbnRleHQg dGhhdCBJU0FzIHdlcmUgZGVzaWduZWQgZm9yIChlLmcuIAo+IHdoZXJlIGNvbnRyb2wtZmxvdyBp bnN0cnVjdGlvbnMgYXJlIGV4dGVuZGVkIHdpdGggbmV3IHNlbWFudGljcykuCgpJbiB0aGUgY2Fz ZSBvZiB0cmFtcGZkLCB0aGUgY29kZSBnZW5lcmF0aW9uIGlzIGluZGVlZCBhcmNoaXRlY3R1cmUK c3BlY2lmaWMuIEJ1dCB0aGF0IGlzIGluIHRoZSBrZXJuZWwuIFRoZSBhcHBsaWNhdGlvbiBpcyBu b3QgYWZmZWN0ZWQgYnkgaXQuCgpBZ2FpbiwgcmVmZXJyaW5nIHRvIHRoZSBsaWJmZmkgcmVmZXJl bmNlIHBhdGNoLCBJIGhhdmUgZGVmaW5lZCB3cmFwcGVyCmZ1bmN0aW9ucyBmb3IgdHJhbXBmZCBp biBjb21tb24gY29kZS4gVGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpYyBjb2RlCmluIGxpYmZmaSBv bmx5IGNhbGxzIHRoZSBzZXRfY29udGV4dCBmdW5jdGlvbiBkZWZpbmVkIGluIGNvbW1vbiBjb2Rl LgpFdmVuIHRoaXMgaXMgcmVxdWlyZWQgb25seSBiZWNhdXNlIHJlZ2lzdGVyIG5hbWVzIGFyZSBz cGVjaWZpYyB0byBlYWNoCmFyY2hpdGVjdHVyZSBhbmQgdGhlIHRhcmdldCBQQyAodG8gdGhlIEFC SSBoYW5kbGVyKSBpcyBzcGVjaWZpYyB0bwplYWNoIGFyY2hpdGVjdHVyZS1BQkkgY29tYm8uCgo+ IEl0IGFsc28gbWVhc3MgdGhhdCB5b3UgY2FuJ3Qgc2hhcmUgdGhlIHJvdWdoIGFwcHJvYWNoIGFj cm9zcyBPU3Mgd2hpY2gKPiBkbyBub3QgaW1wbGVtZW50IGFuIGlkZW50aWNhbCBtZWNoYW5pc20s IHNvIGZvciBjb2RlIGFic3RyYWN0aW5nIGJ5IElTQQo+IGZpcnN0LCB0aGVuIGJ5IHBsYXRmb3Jt L0FCSSwgdGhlcmUgaXNuJ3QgbXVjaCBzYXZpbmcuCgpXaHkgY2FuIHlvdSBub3Qgc2hhcmUgdGhl IHNhbWUgYXBwcm9hY2ggYWNyb3NzIE9TZXM/IEluIGZhY3QsCkkgaGF2ZSB0cmllZCB0byBkZXNp Z24gaXQgc28gdGhhdCBvdGhlciBPU2VzIGNhbiB1c2UgdGhlIHNhbWUKbWVjaGFuaXNtLgoKVGhl IG9ubHkgdGhpbmcgaXMgdGhhdCBJIGhhdmUgZGVmaW5lZCB0aGUgQVBJIHRvIGJlIGJhc2VkIG9u IGEgZmlsZQpkZXNjcmlwdG9yIHNpbmNlIHRoYXQgaXMgd2hhdCBpcyBnZW5lcmFsbHkgcHJlZmVy cmVkIGJ5IHRoZSBMaW51eCBjb21tdW5pdHkKZm9yIGEgbmV3IEFQSS4gSWYgSSB3ZXJlIHRvIGlt cGxlbWVudCBpdCBhcyBhIHJlZ3VsYXIgc3lzdGVtIGNhbGwsIHRoZSBzYW1lCnN5c3RlbSBjYWxs IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiBvdGhlciBPU2VzIGFzIHdlbGwuCgpUaGFua3MuCgpNYWRo YXZhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlu dXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRl YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgt YXJtLWtlcm5lbAo=