From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: Re: Xen 4.6.1 crash with altp2m enabledbydefault Date: Wed, 21 Sep 2016 14:18:52 +0000 Message-ID: <5C9C3B9BEF1B354596EAE3D6800D876B2DCF6BF5@e3.gdata.de> References: <5C9C3B9BEF1B354596EAE3D6800D876B2D31F567@e2.gdata.de> <1aa16ed8-7ee2-fbe7-ece0-86bf64850fc3@citrix.com> <5C9C3B9BEF1B354596EAE3D6800D876B2D32016A@e2.gdata.de> <57A0AF5E0200007800101C1A@prv-mh.provo.novell.com> <5C9C3B9BEF1B354596EAE3D6800D876B2D3216CB@e2.gdata.de> <57A2139B020000780010245D@prv-mh.provo.novell.com> <5C9C3B9BEF1B354596EAE3D6800D876B2D321CCF@e2.gdata.de> <57A37CE80200007800102D8C@prv-mh.provo.novell.com> <5C9C3B9BEF1B354596EAE3D6800D876B2D321F5A@e2.gdata.de> <57A4C36D0200007800103443@prv-mh.provo.novell.com> <5C9C3B9BEF1B354596EAE3D6800D876B2D3222F6@e2.gdata.de> <57A87B1D0200007800103B6D@prv-mh.provo.novell.com> <5C9C3B9BEF1B354596EAE3D6800D876B2DCD7937@e3.gdata.de> <105e972f-d20a-6beb-c5d8-1b18916d2119@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6200614001574437486==" Return-path: In-Reply-To: <105e972f-d20a-6beb-c5d8-1b18916d2119@citrix.com> Content-Language: de-DE List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: andrew.cooper3@citrix.com, JBeulich@suse.com Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============6200614001574437486== Content-Language: de-DE Content-Type: multipart/signed; boundary="----=_NextPart_000_0050_01D21423.D714C840"; micalg="2.16.840.1.101.3.4.2.3"; protocol="application/x-pkcs7-signature" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPart_000_0050_01D21423.D714C840 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0051_01D21423.D714C840" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPart_001_0051_01D21423.D714C840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys I have found the problem (after hours and hours of gruesome debugging with the almighty print) and it seems that this could potentially have quite a bit of impact if altp2m is enabled for a guest domain (even if the functionality is never actively used), since destroying any vcpu of this guest could lead to a hypervisor panic. So a malicious user could simply destroy and restart his VM(s) in order to DOS the VMs of other users by killing the hypervisor. Granted, this is not very effective, but, depending on the environment, it is extremely easy to implement. The bug persists in Xen 4.7 and I do not that it was fixed in the current master branch. The following happens. The call void hvm_vcpu_destroy(struct vcpu *v) { hvm_all_ioreq_servers_remove_vcpu(v->domain, v); if ( hvm_altp2m_supported() ) altp2m_vcpu_destroy(v); at some time reaches vmx_vcpu_update_eptp which ends with a vmx_vmcs_exit(v);. There vmx_clear_vmcs(v); -> __vmx_clear_vmcs is called where the current_vmcs is invalidated if the current vmcs in the CPU is the same as virt_to_maddr (v->arch.hvm_vmx->vmcs): __vmpclear(virt_to_maddr(arch_vmx->vmcs)); ( http://www.tptp.cc/mirrors/siyobik.info/instruction/VMCLEAR.html ) To check this assumption I implemented a basic __vmptrst ( http://www.tptp.cc/mirrors/siyobik.info/instruction/VMPTRST.html ) and added the result to the debug output. (XEN) vmcs.c:519:IDLEv4 __vmx_clear_vmcs: realVMCS BEFORE __vmpclear 82415a000=20 (XEN) vmcs.c:522:IDLEv4 __vmx_clear_vmcs: realVMCS AFTER __vmpclear ffffffffffffffff After that no vmcs_load / enter is executed so the vmcs in the CPU remains invalidated. For the next function in hvm_vcpu_destroy, the nestedhvm_vcpu_destroy(v) the missing vmcs is no problem (at least in our use case), but the free_compat_arg_xlat crashes. The callstack is as follows: hvm_vcpu_destroy free_compat_arg_xlat destroy_perdomain_mapping map_domain_page (probably inlined) mapcache_current_vcpu sync_local_execstate __sync_local_execstate __context_switch (with function pointer v->arch.ctxt_switch_from =3D vmx_ctxt_switch_from) vmx_ctxt_switch_from=20 (probably inlined) vmx_fpu_leave There a vmwrite is tried if either ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) ) or ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) ) is true. The executed vmwrite then crashes. As my knowledge of Xen is not that comprehensive, could you tell me when the TS-bits are set / cleared and what they are used for? static void vmx_fpu_leave(struct vcpu *v) { ASSERT(!v->fpu_dirtied); ASSERT(read_cr0() & X86_CR0_TS); if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) ) { v->arch.hvm_vmx.host_cr0 |=3D X86_CR0_TS; __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0); } if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) ) { v->arch.hvm_vcpu.hw_cr[0] |=3D X86_CR0_TS; __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]); v->arch.hvm_vmx.exception_bitmap |=3D (1u << TRAP_no_device); vmx_update_exception_bitmap(v); } } In the crash dump the additional debug output shows that at least one __vmwrite will be tried and that the VMCS in the CPU is invalidated: (XEN) vmx.c:698:IDLEv4 vmx_fpu_leave: vcpu ffff8300defae000 vmcs ffff8301586c9000 host_cr0-case FALSE guest_cr[0]-case TRUE curr ffff8300df2fb000 curr->arch.hvm_vmx.vmcs 0000000000000000 realVMCS ffffffffffffffff As a quick fix I patched the fpu_leave to only allow the __vmwrite when the realVMCS is valid. This seems to work fine, but requires a call to __vmptrst every time vmx_fpu_leave is called. Also I do not know if an ignored TS has any negative consequences when destroying a vcpu. I assume that this is not case. In our tests nothing pointed to any problems. I added the patch to enable altp2m unconditionally and a patch which evades the panic in vmx_fpu_leave. They are not pretty or anywhere near production ready, but I think you will get the idea. I tried to implement the __vmptrst with the #ifdef HAVE_GAS_VM parts ( analogue to the other functions in vmx.h ) but failed miserably since I lack the required knowledge about the OPCODE definitions. :-D Cheers Kevin > -----Urspr=FCngliche Nachricht----- > Von: Andrew Cooper [mailto:andrew.cooper3@citrix.com] > Gesendet: Montag, 22. August 2016 13:58 > An: Mayer, Kevin ; JBeulich@suse.com > Cc: xen-devel@lists.xen.org > Betreff: Re: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault >=20 > On 19/08/16 11:01, Kevin.Mayer@gdata.de wrote: > > Hi > > > > I took another look at Xen and a new crashdump. > > The last successful __vmwrite should be in static void > > vmx_vcpu_update_vmfunc_ve(struct vcpu *v) [...] > > __vmwrite(SECONDARY_VM_EXEC_CONTROL, > > v->arch.hvm_vmx.secondary_exec_control); > > [...] > > After this the altp2m_vcpu_destroy wakes up the vcpu and is then > finished. > > > > In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can > overwritten (but is not reached in our case as far as I can see): > > if ( nvcpu->nv_n1vmcx ) > > v->arch.hvm_vmx.vmcs =3D nvcpu->nv_n1vmcx; > > > > In conclusion: > > When destroying a domain the altp2m_vcpu_destroy(v); path seems to > mess up the vmcs which ( only ) sometimes leads to a failed __vmwrite in > vmx_fpu_leave. > > That is as far as I can get with my understanding of the Xen code. > > > > Do you guys have any additional ideas what I could test / analyse? >=20 > Do you have easy reproduction instructions you could share? Sadly, this is > looking like an issue which isn't viable to debug over email. >=20 > ~Andrew ____________ Virus checked by G Data MailSecurity Version: AVA 25.8368 dated 21.09.2016 Virus news: www.antiviruslab.com ------=_NextPart_001_0051_01D21423.D714C840 Content-Type: application/octet-stream; name="xen-altp2menable.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-altp2menable.patch" =0A= --- a/xen/arch/x86/hvm/hvm.c 2015-10-05 16:33:39.000000000 +0200=0A= +++ b/xen/arch/x86/hvm/hvm.c 2016-02-10 13:36:31.971062764 +0100=0A= @@ -1597,6 +1597,8 @@=0A= d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] =3D 1;=0A= d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] =3D = SHUTDOWN_reboot;=0A= =0A= + d->arch.hvm_domain.params[HVM_PARAM_ALTP2M] =3D 1;=0A= +=0A= vpic_init(d);=0A= =0A= rc =3D vioapic_init(d);=0A= =0A= ------=_NextPart_001_0051_01D21423.D714C840 Content-Type: application/octet-stream; name="xen-vmx_altp2m_bug.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-vmx_altp2m_bug.patch" --- a/xen/arch/x86/hvm/vmx/vmx.c 2016-02-09 15:44:19.000000000 +0100=0A= +++ b/xen/arch/x86/hvm/vmx/vmx.c 2016-09-21 15:46:20.000000000 +0200=0A= @@ -683,27 +683,31 @@=0A= =0A= static void vmx_fpu_leave(struct vcpu *v)=0A= {=0A= + u64 realVMCS =3D 0xffffffffffffffff;=0A= ASSERT(!v->fpu_dirtied);=0A= ASSERT(read_cr0() & X86_CR0_TS);=0A= -=0A= - if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) )=0A= + __vmptrst ( &realVMCS );=0A= + if ( realVMCS !=3D 0xffffffffffffffff )=0A= {=0A= - v->arch.hvm_vmx.host_cr0 |=3D X86_CR0_TS;=0A= - __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);=0A= - }=0A= + if ( !( v->arch.hvm_vmx.host_cr0 & X86_CR0_TS ) )=0A= + {=0A= + v->arch.hvm_vmx.host_cr0 |=3D X86_CR0_TS;=0A= + __vmwrite ( HOST_CR0 , v->arch.hvm_vmx.host_cr0 );=0A= + }=0A= =0A= - /*=0A= - * If the guest does not have TS enabled then we must cause and = handle an=0A= - * exception on first use of the FPU. If the guest *does* have TS = enabled=0A= - * then this is not necessary: no FPU activity can occur until the = guest=0A= - * clears CR0.TS, and we will initialise the FPU when that happens.=0A= - */=0A= - if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) )=0A= - {=0A= - v->arch.hvm_vcpu.hw_cr[0] |=3D X86_CR0_TS;=0A= - __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]);=0A= - v->arch.hvm_vmx.exception_bitmap |=3D (1u << TRAP_no_device);=0A= - vmx_update_exception_bitmap(v);=0A= + /*=0A= + * If the guest does not have TS enabled then we must cause and = handle an=0A= + * exception on first use of the FPU. If the guest *does* have = TS enabled=0A= + * then this is not necessary: no FPU activity can occur until = the guest=0A= + * clears CR0.TS, and we will initialise the FPU when that = happens.=0A= + */=0A= + if ( !( v->arch.hvm_vcpu.guest_cr[ 0 ] & X86_CR0_TS ) )=0A= + {=0A= + v->arch.hvm_vcpu.hw_cr[ 0 ] |=3D X86_CR0_TS;=0A= + __vmwrite ( GUEST_CR0 , v->arch.hvm_vcpu.hw_cr[ 0 ] );=0A= + v->arch.hvm_vmx.exception_bitmap |=3D ( 1u << = TRAP_no_device );=0A= + vmx_update_exception_bitmap ( v );=0A= + }=0A= }=0A= }=0A= =0A= --- a/xen/include/asm-x86/hvm/vmx/vmx.h 2016-02-09 15:44:19.000000000 = +0100=0A= +++ b/xen/include/asm-x86/hvm/vmx/vmx.h 2016-09-21 15:48:56.000000000 = +0200=0A= @@ -307,6 +307,11 @@=0A= : "memory");=0A= }=0A= =0A= +static inline void __vmptrst ( u64 *addr )=0A= +{=0A= + __asm __volatile ( "vmptrst %[addr]" ::[ addr ]"m" ( *addr ) : = "memory" );=0A= +}=0A= +=0A= static inline void __vmpclear(u64 addr)=0A= {=0A= asm volatile (=0A= ------=_NextPart_001_0051_01D21423.D714C840-- ------=_NextPart_000_0050_01D21423.D714C840 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCC/Mw ggWkMIIDjKADAgECAhAqHGNjtu5EiUJFCCzmegE5MA0GCSqGSIb3DQEBDQUAMEQxEjAQBgoJkiaJ k/IsZAEZFgJkZTEVMBMGCgmSJomT8ixkARkWBWdkYXRhMRcwFQYDVQQDEw5HIERhdGEgUm9vdCBD QTAeFw0xNjA0MjgwOTQ1MDNaFw0yNjA0MjkwOTU1MDFaMEQxEjAQBgoJkiaJk/IsZAEZFgJkZTEV MBMGCgmSJomT8ixkARkWBWdkYXRhMRcwFQYDVQQDEw5HIERhdGEgUm9vdCBDQTCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAMRyKREBZ67DLWkSS6cr3jyvCm113Wl+lEa3NI6wVuOFfZhC 6j6HZAHG6Vo1JBewAM8iMgT7PFLwEwB98ZrKuN0B/RR9Ck0W26kO8THtNfgAIIJzzcVQOOIzvFYV at3r7wMW9vWmzdWbfML+SI6tMwBA2fmdn/xnWWXoULRQOBXeEcaboSB1f/ABrZVA3jIQWnozARLA UFnNCuFMBlO//FBcGTpVnCs5RoV1SmOXk2Y3gMA7rSZVRiblIqfjuEzRxACZup66RlXrKKA2Q/aI dyUydlHR0wqTNmhwlOFyR7jPjLkQGRZrZaitaglXnaQe4M9lPV9SorjnwVcax/TKOC6WwXifUm6S 0oK4ldBbOEi90Yj+su+kfBZw4x64tYJunnBsU0Idb+yi9iD8vifk/URQhn1E7xQ3U7nn21fruj4T tjJCpqZdKCSGHZJ4wWgS/jzFZ2xeiLyL9UJ9OsPfyiMbAroncf44+DS0EKB+3ANWq0Cs7E/Gvbv4 +y4j0J3BWjB7xXMvKJ9Up0X3AV6po2M1uqhkwvBv5N85NGqoU0wy3Zx5/YIOQwkeuDC3+/FwvUPw eSMQSteeeqb+XZe1mE+VXj+5uE6yXGXq5+dgjdwBmi9eXLCJNvejZCnc7EyIuZHmnD+ghrB2Qsee ADgFCvtskfd2DkrlaUqeeSrnKBvPAgMBAAGjgZEwgY4wEwYJKwYBBAGCNxQCBAYeBABDAEEwDgYD VR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLzx+M97bHuypNU0ki1nzRRZ UtRMMBIGCSsGAQQBgjcVAQQFAgMBAAEwIwYJKwYBBAGCNxUCBBYEFEHKvYgqO4yNrIjo4IQvClX7 XRNzMA0GCSqGSIb3DQEBDQUAA4ICAQAfSDaFCNbYTahx0BU7C4eVRDwa3i8ozZZ1BMhzxWcIuUYy rM0QGX0MYZ4x6h//ekPB+hGbEVtqQSwFwznpfrRyvT5EyHbzzNoYoa8jRWWjG9r+I8cOpZovgVRO I6eaLIsaiYyISivo//bVWbwZYWnBcOaSg28VG8UWsELOrHSkzvRNtZv7xbpuAVzs+uiOyxIPZmNG FsdUn2zl/mQJA/507NJhaNyFU+d9YIXfjMj3aBrRdltD4W0riqMURFwIdh5SXdGdh1ESn01DeQ92 SLdR6gnQdJXmqSMGK64xIPAc2ISrLpjVB1Alv0tL/bQHi0jFdjjejELKnvbdfzj7DsuqanDJDaSt LDBGTSQ+iGc1npgUVlKZiB6C2ioxmqOi67AabE3UsL0pWsg1GKb8+SAaWeQUs6nFASlBQSUVc6ed QNGTPToaG/b67uJp7WHoxRMtRi7vMFoIiFF55oZQ4x3BIAX5vfXdhigMKPkxZ3Mcl5wt9+QQvLD4 fxfiXAfLHqXbtghXrqSI1B5NHiHNes7yY6lUcMe0GoYhZ/MxsH1vdv6BJDG/+5gCQZJUWdphiJ12 RvBLJv87OTTAzVDktfY9X4MkiWq6R6MVXcBdbXxooSV/QBt7YK6wNA/28B+5v4By7WI0WwH5bB8W /9O1QkH/7jxTfr7F229LkmYDlvIF3jCCBkcwggQvoAMCAQICE2wAABgqaeB4eDntvwUAAQAAGCow DQYJKoZIhvcNAQENBQAwRDESMBAGCgmSJomT8ixkARkWAmRlMRUwEwYKCZImiZPyLGQBGRYFZ2Rh dGExFzAVBgNVBAMTDkcgRGF0YSBSb290IENBMB4XDTE2MDcxMTE1MDYyNloXDTE4MDcxMTE1MDYy NlowgbIxEjAQBgoJkiaJk/IsZAEZFgJkZTEVMBMGCgmSJomT8ixkARkWBWdkYXRhMQ4wDAYDVQQL EwVHREFUQTEPMA0GA1UECxMGTG9naW5zMRUwEwYDVQQLEwxTZWN1cml0eSBMYWIxEjAQBgNVBAsT CVN5c1NlYy1CQTEUMBIGA1UEAxMLS2V2aW4gTWF5ZXIxIzAhBgkqhkiG9w0BCQEWFEtldmluLk1h eWVyQGdkYXRhLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyY/Fae/GVEuY2LDd GWahABqINzVLHxNRpiEKgBwNJl7IqvJw82TEXEJQhxQ+xuGMY4wqAqwJpfWnX/JM818W1ticGpVg 6DQLb6Jwz76Albo2VOmEUPD+fjufqY7KByMqeQ0+6gdfoBDptZyUW5MS+NcUnJFzwNjpE6Fhxi6k NbZxokclwNrjL2xNIdrTdW2ARgBTksfYYNLHXLqPBrkeZMIKUe05BVrB3NPhulkNHJe9I6fIQEEA T+hdq8WhsDoMYXM04hlyDi3jJgQj1zMFMucXEnP0/QB2VYcI5VSLuxY2NgWf1gkGCI1hjPmDmpgm V1ChtrKJgCidTFvBX5sROwIDAQABo4IBwTCCAb0wPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUI hIH8QYTykVODqZ0UhK2jDIXeyjVKh8egEYSZshMCAWQCARwwKQYDVR0lBCIwIAYKKwYBBAGCNwoD BAYIKwYBBQUHAwQGCCsGAQUFBwMCMA4GA1UdDwEB/wQEAwIFoDA1BgkrBgEEAYI3FQoEKDAmMAwG CisGAQQBgjcKAwQwCgYIKwYBBQUHAwQwCgYIKwYBBQUHAwIwRAYJKoZIhvcNAQkPBDcwNTAOBggq hkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQW BBTekNIfXeYDau7Ek3ejzo/PXWPyqTAfBgNVHSMEGDAWgBS88fjPe2x7sqTVNJItZ80UWVLUTDA9 BgNVHR8ENjA0MDKgMKAuhixodHRwOi8vY3JsLmdkYXRhLmRlL2NybGQvJTNDQ0FOYW1lJTNFKDEp LmNybDBFBgNVHREEPjA8oCQGCisGAQQBgjcUAgOgFgwUS2V2aW4uTWF5ZXJAZ2RhdGEuZGWBFEtl dmluLk1heWVyQGdkYXRhLmRlMA0GCSqGSIb3DQEBDQUAA4ICAQB5lpBxZIik7sDq7fqQCmuffG6b jWirhWjkqoA/KYesCFkUTlqxWlLkWNqWVnatW4DjsBSOXJ/3rHZyuuqw4NEAHVniImfk5bviJ8VF 6Mx0rswJUMllHcS+3wtXJ9qrVS8Aber3DlHhp/6rL4jwHU24IMVMGsV2XWq7p76ZvMlplovslbOu +DK1AAUkLWD/lZfnlHvTAdQRjHf4Uq1JFaT6a6WjV6pcxKfoUT4r6AMjqxKiCmyCdgW7evWajjH/ ZmbWt5fIa0m3BRgdwFMsGkjLEWXozg1pMP7q7f3pmXCNL4IY71FY36thV9UMrNE/sypC9eKYVvPB vnV6gM4Abwz3IyxWidjllir40PzzEdp8KS2tZU9fPtHnaCW9+nnHidAYrmJtuzSU36rYgwVKC3Ie 8N8a2XeIuwzchI9Y1TttQ0cuDw9FvZ2w574Sdch7LIXTjrBPvnRYtq7wR2lp8NgWj0+bEKgRV0ii ZtlXsp2Y96fpe7MXZn0qkqZFWlciNgElHT8oS5OPWfVnKg/OluM2CvxxM8Ce9CbMS0lwg0/hZLyD 5t8KN23yFfoHYt8xAF6xZ6ed4d7txom0LsLe5xzeZGtjdGqg6AS4lnxCUhLkHDAIuZ7zsrhBCoox kWHfqe6idBl4VyheSdGozZRREPqy+a4nVA2zV9YWq42rhzyHTTGCA4MwggN/AgEBMFswRDESMBAG CgmSJomT8ixkARkWAmRlMRUwEwYKCZImiZPyLGQBGRYFZ2RhdGExFzAVBgNVBAMTDkcgRGF0YSBS b290IENBAhNsAAAYKmngeHg57b8FAAEAABgqMA0GCWCGSAFlAwQCAwUAoIIB+TAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MjExNDE4NTFaME8GCSqGSIb3DQEJ BDFCBEDQ0flI2OQmGsI1gEPTAZR2Z9ct8bOdGFTm+PD3BTqRA3GWkGNow4ERPpH1W3+SDiCbXyJU V+0VEHjLrTH55XxUMGoGCSsGAQQBgjcQBDFdMFswRDESMBAGCgmSJomT8ixkARkWAmRlMRUwEwYK CZImiZPyLGQBGRYFZ2RhdGExFzAVBgNVBAMTDkcgRGF0YSBSb290IENBAhNsAAAYKmngeHg57b8F AAEAABgqMGwGCyqGSIb3DQEJEAILMV2gWzBEMRIwEAYKCZImiZPyLGQBGRYCZGUxFTATBgoJkiaJ k/IsZAEZFgVnZGF0YTEXMBUGA1UEAxMORyBEYXRhIFJvb3QgQ0ECE2wAABgqaeB4eDntvwUAAQAA GCowgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3 DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwCwYJYIZIAWUD BAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA DRLX041qav+FrwAcWqhMysBBxgSRD6rFySdaqLxWk5m13kPwutopWHDHAhlVo8RX09H6KevmAsA6 IOLGuYHWQAVZ4HrHvRhb6rk2MqAaMBzGQFFNM0bKibuYODd51Gq2dTi0IIMH1GRK6N8adVpREM7n L9MUGarObYcvFaINJbV36FvKKRqz+hxSfc7hbsXVuLF7dZqtlbx3+wWjBK96ORK1wvkFX0lOXLtK ki0U8BU3X585t01oU/TKQ+LjfBvi7zGZuubq0ZROoVV4g10yUTY3t9hEUoeT38wQgE3I4s+kINWm efpo1oJ8x4GH7d5yUQRyQe8csyowyWpYzUapbQAAAAAAAA== ------=_NextPart_000_0050_01D21423.D714C840-- --===============6200614001574437486== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6200614001574437486==--