From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55896 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P6XyI-0007AG-LB for qemu-devel@nongnu.org; Thu, 14 Oct 2010 20:16:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P6XyH-0005I6-5B for qemu-devel@nongnu.org; Thu, 14 Oct 2010 20:16:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P6XyG-0005I2-Op for qemu-devel@nongnu.org; Thu, 14 Oct 2010 20:16:29 -0400 Message-ID: <4CB79D58.3070006@REDHAT.COM> Date: Thu, 14 Oct 2010 17:16:24 -0700 From: Robert Relyea MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2) References: <4CB74DD3.7090100@REDHAT.COM> <4CB7518B.3010308@codemonkey.ws> <4CB77E2A.9030105@REDHAT.COM> <4CB78147.6040807@codemonkey.ws> In-Reply-To: <4CB78147.6040807@codemonkey.ws> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030906060001060706000903" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Alon Levy , qemu-devel@nongnu.org This is a cryptographically signed message in MIME format. --------------ms030906060001060706000903 Content-Type: multipart/alternative; boundary="------------000705020509040702000505" This is a multi-part message in MIME format. --------------000705020509040702000505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/14/2010 03:16 PM, Anthony Liguori wrote: > On 10/14/2010 05:03 PM, Robert Relyea wrote: >>> Remote device passthrough is just a special case of passthrough.=20 >>> It's got interesting characteristics in that unlike local device >>> passthrough, if you preserve the connection to the remove device, >>> migration is still possible. >>> >>> However, remote device *emulation* is the thing that I'm concerned >>> about. Having a device emulated outside of QEMU means that it's not >>> possible to participate in many of QEMU's features (like live >>> migration, tracing, debugging, etc.). Device creation is extremely >>> complicated because you have to launch the external daemon and >>> somehow configure that. >> There's always some emulation going on on the client side. The client >> side has the device drivers, so you are either emulating an actual >> device or you are emulating the abstraction you invent. Once you have >> the client side, you have to launch the external daemon anyway. > > That's not a very convincing argument. Neither is that;). My point is that no matter what you do, there is *always* some sort of client emulation going on and the client is the only one in this scenario that has access to the local drivers. This is all moot. The only client side qemu supports is vnc/X/xdesktop. All those devices have client side drivers that are emulating the overall protocol. > > It's pretty simple really. We don't want to split QEMU into a bunch > of different daemons that all implement device emulation in slightly > different ways. The user complexity is enormous and the ability to > manage the complexity because impossible because nothing is centralized= =2E I think you misunderstand me. In some sense I'm agreeing with you. I agree you don't want to split QEMU into a bunch of daemons, which is why I think you handle the smart card remotely only with spice. Currently QEMU doesn't have the infrastructure to handle lots of different client devices (pretty much only if there is some preexisting client like vnc that handles those things). In some sense we seem to be talking cross purposes here. I agree that QEMU isn't the right place to handle client side devices. It's clearly not in the QEMU model, so it makes sense NOT to emulate on the client side for QEMU... > >> It seems to me that the best way to go is to provide the native host >> =3D=3D client support like other devices and allow the passthru. If yo= u >> really need client support, just run spice (which is a single client >> daemon that handles everything). > > Let's not confuse passthrough with implementing device emulation > outside of QEMU. They are two very different things. > > I think a remote passthrough protocol who's sole purpose is to allow > external device emulation is a bad idea for QEMU. The passthru is passthru. I'm not sure what you mean here.... I'm presuming the way forward is to have passthru and qemu implementing a local smart card emulation. I'm fine with just passthru and local emulation to a local smart card. > >>> >>> After talking to Alon in IRC, I think a better model for Spice would >>> be to integrate the smart card emulation into QEMU and then develop >>> a specific protocol for the smart card emulation to interface with >>> the physical smart card. This interface isn't really any different >>> than the network interface or the block interface in QEMU today. >> I seems to me that a second protocol is overkill. Having 2 protocols >> is a bit much to manage. We can do everything we need with the passthr= u. > > How is external device emulation not overkill? I don't see why two > protocols are necessary. You just need one. If you have one for passthru and one for emulated cards, that's two protocols. > >> My worry about creating any thing else is we may not have the >> flexibility to handle future cards. Smart cards themselves are >> programmable, so the interface for new cards are pretty dynamic. > > My worry is that we're creating an impossible situation to maintain in > the long term because device emulation is happening in 10 different > places. If there's a bug in your smart card emulation, a guest can > now break into a Spice client. Part of the advantage of keeping > everything contained in a single place (QEMU) is that we can restrict > QEMU from a security perspective via sVirt and other mechanisms. Once > you split apart device emulation, you break that security model. That's true whether I'm emulating on qemu or not. If there is a bug in the emulation code, you can break out. If there is a bug in the client side driver, you can break out. The risk is exactly the same. But again, this is academic, I'm not advocating doing this in qemu. Clearly there needs to be more work before we can even talk about qemu client side devices where client !=3D host. bob --------------000705020509040702000505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/14/2010 03:16 PM, Anthony Liguori wrote:
On 10/14/2010 05:03 PM, Robert Relyea wrote:
Remote device passthrough is just a special case of passthrough.=C2=A0 It's got interesting characteristics in that unlike local device passthrough, if you preserve the connection to the remove device, migration is still possible.

