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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT 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 B6CB5C28CF6 for ; Wed, 1 Aug 2018 07:57:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D5C020844 for ; Wed, 1 Aug 2018 07:57:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linaro.org header.i=@linaro.org header.b="eYMwe0nz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D5C020844 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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 S2387685AbeHAJmP (ORCPT ); Wed, 1 Aug 2018 05:42:15 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:37091 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732300AbeHAJmP (ORCPT ); Wed, 1 Aug 2018 05:42:15 -0400 Received: by mail-pl0-f68.google.com with SMTP id d5-v6so2868133pll.4 for ; Wed, 01 Aug 2018 00:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=tviqsjnYm6JkTD8v8bbf5gM3ouCSX3rUG3lP/f5N5go=; b=eYMwe0nzcZ7WpLcKE9rgjpcaFRJLj9sY2LcVA2yZUorAABiK3HOJy20/PQl5F9+NpO xQfOrKmoAfpjKJSNibuw4HW0Kobe8vH79/UXyCkwFWfgAXcxcih7/AahHPjqbIFISZDA ERx1R109UYQkCp02WyYm9X8BOMaOhts1F2K68= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=tviqsjnYm6JkTD8v8bbf5gM3ouCSX3rUG3lP/f5N5go=; b=tjpGK3ocWVMErma4/LzIWsMV6iOxjjVST3XRZY0imQOC+39j4DH0PIq33o0VahJYWN Wc+/qW/LH0QPF9NqRlVAvsln9fRGsQfrOi3drNRjBR0drzKCseNS1DOWoisSWNQIEXuT koBW8Ij2qMGvVpuHuA47+6axPs5ZsXBmzIQzK8B4idfHIb2wO0/lFyxJjsQsPz+ctV95 Z/6C9X+rCC7hrUN4KCaQdFI0IBIJk6/t+mAsc6HmkiaixOVXZYWqiVw+5zXrBVVJ/c6z kONoadTnDgUvdhaXWWK47ov3asMExRslYOBz7r7kmbR2YXSvVxH95TmlH+zIw1draQin kz+w== X-Gm-Message-State: AOUpUlE/cNuE3WvaINNg3z+2NXFKIIv8f7+2bYoQLVWWQfXx6BnsK4U+ DeE9o6kKWX/r4sW9eu6E6TOBlw== X-Google-Smtp-Source: AAOMgpftsyoeqTZLNtPwS7Nkuc0aao6dJw1DULHnnQZr4BHK3nWr/d2WdA9Uw6zrh5iCLctz9magNA== X-Received: by 2002:a17:902:b28c:: with SMTP id u12-v6mr23178323plr.16.1533110269530; Wed, 01 Aug 2018 00:57:49 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id k64-v6sm32130864pfg.141.2018.08.01.00.57.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 00:57:48 -0700 (PDT) Date: Wed, 1 Aug 2018 16:57:21 +0900 From: AKASHI Takahiro To: James Morse Cc: catalin.marinas@arm.com, will.deacon@arm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v12 16/16] arm64: kexec_file: add kaslr support Message-ID: <20180801075720.GM11258@linaro.org> Mail-Followup-To: AKASHI Takahiro , James Morse , catalin.marinas@arm.com, will.deacon@arm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20180724065759.19186-1-takahiro.akashi@linaro.org> <20180724065759.19186-17-takahiro.akashi@linaro.org> <50b31f17-fc85-aa72-06f5-d3b62060a91f@arm.com> <20180727083104.GI11258@linaro.org> <405b6708-4518-d81e-3938-39032c2b487e@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <405b6708-4518-d81e-3938-39032c2b487e@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James, All the changes mentioned below were applied to my coming v13. On Fri, Jul 27, 2018 at 10:22:31AM +0100, James Morse wrote: > Hi Akashi, > > > On 07/27/2018 09:31 AM, AKASHI Takahiro wrote: > >On Thu, Jul 26, 2018 at 02:40:49PM +0100, James Morse wrote: > >>On 24/07/18 07:57, AKASHI Takahiro wrote: > >>>Adding "kaslr-seed" to dtb enables triggering kaslr, or kernel virtual > >>>address randomization, at secondary kernel boot. > >>Hmm, there are three things that get moved by CONFIG_RANDOMIZE_BASE. The kernel > >>physical placement when booted via the EFIstub, the kernel-text VAs and the > >>location of memory in the linear-map region. Adding the kaslr-seed only does the > >>last two. > >Yes, but I think that I and Mark has agreed that "kaslr" meant > >"virtual" randomisation, not including "physical" randomisation. > Okay, I'll update my terminology! > > > >>This means the physical placement of the new kernel is predictable from > >>/proc/iomem ... but this also tells you the physical placement of the current > >>kernel, so I don't think this is a problem. > >> > >> > >>>We always do this as it will have no harm on kaslr-incapable kernel. > >>>We don't have any "switch" to turn off this feature directly, but still > >>>can suppress it by passing "nokaslr" as a kernel boot argument. > >> > >>>diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c > >>>index 7356da5a53d5..47a4fbd0dc34 100644 > >>>--- a/arch/arm64/kernel/machine_kexec_file.c > >>>+++ b/arch/arm64/kernel/machine_kexec_file.c > >>>@@ -158,6 +160,12 @@ static int setup_dtb(struct kimage *image, > >>Don't you need to reserve some space in the area you vmalloc()d for the DT? > >No, I don't think so. > >All the data to be loaded are temporarily saved in kexec buffers, > >which will eventually be copied to target locations in machine_kexec > >(arm64_relocate_new_kernel, which, unlike its name, will handle > >not only kernel but also other data as well). > > I think we're speaking at cross purposes. Don't you need: > > | buf_size += fdt_prop_len("kaslr―seed", sizeof(u64)); > > > You can't assume the existing DTB had a kaslr-seed property, and the > difference may take us over a PAGE_SIZE boundary. I see, I will add that. > > > > >> > >>>+ /* add kaslr-seed */ > >>>+ get_random_bytes(&value, sizeof(value)); > >>What happens if the crng isn't ready? > >> > >>It looks like this will print a warning that these random-bytes aren't really up > >>to standard, but the new kernel doesn't know this happened. > >> > >>crng_ready() isn't exposed, all we could do now is > >>wait_for_random_bytes(), but that may wait forever because we do this > >>unconditionally. > >> > >>I'd prefer to leave this feature until we can check crng_ready(), and skip > >>adding a dodgy-seed if its not-ready. This avoids polluting the next-kernel's > >>entropy pool. > >OK. I would try to follow the same way as Bhupesh's userspace patch > >does for kaslr-seed: > >http://lists.infradead.org/pipermail/kexec/2018-April/020564.html > > (I really don't understand this 'copying code from user-space' that happens > with kexec_file_load) > > > > if (not found kaslr-seed in 1st kernel's dtb) > > don't care; go ahead > > Don' t bother. As you say in the commit-message its harmless if the new > kernel doesn't support it. > Always having this would let you use kexec_file_load as a bootloader that > can get the crng to > provide decent entropy even if the platform bootloader can't. OK, but anyway previous "kaslr-seed" will be dropped first. > > > else > > if (current kaslr-seed != 0) > > error > > Don't bother. If this happens its a bug in another part of the kernel that > doesn't affect this one. We aren't second-guessing the file-system when we > read the kernel-fd, lets keep this simple. OK > > if (crng_ready()) ; FIXME, it's a local macro > > get_random_bytes(non-blocking) > > set new kaslr-seed > > else > > error > error? Something like pr_warn_once(). It was changed to pr_notice() since there is nothing wrong. Thanks, -Takahiro AKASHI > I thought the kaslr-seed was added to the entropy pool, but now I look again > I see its a separate EFI table. So the new kernel will add the same entropy > ... that doesn't sound clever. (I can't see where its zero'd or > re-initialised) > > > > Thanks, > > James From mboxrd@z Thu Jan 1 00:00:00 1970 From: takahiro.akashi@linaro.org (AKASHI Takahiro) Date: Wed, 1 Aug 2018 16:57:21 +0900 Subject: [PATCH v12 16/16] arm64: kexec_file: add kaslr support In-Reply-To: <405b6708-4518-d81e-3938-39032c2b487e@arm.com> References: <20180724065759.19186-1-takahiro.akashi@linaro.org> <20180724065759.19186-17-takahiro.akashi@linaro.org> <50b31f17-fc85-aa72-06f5-d3b62060a91f@arm.com> <20180727083104.GI11258@linaro.org> <405b6708-4518-d81e-3938-39032c2b487e@arm.com> Message-ID: <20180801075720.GM11258@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org James, All the changes mentioned below were applied to my coming v13. On Fri, Jul 27, 2018 at 10:22:31AM +0100, James Morse wrote: > Hi Akashi, > > > On 07/27/2018 09:31 AM, AKASHI Takahiro wrote: > >On Thu, Jul 26, 2018 at 02:40:49PM +0100, James Morse wrote: > >>On 24/07/18 07:57, AKASHI Takahiro wrote: > >>>Adding "kaslr-seed" to dtb enables triggering kaslr, or kernel virtual > >>>address randomization, at secondary kernel boot. > >>Hmm, there are three things that get moved by CONFIG_RANDOMIZE_BASE. The kernel > >>physical placement when booted via the EFIstub, the kernel-text VAs and the > >>location of memory in the linear-map region. Adding the kaslr-seed only does the > >>last two. > >Yes, but I think that I and Mark has agreed that "kaslr" meant > >"virtual" randomisation, not including "physical" randomisation. > Okay, I'll update my terminology! > > > >>This means the physical placement of the new kernel is predictable from > >>/proc/iomem ... but this also tells you the physical placement of the current > >>kernel, so I don't think this is a problem. > >> > >> > >>>We always do this as it will have no harm on kaslr-incapable kernel. > >>>We don't have any "switch" to turn off this feature directly, but still > >>>can suppress it by passing "nokaslr" as a kernel boot argument. > >> > >>>diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c > >>>index 7356da5a53d5..47a4fbd0dc34 100644 > >>>--- a/arch/arm64/kernel/machine_kexec_file.c > >>>+++ b/arch/arm64/kernel/machine_kexec_file.c > >>>@@ -158,6 +160,12 @@ static int setup_dtb(struct kimage *image, > >>Don't you need to reserve some space in the area you vmalloc()d for the DT? > >No, I don't think so. > >All the data to be loaded are temporarily saved in kexec buffers, > >which will eventually be copied to target locations in machine_kexec > >(arm64_relocate_new_kernel, which, unlike its name, will handle > >not only kernel but also other data as well). > > I think we're speaking at cross purposes. Don't you need: > > | buf_size += fdt_prop_len("kaslr?seed", sizeof(u64)); > > > You can't assume the existing DTB had a kaslr-seed property, and the > difference may take us over a PAGE_SIZE boundary. I see, I will add that. > > > > >> > >>>+ /* add kaslr-seed */ > >>>+ get_random_bytes(&value, sizeof(value)); > >>What happens if the crng isn't ready? > >> > >>It looks like this will print a warning that these random-bytes aren't really up > >>to standard, but the new kernel doesn't know this happened. > >> > >>crng_ready() isn't exposed, all we could do now is > >>wait_for_random_bytes(), but that may wait forever because we do this > >>unconditionally. > >> > >>I'd prefer to leave this feature until we can check crng_ready(), and skip > >>adding a dodgy-seed if its not-ready. This avoids polluting the next-kernel's > >>entropy pool. > >OK. I would try to follow the same way as Bhupesh's userspace patch > >does for kaslr-seed: > >http://lists.infradead.org/pipermail/kexec/2018-April/020564.html > > (I really don't understand this 'copying code from user-space' that happens > with kexec_file_load) > > > > if (not found kaslr-seed in 1st kernel's dtb) > > don't care; go ahead > > Don' t bother. As you say in the commit-message its harmless if the new > kernel doesn't support it. > Always having this would let you use kexec_file_load as a bootloader that > can get the crng to > provide decent entropy even if the platform bootloader can't. OK, but anyway previous "kaslr-seed" will be dropped first. > > > else > > if (current kaslr-seed != 0) > > error > > Don't bother. If this happens its a bug in another part of the kernel that > doesn't affect this one. We aren't second-guessing the file-system when we > read the kernel-fd, lets keep this simple. OK > > if (crng_ready()) ; FIXME, it's a local macro > > get_random_bytes(non-blocking) > > set new kaslr-seed > > else > > error > error? Something like pr_warn_once(). It was changed to pr_notice() since there is nothing wrong. Thanks, -Takahiro AKASHI > I thought the kaslr-seed was added to the entropy pool, but now I look again > I see its a separate EFI table. So the new kernel will add the same entropy > ... that doesn't sound clever. (I can't see where its zero'd or > re-initialised) > > > > Thanks, > > James From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pl0-x241.google.com ([2607:f8b0:400e:c01::241]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fkm1A-00027x-Nj for kexec@lists.infradead.org; Wed, 01 Aug 2018 07:58:02 +0000 Received: by mail-pl0-x241.google.com with SMTP id m1-v6so8396056plt.6 for ; Wed, 01 Aug 2018 00:57:49 -0700 (PDT) Date: Wed, 1 Aug 2018 16:57:21 +0900 From: AKASHI Takahiro Subject: Re: [PATCH v12 16/16] arm64: kexec_file: add kaslr support Message-ID: <20180801075720.GM11258@linaro.org> References: <20180724065759.19186-1-takahiro.akashi@linaro.org> <20180724065759.19186-17-takahiro.akashi@linaro.org> <50b31f17-fc85-aa72-06f5-d3b62060a91f@arm.com> <20180727083104.GI11258@linaro.org> <405b6708-4518-d81e-3938-39032c2b487e@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <405b6708-4518-d81e-3938-39032c2b487e@arm.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: James Morse Cc: herbert@gondor.apana.org.au, bhe@redhat.com, ard.biesheuvel@linaro.org, catalin.marinas@arm.com, bhsharma@redhat.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, heiko.carstens@de.ibm.com, dhowells@redhat.com, arnd@arndb.de, linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org, schwidefsky@de.ibm.com, dyoung@redhat.com, davem@davemloft.net, vgoyal@redhat.com SmFtZXMsCgpBbGwgdGhlIGNoYW5nZXMgbWVudGlvbmVkIGJlbG93IHdlcmUgYXBwbGllZCB0byBt eSBjb21pbmcgdjEzLgoKT24gRnJpLCBKdWwgMjcsIDIwMTggYXQgMTA6MjI6MzFBTSArMDEwMCwg SmFtZXMgTW9yc2Ugd3JvdGU6Cj4gSGkgQWthc2hpLAo+IAo+IAo+IE9uIDA3LzI3LzIwMTggMDk6 MzEgQU0sIEFLQVNISSBUYWthaGlybyB3cm90ZToKPiA+T24gVGh1LCBKdWwgMjYsIDIwMTggYXQg MDI6NDA6NDlQTSArMDEwMCwgSmFtZXMgTW9yc2Ugd3JvdGU6Cj4gPj5PbiAyNC8wNy8xOCAwNzo1 NywgQUtBU0hJIFRha2FoaXJvIHdyb3RlOgo+ID4+PkFkZGluZyAia2FzbHItc2VlZCIgdG8gZHRi IGVuYWJsZXMgdHJpZ2dlcmluZyBrYXNsciwgb3Iga2VybmVsIHZpcnR1YWwKPiA+Pj5hZGRyZXNz IHJhbmRvbWl6YXRpb24sIGF0IHNlY29uZGFyeSBrZXJuZWwgYm9vdC4KPiA+PkhtbSwgdGhlcmUg YXJlIHRocmVlIHRoaW5ncyB0aGF0IGdldCBtb3ZlZCBieSBDT05GSUdfUkFORE9NSVpFX0JBU0Uu IFRoZSBrZXJuZWwKPiA+PnBoeXNpY2FsIHBsYWNlbWVudCB3aGVuIGJvb3RlZCB2aWEgdGhlIEVG SXN0dWIsIHRoZSBrZXJuZWwtdGV4dCBWQXMgYW5kIHRoZQo+ID4+bG9jYXRpb24gb2YgbWVtb3J5 IGluIHRoZSBsaW5lYXItbWFwIHJlZ2lvbi4gQWRkaW5nIHRoZSBrYXNsci1zZWVkIG9ubHkgZG9l cyB0aGUKPiA+Pmxhc3QgdHdvLgo+ID5ZZXMsIGJ1dCBJIHRoaW5rIHRoYXQgSSBhbmQgTWFyayBo YXMgYWdyZWVkIHRoYXQgImthc2xyIiBtZWFudAo+ID4idmlydHVhbCIgcmFuZG9taXNhdGlvbiwg bm90IGluY2x1ZGluZyAicGh5c2ljYWwiIHJhbmRvbWlzYXRpb24uCj4gT2theSwgSSdsbCB1cGRh dGUgbXkgdGVybWlub2xvZ3khCj4gCj4gCj4gPj5UaGlzIG1lYW5zIHRoZSBwaHlzaWNhbCBwbGFj ZW1lbnQgb2YgdGhlIG5ldyBrZXJuZWwgaXMgcHJlZGljdGFibGUgZnJvbQo+ID4+L3Byb2MvaW9t ZW0gLi4uIGJ1dCB0aGlzIGFsc28gdGVsbHMgeW91IHRoZSBwaHlzaWNhbCBwbGFjZW1lbnQgb2Yg dGhlIGN1cnJlbnQKPiA+Pmtlcm5lbCwgc28gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgcHJvYmxl bS4KPiA+Pgo+ID4+Cj4gPj4+V2UgYWx3YXlzIGRvIHRoaXMgYXMgaXQgd2lsbCBoYXZlIG5vIGhh cm0gb24ga2FzbHItaW5jYXBhYmxlIGtlcm5lbC4KPiA+Pj5XZSBkb24ndCBoYXZlIGFueSAic3dp dGNoIiB0byB0dXJuIG9mZiB0aGlzIGZlYXR1cmUgZGlyZWN0bHksIGJ1dCBzdGlsbAo+ID4+PmNh biBzdXBwcmVzcyBpdCBieSBwYXNzaW5nICJub2thc2xyIiBhcyBhIGtlcm5lbCBib290IGFyZ3Vt ZW50Lgo+ID4+Cj4gPj4+ZGlmZiAtLWdpdCBhL2FyY2gvYXJtNjQva2VybmVsL21hY2hpbmVfa2V4 ZWNfZmlsZS5jIGIvYXJjaC9hcm02NC9rZXJuZWwvbWFjaGluZV9rZXhlY19maWxlLmMKPiA+Pj5p bmRleCA3MzU2ZGE1YTUzZDUuLjQ3YTRmYmQwZGMzNCAxMDA2NDQKPiA+Pj4tLS0gYS9hcmNoL2Fy bTY0L2tlcm5lbC9tYWNoaW5lX2tleGVjX2ZpbGUuYwo+ID4+PisrKyBiL2FyY2gvYXJtNjQva2Vy bmVsL21hY2hpbmVfa2V4ZWNfZmlsZS5jCj4gPj4+QEAgLTE1OCw2ICsxNjAsMTIgQEAgc3RhdGlj IGludCBzZXR1cF9kdGIoc3RydWN0IGtpbWFnZSAqaW1hZ2UsCj4gPj5Eb24ndCB5b3UgbmVlZCB0 byByZXNlcnZlIHNvbWUgc3BhY2UgaW4gdGhlIGFyZWEgeW91IHZtYWxsb2MoKWQgZm9yIHRoZSBE VD8KPiA+Tm8sIEkgZG9uJ3QgdGhpbmsgc28uCj4gPkFsbCB0aGUgZGF0YSB0byBiZSBsb2FkZWQg YXJlIHRlbXBvcmFyaWx5IHNhdmVkIGluIGtleGVjIGJ1ZmZlcnMsCj4gPndoaWNoIHdpbGwgZXZl bnR1YWxseSBiZSBjb3BpZWQgdG8gdGFyZ2V0IGxvY2F0aW9ucyBpbiBtYWNoaW5lX2tleGVjCj4g Pihhcm02NF9yZWxvY2F0ZV9uZXdfa2VybmVsLCB3aGljaCwgdW5saWtlIGl0cyBuYW1lLCB3aWxs IGhhbmRsZQo+ID5ub3Qgb25seSBrZXJuZWwgYnV0IGFsc28gb3RoZXIgZGF0YSBhcyB3ZWxsKS4K PiAKPiBJIHRoaW5rIHdlJ3JlIHNwZWFraW5nIGF0IGNyb3NzIHB1cnBvc2VzLiBEb24ndCB5b3Ug bmVlZDoKPiAKPiB8IGJ1Zl9zaXplICs9IGZkdF9wcm9wX2xlbigia2FzbHLigJVzZWVkIiwgc2l6 ZW9mKHU2NCkpOwo+IAo+IAo+IFlvdSBjYW4ndCBhc3N1bWUgdGhlIGV4aXN0aW5nIERUQiBoYWQg YSBrYXNsci1zZWVkIHByb3BlcnR5LCBhbmQgdGhlCj4gZGlmZmVyZW5jZSBtYXkgdGFrZSB1cyBv dmVyIGEgUEFHRV9TSVpFIGJvdW5kYXJ5LgoKSSBzZWUsIEkgd2lsbCBhZGQgdGhhdC4KCj4gCj4g Pgo+ID4+Cj4gPj4+KwkvKiBhZGQga2FzbHItc2VlZCAqLwo+ID4+PisJZ2V0X3JhbmRvbV9ieXRl cygmdmFsdWUsIHNpemVvZih2YWx1ZSkpOwo+ID4+V2hhdCBoYXBwZW5zIGlmIHRoZSBjcm5nIGlz bid0IHJlYWR5Pwo+ID4+Cj4gPj5JdCBsb29rcyBsaWtlIHRoaXMgd2lsbCBwcmludCBhIHdhcm5p bmcgdGhhdCB0aGVzZSByYW5kb20tYnl0ZXMgYXJlbid0IHJlYWxseSB1cAo+ID4+dG8gc3RhbmRh cmQsIGJ1dCB0aGUgbmV3IGtlcm5lbCBkb2Vzbid0IGtub3cgdGhpcyBoYXBwZW5lZC4KPiA+Pgo+ ID4+Y3JuZ19yZWFkeSgpIGlzbid0IGV4cG9zZWQsIGFsbCB3ZSBjb3VsZCBkbyBub3cgaXMKPiA+ PndhaXRfZm9yX3JhbmRvbV9ieXRlcygpLCBidXQgdGhhdCBtYXkgd2FpdCBmb3JldmVyIGJlY2F1 c2Ugd2UgZG8gdGhpcwo+ID4+dW5jb25kaXRpb25hbGx5Lgo+ID4+Cj4gPj5JJ2QgcHJlZmVyIHRv IGxlYXZlIHRoaXMgZmVhdHVyZSB1bnRpbCB3ZSBjYW4gY2hlY2sgY3JuZ19yZWFkeSgpLCBhbmQg c2tpcAo+ID4+YWRkaW5nIGEgZG9kZ3ktc2VlZCBpZiBpdHMgbm90LXJlYWR5LiBUaGlzIGF2b2lk cyBwb2xsdXRpbmcgdGhlIG5leHQta2VybmVsJ3MKPiA+PmVudHJvcHkgcG9vbC4KPiA+T0suIEkg d291bGQgdHJ5IHRvIGZvbGxvdyB0aGUgc2FtZSB3YXkgYXMgQmh1cGVzaCdzIHVzZXJzcGFjZSBw YXRjaAo+ID5kb2VzIGZvciBrYXNsci1zZWVkOgo+ID5odHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9y Zy9waXBlcm1haWwva2V4ZWMvMjAxOC1BcHJpbC8wMjA1NjQuaHRtbAo+IAo+IChJIHJlYWxseSBk b24ndCB1bmRlcnN0YW5kIHRoaXMgJ2NvcHlpbmcgY29kZSBmcm9tIHVzZXItc3BhY2UnIHRoYXQg aGFwcGVucwo+IHdpdGgga2V4ZWNfZmlsZV9sb2FkKQo+IAo+IAo+ID4gICBpZiAobm90IGZvdW5k IGthc2xyLXNlZWQgaW4gMXN0IGtlcm5lbCdzIGR0YikKPiA+ICAgICAgZG9uJ3QgY2FyZTsgZ28g YWhlYWQKPiAKPiBEb24nIHQgYm90aGVyLiBBcyB5b3Ugc2F5IGluIHRoZSBjb21taXQtbWVzc2Fn ZSBpdHMgaGFybWxlc3MgaWYgdGhlIG5ldwo+IGtlcm5lbCBkb2Vzbid0IHN1cHBvcnQgaXQuCj4g QWx3YXlzIGhhdmluZyB0aGlzIHdvdWxkIGxldCB5b3UgdXNlIGtleGVjX2ZpbGVfbG9hZCBhcyBh IGJvb3Rsb2FkZXIgdGhhdAo+IGNhbiBnZXQgdGhlIGNybmcgdG8KPiBwcm92aWRlIGRlY2VudCBl bnRyb3B5IGV2ZW4gaWYgdGhlIHBsYXRmb3JtIGJvb3Rsb2FkZXIgY2FuJ3QuCgpPSywgYnV0IGFu eXdheSBwcmV2aW91cyAia2FzbHItc2VlZCIgd2lsbCBiZSBkcm9wcGVkIGZpcnN0LgoKPiAKPiA+ ICAgZWxzZQo+ID4gICAgICBpZiAoY3VycmVudCBrYXNsci1zZWVkICE9IDApCj4gPiAgICAgICAg IGVycm9yCj4gCj4gRG9uJ3QgYm90aGVyLiBJZiB0aGlzIGhhcHBlbnMgaXRzIGEgYnVnIGluIGFu b3RoZXIgcGFydCBvZiB0aGUga2VybmVsIHRoYXQKPiBkb2Vzbid0IGFmZmVjdCB0aGlzIG9uZS4g V2UgYXJlbid0IHNlY29uZC1ndWVzc2luZyB0aGUgZmlsZS1zeXN0ZW0gd2hlbiB3ZQo+IHJlYWQg dGhlIGtlcm5lbC1mZCwgbGV0cyBrZWVwIHRoaXMgc2ltcGxlLgoKT0sKCj4gPiAgICAgIGlmIChj cm5nX3JlYWR5KCkpIDsgRklYTUUsIGl0J3MgYSBsb2NhbCBtYWNybwo+ID4gICAgICAgICBnZXRf cmFuZG9tX2J5dGVzKG5vbi1ibG9ja2luZykKPiA+ICAgICAgICAgc2V0IG5ldyBrYXNsci1zZWVk Cj4gPiAgICAgIGVsc2UKPiA+ICAgICAgICAgZXJyb3IKPiBlcnJvcj8gU29tZXRoaW5nIGxpa2Ug cHJfd2Fybl9vbmNlKCkuCgpJdCB3YXMgY2hhbmdlZCB0byBwcl9ub3RpY2UoKSBzaW5jZSB0aGVy ZSBpcyBub3RoaW5nIHdyb25nLgoKVGhhbmtzLAotVGFrYWhpcm8gQUtBU0hJCgo+IEkgdGhvdWdo dCB0aGUga2FzbHItc2VlZCB3YXMgYWRkZWQgdG8gdGhlIGVudHJvcHkgcG9vbCwgYnV0IG5vdyBJ IGxvb2sgYWdhaW4KPiBJIHNlZSBpdHMgYSBzZXBhcmF0ZSBFRkkgdGFibGUuIFNvIHRoZSBuZXcg a2VybmVsIHdpbGwgYWRkIHRoZSBzYW1lIGVudHJvcHkKPiAuLi4gdGhhdCBkb2Vzbid0IHNvdW5k IGNsZXZlci4gKEkgY2FuJ3Qgc2VlIHdoZXJlIGl0cyB6ZXJvJ2Qgb3IKPiByZS1pbml0aWFsaXNl ZCkKPiAKPiAKPiAKPiBUaGFua3MsCj4gCj4gSmFtZXMKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmtleGVjIG1haWxpbmcgbGlzdAprZXhlY0BsaXN0cy5p bmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8v a2V4ZWMK