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=-12.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 65B49C48BC2 for ; Fri, 25 Jun 2021 08:23:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4EEC061426 for ; Fri, 25 Jun 2021 08:23:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229839AbhFYIZx (ORCPT ); Fri, 25 Jun 2021 04:25:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229878AbhFYIZw (ORCPT ); Fri, 25 Jun 2021 04:25:52 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09B0BC061574 for ; Fri, 25 Jun 2021 01:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Mime-Version:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=jDI5hW3GgEPHVoue/If3RmdOtbGfuMxHWCSdjOkljvg=; b=mVdHKYkENYkNW0w6FINsO+w7TG 5LZma73i363/RYJior7/M+bjTtPZ2jii0RURjNN1z1HxGAJv4dwKCflZaaY+ELf7UUH6nkNncZfG0 i5AIXer4IU2UYric+tP6qz1edV7kQpwUA27kN98m5YshshUgqTGmdk0Zeg8pKPveO1JbqxHYl8w8v S5d8UvJqgNulsDsBlBHIj9EiR81ZBlzFOclwGu3vHqD4RjW1gNX+GDa7qzJ3BUy+fY45elRHrAkDd HRPQAAfm3ixhkrH8HXyNCdu0+IInV5J911sNt2OhtJDLYGN/zN9Rd7yW6F+AmW7cJjD3Il1YC7Bos u69zo6Nw==; Received: from [2001:8b0:10b:1::3ae] (helo=u3832b3a9db3152.ant.amazon.com) by bombadil.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwh7Z-000IQw-NA; Fri, 25 Jun 2021 08:23:30 +0000 Message-ID: <4b33ed9ac98c28e8980043d482cc3549acfba799.camel@infradead.org> Subject: Re: [PATCH v3 1/5] net: add header len parameter to tun_get_socket(), tap_get_socket() From: David Woodhouse To: Jason Wang , netdev@vger.kernel.org Cc: Eugenio =?ISO-8859-1?Q?P=E9rez?= , Willem de Bruijn Date: Fri, 25 Jun 2021 09:23:27 +0100 In-Reply-To: <8bc0d9b7-b3d8-ddbb-bcdc-e0169fac7111@redhat.com> References: <03ee62602dd7b7101f78e0802249a6e2e4c10b7f.camel@infradead.org> <20210624123005.1301761-1-dwmw2@infradead.org> <8bc0d9b7-b3d8-ddbb-bcdc-e0169fac7111@redhat.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-yi1cl3fh583v9Yrq7LFE" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org --=-yi1cl3fh583v9Yrq7LFE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2021-06-25 at 13:00 +0800, Jason Wang wrote: > =E5=9C=A8 2021/6/24 =E4=B8=8B=E5=8D=888:30, David Woodhouse =E5=86=99=E9= =81=93: > > From: David Woodhouse > >=20 > > The vhost-net driver was making wild assumptions about the header lengt= h > > of the underlying tun/tap socket. >=20 >=20 > It's by design to depend on the userspace to co-ordinate the vnet header= =20 > setting with the underlying sockets. >=20 >=20 > > Then it was discarding packets if > > the number of bytes it got from sock_recvmsg() didn't precisely match > > its guess. >=20 >=20 > Anything that is broken by this? The failure is a hint for the userspace= =20 > that something is wrong during the coordination. I am not a fan of this approach. I firmly believe that for a given configuration, the kernel should either *work* or it should gracefully refuse to set it up that way. And the requirements should be clearly documented. Having been on the receiving end of this "hint" of which you speak, I found it distinctly suboptimal as a user interface. I was left scrabbling around trying to find a set of options which *would* work, and it was only through debugging the kernel that I managed to work out that I: =E2=80=A2 MUST set IFF_NO_PI =E2=80=A2 MUST use TUNSETSNDBUF to reduce the sndbuf from INT_MAX =E2=80=A2 MUST use a virtio_net_hdr that I don't want If my application failed to do any of those things, I got a silent failure to transport any packets. The only thing I could do *without* debugging the kernel was tcpdump on the 'tun0' interface and see if the TX packets I put into the ring were even making it to the interface, and what they looked like if they did. (Losing the first 14 bytes and having the *next* 14 bytes scribbled on by an Ethernet header was a fun one.) > >=20 > > Fix it to get the correct information along with the socket itself. >=20 >=20 > I'm not sure what is fixed by this. It looks to me it tires to let=20 > packet go even if the userspace set the wrong attributes to tap or=20 > vhost. This is even sub-optimal than failing explicitly fail the RX. I'm OK with explicit failure. But once I'd let it *get* the information from the underlying socket in order to decide whether it should fail or not, it turned out to be easy enough just to make those configs work anyway. The main case where that "easy enough" is stretched a little (IMO) was when there's a tun_pi header. I have one more of your emails to reply to after this, and I'll address that there. >=20 > > As a side-effect, this means that tun_get_socket() won't work if the > > tun file isn't actually connected to a device, since there's no 'tun' > > yet in that case to get the information from. >=20 >=20 > This may break the existing application. Vhost-net is tied to the socket= =20 > instead of the device that the socket is loosely coupled. Hm. Perhaps the PI and vnet hdr should be considered an option of the *socket* (which is tied to the tfile), not purely an option of the underlying device? Or maybe it's sufficient just to get the flags from *either* tfile->tun=20 or tfile->detached, so that it works when the queue is detached. I'll take a look. I suppose we could even have a fallback that makes stuff up like we do today. If the user attempts to attach a tun file descriptor to vhost without ever calling TUNSETIFF on it first, *then* we make the same assumptions we do today? > > --- a/drivers/vhost/net.c > > +++ b/drivers/vhost/net.c > > @@ -1143,7 +1143,8 @@ static void handle_rx(struct vhost_net *net) > > =20 > > vq_log =3D unlikely(vhost_has_feature(vq, VHOST_F_LOG_ALL)) ? > > vq->log : NULL; > > - mergeable =3D vhost_has_feature(vq, VIRTIO_NET_F_MRG_RXBUF); > > + mergeable =3D vhost_has_feature(vq, VIRTIO_NET_F_MRG_RXBUF) && > > + (vhost_hlen || sock_hlen >=3D sizeof(num_buffers)); >=20 >=20 > So this change the behavior. When mergeable buffer is enabled, userspace= =20 > expects the vhost to merge buffers. If the feature is disabled silently,= =20 > it violates virtio spec. >=20 > If anything wrong in the setup, userspace just breaks itself. >=20 > E.g if sock_hlen is less that struct virtio_net_hdr_mrg_buf. The packet= =20 > header might be overwrote by the vnet header. This wasn't intended to change the behaviour of any code path that is already working today. If *either* vhost or the underlying device have provided a vnet header, we still merge. If *neither* provide a vnet hdr, there's nowhere to put num_buffers and we can't merge. That code path doesn't work at all today, but does after my patches. But you're right, we should explicitly refuse to negotiate VIRITO_NET_F_MSG_RXBUF in that case. >=20 > > =20 > > do { > > sock_len =3D vhost_net_rx_peek_head_len(net, sock->sk, > > @@ -1213,9 +1214,10 @@ static void handle_rx(struct vhost_net *net) > > } > > } else { > > /* Header came from socket; we'll need to patch > > - * ->num_buffers over if VIRTIO_NET_F_MRG_RXBUF > > + * ->num_buffers over the last two bytes if > > + * VIRTIO_NET_F_MRG_RXBUF is enabled. > > */ > > - iov_iter_advance(&fixup, sizeof(hdr)); > > + iov_iter_advance(&fixup, sock_hlen - 2); >=20 >=20 > I'm not sure what did the above code want to fix. It doesn't change=20 > anything if vnet header is set correctly in TUN. It only prevents the=20 > the packet header from being rewrote. >=20 It fixes the case where the virtio_net_hdr isn't at the start of the tun header, because the tun actually puts the tun_pi struct *first*, and *then* the virtio_net_hdr.=20 The num_buffers field needs to go at the *end* of sock_hlen. Not at a fixed offset from the *start* of it. At least, that's true unless we want to just declare that we *only* support TUN with the IFF_NO_PI flag. (qv). --=-yi1cl3fh583v9Yrq7LFE Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCECow ggUcMIIEBKADAgECAhEA4rtJSHkq7AnpxKUY8ZlYZjANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTkwMTAyMDAwMDAwWhcNMjIwMTAxMjM1 OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZyYWRlYWQub3JnMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAsv3wObLTCbUA7GJqKj9vHGf+Fa+tpkO+ZRVve9EpNsMsfXhvFpb8 RgL8vD+L133wK6csYoDU7zKiAo92FMUWaY1Hy6HqvVr9oevfTV3xhB5rQO1RHJoAfkvhy+wpjo7Q cXuzkOpibq2YurVStHAiGqAOMGMXhcVGqPuGhcVcVzVUjsvEzAV9Po9K2rpZ52FE4rDkpDK1pBK+ uOAyOkgIg/cD8Kugav5tyapydeWMZRJQH1vMQ6OVT24CyAn2yXm2NgTQMS1mpzStP2ioPtTnszIQ Ih7ASVzhV6csHb8Yrkx8mgllOyrt9Y2kWRRJFm/FPRNEurOeNV6lnYAXOymVJwIDAQABo4IB0zCC Ac8wHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFLfuNf820LvaT4AK xrGK3EKx1DE7MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAeBgNVHREEFzAVgRNkd213MkBpbmZy YWRlYWQub3JnMA0GCSqGSIb3DQEBCwUAA4IBAQALbSykFusvvVkSIWttcEeifOGGKs7Wx2f5f45b nv2ghcxK5URjUvCnJhg+soxOMoQLG6+nbhzzb2rLTdRVGbvjZH0fOOzq0LShq0EXsqnJbbuwJhK+ PnBtqX5O23PMHutP1l88AtVN+Rb72oSvnD+dK6708JqqUx2MAFLMevrhJRXLjKb2Mm+/8XBpEw+B 7DisN4TMlLB/d55WnT9UPNHmQ+3KFL7QrTO8hYExkU849g58Dn3Nw3oCbMUgny81ocrLlB2Z5fFG Qu1AdNiBA+kg/UxzyJZpFbKfCITd5yX49bOriL692aMVDyqUvh8fP+T99PqorH4cIJP6OxSTdxKM MIIFHDCCBASgAwIBAgIRAOK7SUh5KuwJ6cSlGPGZWGYwDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDEwMjAwMDAwMFoXDTIyMDEwMTIz NTk1OVowJDEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALL98Dmy0wm1AOxiaio/bxxn/hWvraZDvmUVb3vRKTbDLH14bxaW /EYC/Lw/i9d98CunLGKA1O8yogKPdhTFFmmNR8uh6r1a/aHr301d8YQea0DtURyaAH5L4cvsKY6O 0HF7s5DqYm6tmLq1UrRwIhqgDjBjF4XFRqj7hoXFXFc1VI7LxMwFfT6PStq6WedhROKw5KQytaQS vrjgMjpICIP3A/CroGr+bcmqcnXljGUSUB9bzEOjlU9uAsgJ9sl5tjYE0DEtZqc0rT9oqD7U57My ECIewElc4VenLB2/GK5MfJoJZTsq7fWNpFkUSRZvxT0TRLqznjVepZ2AFzsplScCAwEAAaOCAdMw ggHPMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBS37jX/NtC72k+A CsaxitxCsdQxOzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2Nh LmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZHdtdzJAaW5m cmFkZWFkLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAC20spBbrL71ZEiFrbXBHonzhhirO1sdn+X+O W579oIXMSuVEY1LwpyYYPrKMTjKECxuvp24c829qy03UVRm742R9Hzjs6tC0oatBF7KpyW27sCYS vj5wbal+TttzzB7rT9ZfPALVTfkW+9qEr5w/nSuu9PCaqlMdjABSzHr64SUVy4ym9jJvv/FwaRMP gew4rDeEzJSwf3eeVp0/VDzR5kPtyhS+0K0zvIWBMZFPOPYOfA59zcN6AmzFIJ8vNaHKy5QdmeXx RkLtQHTYgQPpIP1Mc8iWaRWynwiE3ecl+PWzq4i+vdmjFQ8qlL4fHz/k/fT6qKx+HCCT+jsUk3cS jDCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI5Or1u6zf +bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+RKwrB6vcf WlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4yNNwTqza aPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDK CMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAU u69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1Ud DwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8E RTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9u QXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2 SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs 0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDM KVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfH M5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJM/1t yZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJUmpvVdZ4o gnzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8YXLI8nAb R9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDyjCCA8YCAQEwga0wgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA4rtJSHkq7AnpxKUY8ZlYZjANBglghkgB ZQMEAgEFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEw NjI1MDgyMzI3WjAvBgkqhkiG9w0BCQQxIgQg7SMov45425s84Q09iirif2F3cMSqch+mei2vs5mI Ui8wgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQDiu0lIeSrsCenEpRjxmVhmMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDiu0lIeSrsCenEpRjxmVhmMA0GCSqGSIb3 DQEBAQUABIIBAARPQlv4H7Tsss1BmUfq3gv3Sgm5xa+DNMO12bQWZFI2pcKZ9n7WiOFdivAozx6R aj7srbgYAjiUFIUCGof40OoiECfofHl77W67OfdNavIxwEzU9gIZyezHekfDt1+aSPcmQoT7ujGx bVJXI+vDNGPWrrUQpVrcyHZeZ5OxLCcnAK7hLNaQ79WI6c9WFTHADgrLH6ffji/sZPepU1WLUTYk zGfZtVVdpE2KZUZlzNPL08qxiBtpgHWvS8tpH+UvL1Ut5jQ9QepKmIMXLtVS3yr5ZEVg01hoZKEN /1Yupn8SyuEgKG5vSdEvRLKgEa1BFyHa5eXDVTfPnDK2Ps0UQhIAAAAAAAA= --=-yi1cl3fh583v9Yrq7LFE--