However, remote device *emulation* is the thing that I'm concerned about.=C2=A0 Having a device emulated outside of QEMU means that it's not= possible to participate in many of QEMU's features (like live migration, tracing, debugging, etc.).=C2=A0 Device creation is extremely complicated because you have to launch the external daemon and somehow configure that.
There's always some emulation going on on the client side. The client side has the device drivers, so you are either emulating an actual device or you are emulating the abstraction you invent. Once you have the client side, you have to launch the external daemon anyway.
That's not a very convincing argument.
Neither is that;). My point is that no matter what you do, there is *always* some sort of client emulation going on and the client is the only one in this scenario that has access to the local drivers. This is all moot. The only client side qemu supports is vnc/X/xdesktop. All those devices have client side drivers that are emulating the overall protocol.
It's pretty simple really.=C2=A0 We don't want to split QEMU into a bunch= of different daemons that all implement device emulation in slightly different ways.=C2=A0 The user complexity is enormous and the ability to manage the complexity because impossible because nothing is centralized.<= br>
I think you misunderstand me. In some sense I'm agreeing with you. I agree you don't want to split QEMU into a bunch of daemons, which is why I think you handle the smart card remotely only with spice. Currently QEMU doesn't have the infrastructure to handle lots of different client devices (pretty much only if there is some preexisting client like vnc that handles those things).

In some sense we seem to be talking cross purposes here. I agree that QEMU isn't the right place to handle client side devices. It's clearly not in the QEMU model, so it makes sense NOT to emulate on the client side for QEMU...
It seems to me that the best way to go is to provide the native host =3D=3D client support like other devices and allow the passthru. If you really need client support, just run spice (which is a single client daemon that handles everything).

Let's not confuse passthrough with implementing device emulation outside of QEMU.=C2=A0 They are two very different things.

I think a remote passthrough protocol who's sole purpose is to allow external device emulation is a bad idea for QEMU.
The passthru is passthru. I'm not sure what you mean here.... I'm presuming the way forward is to have passthru and qemu implementing a local smart card emulation. I'm fine with just passthru and local emulation to a local smart card.

After talking to Alon in IRC, I think a better model for Spice would be to integrate the smart card emulation into QEMU and then develop a specific protocol for the smart card emulation to interface with the physical smart card.=C2=A0 This interface isn't really any different than= the network interface or the block interface in QEMU today.
I seems to me that a second protocol is overkill. Having 2 protocols is a bit much to manage. We can do everything we need with the passthru.
How is external device emulation not overkill?=C2=A0 I don't see why two protocols are necessary.=C2=A0 You just need one.
If you have one for passthru and one for emulated cards, that's two protocols.
My worry about creating any thing else is we may not have the flexibility to handle future cards. Smart cards themselves are programmable, so the interface for new cards are pretty dynamic.

My worry is that we're creating an impossible situation to maintain in the long term because device emulation is happening in 10 different places.=C2=A0 If there's a bug in your smart card emulation, a guest can = now break into a Spice client.=C2=A0 Part of the advantage of keeping everyth= ing contained in a single place (QEMU) is that we can restrict QEMU from a security perspective via sVirt and other mechanisms.=C2=A0 Once you split= apart device emulation, you break that security model.
That's true whether I'm emulating on qemu or not. If there is a bug in the emulation code, you can break out. If there is a bug in the client side driver, you can break out. The risk is exactly the same.

But again, this is academic, I'm not advocating doing this in qemu. Clearly there needs to be more work before we can even talk about qemu client side devices where client !=3D host.

bob

