From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by mx.groups.io with SMTP id smtpd.web10.4675.1615528827704979766 for ; Thu, 11 Mar 2021 22:00:28 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@solid-run-com.20150623.gappssmtp.com header.s=20150623 header.b=FuSzMdOD; spf=pass (domain: solid-run.com, ip: 209.85.218.47, mailfrom: jon@solid-run.com) Received: by mail-ej1-f47.google.com with SMTP id ox4so35501058ejb.11 for ; Thu, 11 Mar 2021 22:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solid-run-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ro1LDBWN2n2sskTwgkxNdpLuJODGVIvVoIJEbSYLw9U=; b=FuSzMdODcaUatJ5qT5RtQkGPf2Zvq1oKk0izH1iBUri3kP2vMySlLOfKW8B3QynvlV acNln3gS14ZTKHN9ng8ll6GqYGnkoEKmtZ6CX5xucRepbrAuY4ldu8TY+ndR0qbbhZcs FisrN5Wo5IOkzMP7R+VZuAyZ3tGf9AU4SHxsZw6JhcLyvRklJzRgHpAV+Z689F7ZcJaQ mjW1FAojyEXn7kJp5zDK6WIpEwXYk+2aWvLrqjFvOKC7tMeU24teTqFpQ62xNAKQsco3 xiWEYhbByAJdgFsEgzK2QEqBpqtYzZTJjqd70+19IS4Sj08pzBchnZv4Lq75KDeLWGXC z9Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ro1LDBWN2n2sskTwgkxNdpLuJODGVIvVoIJEbSYLw9U=; b=k3uA6FdqkzBvJFgvTrchBrIafS77f8HmpX0Vjav22onqlkQthFtgOcJsjapuH3PgON O7PUee3nMmLqYdCo2jnkuJQ+ELGd8GJysXlaTpx2CQi1RuElWREDG6fL4tE0Sg8Z4axy 4fb2Hy4IsGy5eOOoGZ+axXHjgrZzkyVhj28Ji3kXxGEG0C/K/t9/BKYA0+SOmTxS4Bq3 nV1VxRmlYozINLjah4A8BcwyfWNN06Dg8OHK6k6UsR6f9lt3Mrj3eJaoZPM5Iiekzkjj KpNdnjOscj2/fq03lGz1VXZUsM5c50U6SEKTb9oY1BbCbZBDBk8bzDm6PfcadfPcVhAR IUBQ== X-Gm-Message-State: AOAM530qg13Yd7YSImPWsKZR0aDSMSpGigEvBaPm4UeFrzunIYeSp6Rb jfF9fOXPbBvuVieDCuYNSzaba+F3lXicxIeU2dSlDhAw2mxn2A== X-Google-Smtp-Source: ABdhPJzOvzYi7mXElC6KkNDmIgDyYJbmPkXxTa6jcbbcuTD/9c5suRonqUC7FgIRSubNjsp1k/z8GHSu7VUudBDDUNM= X-Received: by 2002:a17:906:6a94:: with SMTP id p20mr6887138ejr.68.1615528825481; Thu, 11 Mar 2021 22:00:25 -0800 (PST) MIME-Version: 1.0 References: <5363bdf0-afac-73bf-d001-77949916f511@redhat.com> <166B374585A9D8FC.18699@groups.io> <290a35ce-9116-af00-85f4-8df1c5228680@redhat.com> <4841241f-fc6d-6185-efe6-ed9a536534dd@redhat.com> <166B792D1514133B.31346@groups.io> In-Reply-To: <166B792D1514133B.31346@groups.io> From: "Jon Nettleton" Date: Fri, 12 Mar 2021 06:59:49 +0100 Message-ID: Subject: Re: [edk2-devel] Conflicting virtual addresses causing Runtime Services issues To: devel@edk2.groups.io, Jon Nettleton Cc: Ard Biesheuvel , Laszlo Ersek , Hao A Wu , Liming Gao , "Ard Biesheuvel (TianoCore)" , "Leif Lindholm (Nuvia address)" X-Groupsio-MsgNum: 72701 Content-Type: multipart/mixed; boundary="000000000000c4a5e305bd509d13" --000000000000c4a5e305bd509d13 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 12, 2021 at 4:02 AM Jon Nettleton via groups.io wrote: > > On Thu, Mar 11, 2021 at 11:39 PM Ard Biesheuvel wrote: > > > > On Thu, 11 Mar 2021 at 23:25, Laszlo Ersek wrote: > > > > > > Adding Ard and Leif, comments below: > > > > > > On 03/11/21 15:50, Laszlo Ersek wrote: > > > > On 03/11/21 10:48, Jon Nettleton wrote: > > > > > > [...] > > > > > > >> And this is where the pointer gets remapped again and into the MMIO > > > >> space of the nor flash. If I remove the calls to ConvertPointer for > > > >> the FvbProtocol I am still seeing those addresses getting remapped > > > >> but only once and runtime works as expected. > > > >> > > > >> I am seeing that in > > > >> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c > > > >> &mVariableModuleGlobal->FvbInstance->* are all being converted. It > > > >> is possible this is a long standing bug and it just so happens that > > > >> our configuration has caused a conflict and exposed it. > > > > > > > > Yes, this is curious, I noticed it too yesterday, trying to see where > > > > the FVB protocol member function pointers were converted. I found that > > > > OVMF's flash driver (OvmfPkg/QemuFlashFvbServicesRuntimeDxe) didn't do > > > > it, but MdeModulePkg/Universal/Variable/RuntimeDxe did. That was > > > > certainly strange, as the variable driver is a consumer of the > > > > protocol (not the producer thereof), so I'd say it has no business > > > > poking new values into the protocol interface structure. > > > > > > [...] > > > > > > > ... Strangely, the other flash (FVB) driver in edk2, > > > > ArmPlatformPkg/Drivers/NorFlashDxe, *does* perform the conversion > > > > itself! See NorFlashVirtualNotifyEvent(). > > > > > > > > I don't understand that. Is it possible that, with > > > > "ArmPlatformPkg/Drivers/NorFlashDxe" too, the conversion happens > > > > *twice*, but (at least) one of those mappings is "identity"? > > > > > > Confirmed. > > > > > > I had to write some elaborate debug patches for determining this, > > > because in ArmVirtQemu, I cannot produce DEBUG output from the > > > SetVirtualAddressMap() notification functions. So here's the approach I > > > took: > > > > > > (1) Introduce a new GUID-ed HOB structure in MdeModulePkg. The structure > > > itself lives in reserved memory, but its address is exposed in a GUID-ed > > > HOB. The structure is named FVB_ADDRESS_LIST, and it has the following > > > fields: > > > > > > - signature ("FVBADRLS" -- FVB Address List) > > > - 16 entries of: > > > - owner signature [what driver set this entry] > > > - address > > > - number of entries used (aka next entry to fill) > > > > > > (2) In PlatformPei, allocate and initialize this structure (in reserved > > > memory), and expose its address via the GUID-ed HOB. Furthermore, > > > produce a log message with the allocation address. > > > > > > (3) In NorFlashDxe, look up the structure via the GUID-ed HOB, in the > > > entry point function; remember the address in a global variable. In the > > > SetVirtualAddressMap() handler function, treat the conversion of the > > > "GetPhysicalAddress" FVB member function specially: via the global > > > variable pointer to FVB_ADDRESS_LIST in reserved memory, save both the > > > physical (original) and the virtual (converted) address of the > > > "GetPhysicalAddress" FVB member function, in new entries. As owner > > > signature in both entries, use "NORFLASH". > > > > > > (4) In the runtime DXE variable driver, do the exact same thing, just > > > use a different "owner signature" -- "VARIABLE". > > > > > > (5) Once the guest is up and running, run "efibootmgr --delete-timeout" > > > at a root prompt in the guest, deleting the existent "Timeout" UEFI > > > non-volatile variable, for verifying that the runtime variable (write) > > > service is functional. > > > > > > (6) Using the log message from point (2): > > > > > > > PlatformPeim: FvbAddressList @ 13FEC9000 > > > > > > hexdump the guest memory containing the FVB_ADDRESS_LIST, as follows: > > > > > > > $ virsh qemu-monitor-command aavmf.rhel7.registered --hmp xp /268cb 0x13FEC9000 > > > > > > Ccomments to the right of the hexdump: > > > > > > > 000000013fec9000: 'F' 'V' 'B' 'A' 'D' 'R' 'L' 'S' <- structure signature: FVBADRLS > > > > 000000013fec9008: 'N' 'O' 'R' 'F' 'L' 'A' 'S' 'H' <- entry[0], signature: NORFLASH > > > > 000000013fec9010: 'T' ' ' '\xc6' ';' '\x01' '\x00' '\x00' '\x00' <- entry[0], GetPhysicalAddress *physical*: 0x000000013bc62054 > > > > 000000013fec9018: 'N' 'O' 'R' 'F' 'L' 'A' 'S' 'H' <- entry[1], signature: NORFLASH > > > > 000000013fec9020: 'T' ' ' 'N' '$' '\x00' '\x00' '\x00' '\x00' <- entry[1], GetPhysicalAddress *virtual*: 0x00000000244e2054 > > > > 000000013fec9028: 'V' 'A' 'R' 'I' 'A' 'B' 'L' 'E' <- entry[2], signature: VARIABLE > > > > 000000013fec9030: 'T' ' ' 'N' '$' '\x00' '\x00' '\x00' '\x00' <- entry[2], GetPhysicalAddress *physical*: 0x00000000244e2054 > > > > 000000013fec9038: 'V' 'A' 'R' 'I' 'A' 'B' 'L' 'E' <- entry[3], signature: VARIABLE > > > > 000000013fec9040: 'T' ' ' 'N' '$' '\x00' '\x00' '\x00' '\x00' <- entry[3], GetPhysicalAddress *virtual*: 0x00000000244e2054 > > > > 000000013fec9048: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9050: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9058: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9060: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9068: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9070: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9078: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9080: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9088: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9090: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9098: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90a0: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90a8: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90b0: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90b8: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90c0: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90c8: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90d0: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90d8: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90e0: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90e8: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90f0: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec90f8: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9100: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' > > > > 000000013fec9108: '\x04' '\x00' '\x00' '\x00' <- number of entries used: 4 > > > > > > This shows the following: > > > > > > - both NorFlashDxe and the runtime DXE variable driver converted the > > > FVB.GetPhysicalAddress member function, > > > > > > - the NorFlashDxe driver acted first, the runtime DXE variable driver > > > acted second, > > > > > > - when the runtime DXE variable driver "converted" the "physical" > > > address to virtual address, there was no change (and no crash!), > > > because the virtual address map passed in by the Linux kernel > > > apparently identity maps this area -- just as I guessed. > > > > > > So we definitely have a bug (only Linux's page tables save us from the > > > crash); now the question is: > > > > > > Which driver is wrong to even attempt the conversion of the FVB member > > > functions? > > > > > > The answer must be documented somewhere highly visible. > > > > > > Debug patches attached, for the record (based on commit edd46cd407ea). > > > > > > > Thanks for inviting me to this party! > > > > So the tl;dr here is that some points get converted twice, which > > usually is not a problem because the virtual address resulting from > > the conversion is rarely mistaken for a physical address living in a > > EFI_MEMORY_RUNTIME region. > > > > So I agree with Laszlo's assertion that the consumer of a protocol has > > no business updating its protocol pointers, so this should definitely > > be fixed in the core VariableRuntime driver. However, given the > > typical nature of the variable stack, i.e., a platform specfic NOR > > flash driver combined with the generic FTW and variable drivers, doing > > so would likely break many out of tree platforms where the NOR flash > > driver does not bother to update its pointers at all. > > Not ideal, but we could add a flag to Runtime Services and let the platform > specify if it is remapping the FVB. This would allow us to not break legacy > drivers, but still easily let properly designed platforms bypass this > behaviour. As time progressed this could be used to for a deprecation > warning, until it became the default handling of FVB pointer conversion. > Something like the attached patch possibly? --000000000000c4a5e305bd509d13 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-MdeModulePkg-Variable-VariableRuntimeDxe-Add-Bool-Pc.patch" Content-Disposition: attachment; filename="0001-MdeModulePkg-Variable-VariableRuntimeDxe-Add-Bool-Pc.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_km5w4m450 RnJvbSAxMjZiZDhiZWJmMjRlMDI2OTY5NmYyMmEyODJhNGIwMzQwZDk5MjNiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKb24gTmV0dGxldG9uIDxqb25Ac29saWQtcnVuLmNvbT4KRGF0 ZTogRnJpLCAxMiBNYXIgMjAyMSAwNjo1Mjo1NiArMDEwMApTdWJqZWN0OiBbUEFUQ0hdIE1kZU1v ZHVsZVBrZy9WYXJpYWJsZS9WYXJpYWJsZVJ1bnRpbWVEeGU6IEFkZCBCb29sCiBQY2REcml2ZXJD b252ZXJ0c0Z2YkZ1bmNQb2ludGVycwoKVmFyaWFibGVSdW50aW1lRHhlIGlzIHVuY29uZGl0aW9u YWxseSBjb252ZXJ0aW5nIHRoZSBwb2ludGVycyB0byB0aGUgRnZiIHByb3RvY29sCmZ1bmN0aW9u cyBldmVuIGlmIHRoZSBwbGF0Zm9ybSBkcml2ZXJzIGFyZSBhbHJlYWR5IGNvbnZlcnRpbmcgdGhl IHBvaW50ZXJzCnRoZW1zZWx2ZXMuICBUaGlzIGxlYWRzIHRvIGEgZG91YmxlIHBvaW50ZXIgY29u dmVyc2lvbiBhbmQgY2FuIGNhdXNlIHVuZXhwZWN0ZWQKcnVudGltZSBiZWhhdmlvdXIgZGVwZW5k aW5nIG9uIHRoZSBtZW1vcnkgbGF5b3V0IG9mIHRoZSBwbGF0Zm9ybS4KClNpbmNlIHdlIGRvbid0 IHdhbnQgdG8gYnJlYWsgbGVnYWN5IGFuZCBvdXQgb2YgdHJlZSBwbGF0Zm9ybXMgd2UgYWRkIGEg Qm9vbCBmbGFnCnRoYXQgZGVmYXVsdHMgdG8gdGhlIGV4aXN0aW5nIGJlaGF2aW91ciBidXQgYWxs b3dzIHBsYXRmb3JtcyB0byBvbmx5IHVzZSB0aGUKcG9pbnRlciBjb252ZXJzaW9uIGJlaW5nIGRv bmUgaW4gdGhlaXIgZHJpdmVyIGltcGxlbWVudGF0aW9uIHRoYXQgcHJvZHVjZXMgdGhlCkZWQiBQ cm90b2NvbC4KClNpZ25lZC1vZmYtYnk6IEpvbiBOZXR0bGV0b24gPGpvbkBzb2xpZC1ydW4uY29t PgotLS0KIE1kZU1vZHVsZVBrZy9NZGVNb2R1bGVQa2cuZGVjICAgICAgICAgICAgICAgICAgICB8 ICA2ICsrKysrKwogLi4uL1VuaXZlcnNhbC9WYXJpYWJsZS9SdW50aW1lRHhlL1ZhcmlhYmxlRHhl LmMgIHwgMTYgKysrKysrKysrLS0tLS0tLQogLi4uL1ZhcmlhYmxlL1J1bnRpbWVEeGUvVmFyaWFi bGVSdW50aW1lRHhlLmluZiAgIHwgIDEgKwogMyBmaWxlcyBjaGFuZ2VkLCAxNiBpbnNlcnRpb25z KCspLCA3IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL01kZU1vZHVsZVBrZy9NZGVNb2R1bGVQ a2cuZGVjIGIvTWRlTW9kdWxlUGtnL01kZU1vZHVsZVBrZy5kZWMKaW5kZXggMTQ4Mzk1NTExMC4u MDdiODRiMTgzNyAxMDA2NDQKLS0tIGEvTWRlTW9kdWxlUGtnL01kZU1vZHVsZVBrZy5kZWMKKysr IGIvTWRlTW9kdWxlUGtnL01kZU1vZHVsZVBrZy5kZWMKQEAgLTExMzAsNiArMTEzMCwxMiBAQAog ICAjIEBQcm9tcHQgUmVjbGFpbSB2YXJpYWJsZSBzcGFjZSBhdCBFbmRPZkR4ZS4NCiAgIGdFZmlN ZGVNb2R1bGVQa2dUb2tlblNwYWNlR3VpZC5QY2RSZWNsYWltVmFyaWFibGVTcGFjZUF0RW5kT2ZE eGV8RkFMU0V8Qk9PTEVBTnwweDMwMDAwMDA4DQogDQorICAjIyBEcml2ZXIgY29udmVydHMgRlZC IGZ1bmN0aW9uIHBvaW50ZXJzLjxCUj48QlI+DQorICAjIFRoZSB2YWx1ZSBpcyBGQUxTRSBhcyBk ZWZhdWx0IHRvIHJldGFpbiB0aGUgY3VycmVudCBiZWhhdmlvdXIgYW5kIHJldGFpbiBjb21wYXRp YmlsaXR5IHdpdGggb3V0IG9mIHRyZWUgcGxhdG9ybXMuPEJSPg0KKyAgIyBJZiB0aGUgdmFsdWUg aXMgc2V0IHRvIFRSVUUsIHZhcmlhYmxlIGRyaXZlciBkb2VzIG5vdCBjb252ZXJ0IHRoZSBGVkIg ZnVuY3Rpb24gcG9pbnRlcnMuPEJSPg0KKyAgIyBAUHJvbXB0IFBsYXRmb3JtIGRyaXZlciBjb252 ZXJ0cyBGVkIgcG9pbnRlcnMuDQorICBnRWZpTWRlTW9kdWxlUGtnVG9rZW5TcGFjZUd1aWQuUGNk RHJpdmVyQ29udmVydHNGdmJGdW5jUG9pbnRlcnN8RkFMU0V8Qk9PTEVBTnwweDMwMDAwMDBiDQor DQogICAjIyBUaGUgc2l6ZSBvZiB2b2xhdGlsZSBidWZmZXIuIFRoaXMgYnVmZmVyIGlzIHVzZWQg dG8gc3RvcmUgVk9MQVRJTEUgYXR0cmlidXRlIHZhcmlhYmxlcy4NCiAgICMgQFByb21wdCBWYXJp YWJsZSBzdG9yYWdlIHNpemUuDQogICBnRWZpTWRlTW9kdWxlUGtnVG9rZW5TcGFjZUd1aWQuUGNk VmFyaWFibGVTdG9yZVNpemV8MHgxMDAwMHxVSU5UMzJ8MHgzMDAwMDAwNQ0KZGlmZiAtLWdpdCBh L01kZU1vZHVsZVBrZy9Vbml2ZXJzYWwvVmFyaWFibGUvUnVudGltZUR4ZS9WYXJpYWJsZUR4ZS5j IGIvTWRlTW9kdWxlUGtnL1VuaXZlcnNhbC9WYXJpYWJsZS9SdW50aW1lRHhlL1ZhcmlhYmxlRHhl LmMKaW5kZXggMGZjYTBiYjJhOS4uZWRlMmE2NjY4MiAxMDA2NDQKLS0tIGEvTWRlTW9kdWxlUGtn L1VuaXZlcnNhbC9WYXJpYWJsZS9SdW50aW1lRHhlL1ZhcmlhYmxlRHhlLmMKKysrIGIvTWRlTW9k dWxlUGtnL1VuaXZlcnNhbC9WYXJpYWJsZS9SdW50aW1lRHhlL1ZhcmlhYmxlRHhlLmMKQEAgLTI0 NywxMyArMjQ3LDE1IEBAIFZhcmlhYmxlQ2xhc3NBZGRyZXNzQ2hhbmdlRXZlbnQgKAogICBVSU5U TiAgICAgICAgICBJbmRleDsNCiANCiAgIGlmIChtVmFyaWFibGVNb2R1bGVHbG9iYWwtPkZ2Yklu c3RhbmNlICE9IE5VTEwpIHsNCi0gICAgRWZpQ29udmVydFBvaW50ZXIgKDB4MCwgKFZPSUQgKiop ICZtVmFyaWFibGVNb2R1bGVHbG9iYWwtPkZ2Ykluc3RhbmNlLT5HZXRCbG9ja1NpemUpOw0KLSAg ICBFZmlDb252ZXJ0UG9pbnRlciAoMHgwLCAoVk9JRCAqKikgJm1WYXJpYWJsZU1vZHVsZUdsb2Jh bC0+RnZiSW5zdGFuY2UtPkdldFBoeXNpY2FsQWRkcmVzcyk7DQotICAgIEVmaUNvbnZlcnRQb2lu dGVyICgweDAsIChWT0lEICoqKSAmbVZhcmlhYmxlTW9kdWxlR2xvYmFsLT5GdmJJbnN0YW5jZS0+ R2V0QXR0cmlidXRlcyk7DQotICAgIEVmaUNvbnZlcnRQb2ludGVyICgweDAsIChWT0lEICoqKSAm bVZhcmlhYmxlTW9kdWxlR2xvYmFsLT5GdmJJbnN0YW5jZS0+U2V0QXR0cmlidXRlcyk7DQotICAg IEVmaUNvbnZlcnRQb2ludGVyICgweDAsIChWT0lEICoqKSAmbVZhcmlhYmxlTW9kdWxlR2xvYmFs LT5GdmJJbnN0YW5jZS0+UmVhZCk7DQotICAgIEVmaUNvbnZlcnRQb2ludGVyICgweDAsIChWT0lE ICoqKSAmbVZhcmlhYmxlTW9kdWxlR2xvYmFsLT5GdmJJbnN0YW5jZS0+V3JpdGUpOw0KLSAgICBF ZmlDb252ZXJ0UG9pbnRlciAoMHgwLCAoVk9JRCAqKikgJm1WYXJpYWJsZU1vZHVsZUdsb2JhbC0+ RnZiSW5zdGFuY2UtPkVyYXNlQmxvY2tzKTsNCisgICAgaWYgKCFQY2RHZXRCb29sIChQY2REcml2 ZXJDb252ZXJ0c0Z2YkZ1bmNQb2ludGVycykpIHsNCisgICAgICBFZmlDb252ZXJ0UG9pbnRlciAo MHgwLCAoVk9JRCAqKikgJm1WYXJpYWJsZU1vZHVsZUdsb2JhbC0+RnZiSW5zdGFuY2UtPkdldEJs b2NrU2l6ZSk7DQorICAgICAgRWZpQ29udmVydFBvaW50ZXIgKDB4MCwgKFZPSUQgKiopICZtVmFy aWFibGVNb2R1bGVHbG9iYWwtPkZ2Ykluc3RhbmNlLT5HZXRQaHlzaWNhbEFkZHJlc3MpOw0KKyAg ICAgIEVmaUNvbnZlcnRQb2ludGVyICgweDAsIChWT0lEICoqKSAmbVZhcmlhYmxlTW9kdWxlR2xv YmFsLT5GdmJJbnN0YW5jZS0+R2V0QXR0cmlidXRlcyk7DQorICAgICAgRWZpQ29udmVydFBvaW50 ZXIgKDB4MCwgKFZPSUQgKiopICZtVmFyaWFibGVNb2R1bGVHbG9iYWwtPkZ2Ykluc3RhbmNlLT5T ZXRBdHRyaWJ1dGVzKTsNCisgICAgICBFZmlDb252ZXJ0UG9pbnRlciAoMHgwLCAoVk9JRCAqKikg Jm1WYXJpYWJsZU1vZHVsZUdsb2JhbC0+RnZiSW5zdGFuY2UtPlJlYWQpOw0KKyAgICAgIEVmaUNv bnZlcnRQb2ludGVyICgweDAsIChWT0lEICoqKSAmbVZhcmlhYmxlTW9kdWxlR2xvYmFsLT5GdmJJ bnN0YW5jZS0+V3JpdGUpOw0KKyAgICAgIEVmaUNvbnZlcnRQb2ludGVyICgweDAsIChWT0lEICoq KSAmbVZhcmlhYmxlTW9kdWxlR2xvYmFsLT5GdmJJbnN0YW5jZS0+RXJhc2VCbG9ja3MpOw0KKyAg ICB9DQogICAgIEVmaUNvbnZlcnRQb2ludGVyICgweDAsIChWT0lEICoqKSAmbVZhcmlhYmxlTW9k dWxlR2xvYmFsLT5GdmJJbnN0YW5jZSk7DQogICB9DQogICBFZmlDb252ZXJ0UG9pbnRlciAoMHgw LCAoVk9JRCAqKikgJm1WYXJpYWJsZU1vZHVsZUdsb2JhbC0+UGxhdGZvcm1MYW5nQ29kZXMpOw0K ZGlmZiAtLWdpdCBhL01kZU1vZHVsZVBrZy9Vbml2ZXJzYWwvVmFyaWFibGUvUnVudGltZUR4ZS9W YXJpYWJsZVJ1bnRpbWVEeGUuaW5mIGIvTWRlTW9kdWxlUGtnL1VuaXZlcnNhbC9WYXJpYWJsZS9S dW50aW1lRHhlL1ZhcmlhYmxlUnVudGltZUR4ZS5pbmYKaW5kZXggYzk0MzRkZjYzMS4uZjMzNzNm ODEzNyAxMDA2NDQKLS0tIGEvTWRlTW9kdWxlUGtnL1VuaXZlcnNhbC9WYXJpYWJsZS9SdW50aW1l RHhlL1ZhcmlhYmxlUnVudGltZUR4ZS5pbmYKKysrIGIvTWRlTW9kdWxlUGtnL1VuaXZlcnNhbC9W YXJpYWJsZS9SdW50aW1lRHhlL1ZhcmlhYmxlUnVudGltZUR4ZS5pbmYKQEAgLTEzNyw2ICsxMzcs NyBAQAogICBnRWZpTWRlTW9kdWxlUGtnVG9rZW5TcGFjZUd1aWQuUGNkTWF4VXNlck52VmFyaWFi bGVTcGFjZVNpemUgICAgICAgICAgICMjIENPTlNVTUVTDQogICBnRWZpTWRlTW9kdWxlUGtnVG9r ZW5TcGFjZUd1aWQuUGNkQm9vdHRpbWVSZXNlcnZlZE52VmFyaWFibGVTcGFjZVNpemUgICMjIENP TlNVTUVTDQogICBnRWZpTWRlTW9kdWxlUGtnVG9rZW5TcGFjZUd1aWQuUGNkUmVjbGFpbVZhcmlh YmxlU3BhY2VBdEVuZE9mRHhlICAjIyBDT05TVU1FUw0KKyAgZ0VmaU1kZU1vZHVsZVBrZ1Rva2Vu U3BhY2VHdWlkLlBjZERyaXZlckNvbnZlcnRzRnZiRnVuY1BvaW50ZXJzICAgIyMgQ09OU1VNRVMN CiAgIGdFZmlNZGVNb2R1bGVQa2dUb2tlblNwYWNlR3VpZC5QY2RFbXVWYXJpYWJsZU52TW9kZUVu YWJsZSAgICAgICAgICMjIFNPTUVUSU1FU19DT05TVU1FUw0KICAgZ0VmaU1kZU1vZHVsZVBrZ1Rv a2VuU3BhY2VHdWlkLlBjZEVtdVZhcmlhYmxlTnZTdG9yZVJlc2VydmVkICAgICAgIyMgU09NRVRJ TUVTX0NPTlNVTUVTDQogDQotLSAKMi4yNy4wCgo= --000000000000c4a5e305bd509d13--