--------------000705020509040702000505-- --------------ms030906060001060706000903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITcDCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGmDCCBYCgAwIBAgIDAaw8MA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTAwOTMwMTg0NjA4 WhcNMTExMDAyMTUyMjEwWjCBkDEgMB4GA1UEDRMXMjY3NDEzLUlnZG1pYU9TQ25FTm5GdGsx HjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRDb20gRnJl ZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVkaGF0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/vMdJyaf8cVx+DOHsFocCxBTlQ XlBFrvoMW3a/keL27AOWJCkLcSPRMzIBvmQe4DDISs1I+pe4CXn/ZKTTP8DBDkWr/vQEeXKW nT47SnY6a5Kb/IHaw3vJJDjPkXUSkTMeKrp+4rSorGEf6jUrreyrHC6phjIGqKWMLcSxfkQy i3IPtfhbXC3IHsa3om/2rGNkA3Ocal4OZDS5gxVgNrxATYxvncdheLN0fHerquWIRyY4z+2A BtzSJ0t4Ixj7bvyxFToywUGHpHgiK/0Mrz2J55auJ9Rh/EqXHqJxnqB71yijjzkUzdYvE+Ke ZxxUJwkWTaMNI2YwzWq3gUJQyoUCAwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUFYpMA40TM+1C BCDr1I3jdoQkNHQwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYw FIEScnJlbHllYUByZWRoYXQuY29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwEC AjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmls aXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5z dGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5j b20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQw IwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQAHFhOPN0nFgE+8h1PaW2cm0WGqkiOyrGerZx0WaGknFqrWzbwNiNbEEIAWS153n94P3T9S RsZrGTT7zf0yR2E2132twrbqYAMcIY8OgDuufm5aCHVZDNGUYqFdSFPqlSW6t5jkqsA3JYs5 5bGyBb9pcS8/gyyO6gOOkH2WbAaS85D0K7LxqwsHZa9B/X+OxJX+3SxK/J14mlLSOYO7veZ7 e5ynM5NEeVzA53E8WDLcZuEjFTf72/v7LmmDry1hbCF+LvEOKFAyco1BaK753wVkKrVRPLdR Nv3G6uepR6SPpb3M9QGRLNY6WQC0HxRQw32h6irknRRauASYZggT3mtzMIIGmDCCBYCgAwIB AgIDAaw8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0EwHhcNMTAwOTMwMTg0NjA4WhcNMTExMDAyMTUyMjEwWjCBkDEgMB4GA1UEDRMXMjY3NDEz LUlnZG1pYU9TQ25FTm5GdGsxHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcG A1UEAxMgU3RhcnRDb20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEW EnJyZWx5ZWFAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/v MdJyaf8cVx+DOHsFocCxBTlQXlBFrvoMW3a/keL27AOWJCkLcSPRMzIBvmQe4DDISs1I+pe4 CXn/ZKTTP8DBDkWr/vQEeXKWnT47SnY6a5Kb/IHaw3vJJDjPkXUSkTMeKrp+4rSorGEf6jUr reyrHC6phjIGqKWMLcSxfkQyi3IPtfhbXC3IHsa3om/2rGNkA3Ocal4OZDS5gxVgNrxATYxv ncdheLN0fHerquWIRyY4z+2ABtzSJ0t4Ixj7bvyxFToywUGHpHgiK/0Mrz2J55auJ9Rh/EqX HqJxnqB71yijjzkUzdYvE+KeZxxUJwkWTaMNI2YwzWq3gUJQyoUCAwEAAaOCAvswggL3MAkG A1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUFYpMA40TM+1CBCDr1I3jdoQkNHQwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ ljVO8tS4UYIwHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQuY29tMIIBQgYDVR0gBIIBOTCC ATUwggExBgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMq IG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxh YmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAr oCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDAroCmgJ4YlaHR0 cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5 BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50 L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xh c3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v MA0GCSqGSIb3DQEBBQUAA4IBAQAHFhOPN0nFgE+8h1PaW2cm0WGqkiOyrGerZx0WaGknFqrW zbwNiNbEEIAWS153n94P3T9SRsZrGTT7zf0yR2E2132twrbqYAMcIY8OgDuufm5aCHVZDNGU YqFdSFPqlSW6t5jkqsA3JYs55bGyBb9pcS8/gyyO6gOOkH2WbAaS85D0K7LxqwsHZa9B/X+O xJX+3SxK/J14mlLSOYO7veZ7e5ynM5NEeVzA53E8WDLcZuEjFTf72/v7LmmDry1hbCF+LvEO KFAyco1BaK753wVkKrVRPLdRNv3G6uepR6SPpb3M9QGRLNY6WQC0HxRQw32h6irknRRauASY ZggT3mtzMYID0DCCA8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIDAaw8MAkGBSsOAwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMTAxNTAwMTYyNFowIwYJKoZIhvcNAQkEMRYEFFmDnfdrxMlo7/7qHtsj g77c2QTNMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJ KwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwGs PDCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQIDAaw8MA0GCSqGSIb3DQEBAQUABIIBADbpNDHRHBotQtNJspF5mi9Y3qxMEdrmUKqz u+t6mJyx8BLpUprHQUh7uDqzPdAug0TnhWdp2ruYXbU+lvMEXMxXYBnw92tgaDSaCJgqrf1F ADxnIGM5BKCVCDBb6/Dq53XdssP/9J+QLxBE9sEZO/eoK9Zhsby4IrIJrhfuruMOdiWetVkV v52KAMom5KMO85dwo1SeRLCWjlfO1pXHwAU+bAZuj9dErUZcU2VFiT9+8l7iz0mpT9LmSrna Kbqcjn4cPySzwRCeXQzVlbmD5hTP4VUiW24Qf27Xm19SuS1F7dm6TRg6qnb79gDrHmPaC3yq FXzZCBQ+FqzW7N6p3G8AAAAAAAA= --------------ms030906060001060706000903--