From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 679E542D59; Mon, 26 Jun 2023 12:39:58 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EBCFC41149; Mon, 26 Jun 2023 12:39:57 +0200 (CEST) Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by mails.dpdk.org (Postfix) with ESMTP id 3A1124067B for ; Mon, 26 Jun 2023 12:39:56 +0200 (CEST) Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-262c6718d14so425023a91.2 for ; Mon, 26 Jun 2023 03:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; t=1687775995; x=1690367995; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kPCHBsrwd9yoGHebQzGj7cPhYYc7mQskwVq85ciKzKs=; b=h0cg1G1umIMegZK5JPZ4Ln2d4yUnLdl7LSUhkwkxZW0cAqpr0ePF/VKQKKMjNPwYNp WpVf4R15nIXpwycCetk+6fEHIpglIpxYcOKGZeohRDLbqbfb7XACXSRAbZusw0zuCc+D T3ehXJyHkbFfml4sqINCh3x8/Nb7UVy9w+dtBYVtAKMQhEW1LK7Iw+ebu92QtiZ4w6U1 hAq/wzSKygwziLqow0fEgD8nWTirCk0WOEgW9N4GUFCephYcHQMmNkkI9n6XiZpckRS4 Net7DOg4ozNuM9xT3UVJ3Se40y2OcxdLSDHnPG47nipxUeTnZrX0GqU407KUnUIgvPRq btDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687775995; x=1690367995; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kPCHBsrwd9yoGHebQzGj7cPhYYc7mQskwVq85ciKzKs=; b=WyzUQr11YF7Wu5BYiVajhQBm9SOikKdPkEEVr88PaSTzGPV/ytiI/c0WrBOwo6VmHp 8xX2SmWB2uMWbuu/ABvQ7GXjrakUHrtAXJ4V2773kVdl/XHgsiBwpTIvM7Ee+tDHz3J1 pX1mNYIqjKSPGHL4y5Km3Pwtl4S5ID8yZum1V9flCebisuatzFXfxdSCGPmhwv5LlRQg xFnqP8wSSMa9lRYPuhV11i9Z1Ruesja62F8N3gOOOHF3Hb6jZkIUTuKvGPXxLrYUCG8D TwgLecLq0f4oW6h80lul/XioXK8M6UjBwHhaFaUWBij9/yZrIrEjZTw4YlVUFCOEcGEz aKWw== X-Gm-Message-State: AC+VfDzUv0z4POqCoRlugcFtJ+2NNlxUpNxg0FjnrM7cVtw8LDRi4rDB SBep0SAuKMz4QqCsYV3hYzJbdLE4/1rve65FI0ZlPw== X-Google-Smtp-Source: ACHHUZ5NptcPnLagA3l7YEQTelyhc+XQHw+uFyOI8lmQYoKMDo1z2EaYgql3JaCf+mDpA1Xqne8rCff0DwfGlOON2vA= X-Received: by 2002:a17:90a:64cc:b0:262:fab9:b12 with SMTP id i12-20020a17090a64cc00b00262fab90b12mr677808pjm.45.1687775995333; Mon, 26 Jun 2023 03:39:55 -0700 (PDT) MIME-Version: 1.0 References: <20230418145619.2648068-1-didier.pallard@6wind.com> <2809888.Y6S9NjorxK@thomas> <1720411.yIU609i1g2@thomas> In-Reply-To: <1720411.yIU609i1g2@thomas> From: Didier Pallard Date: Mon, 26 Jun 2023 12:39:44 +0200 Message-ID: Subject: Re: [PATCH] crypto/openssl: do not build useless workaround To: Thomas Monjalon Cc: Kai Ji , gakhil@marvell.com, dev@dpdk.org, stable@dpdk.org, Daniel Mrzyglod , Tomasz Kulasek , Michal Kobylinski , Pablo de Lara , Slawomir Mrozowicz Content-Type: multipart/alternative; boundary="000000000000a9a4ac05ff05f887" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000a9a4ac05ff05f887 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2023 at 12:04=E2=80=AFPM Thomas Monjalon wrote: > 26/06/2023 11:13, Didier Pallard: > > HI, > > not sure to understand how it is possible. > > If build OPENSSL_VERSION_NUMBER < 0x10100000L, linker should link > binary > > with libcrypto.so.1.0.0. > > libcrypto.so.1.1 if build for 0x10100000L and libcrypto.so.3 for > > 0x30000000L > > loader should not allow to link with a library different from the one > used > > at build time, no? > > You are probably right. > libcrypto.so.1.1 and libcrypto.so.1.0 are incompatible versions? > I think so. Can someone else confirm? > If we are linking against libcrypto.so.1.1 and you did exactly > a check for lower than libcrypto.so.1.1, then it should be OK. > > > > On Sun, Jun 25, 2023 at 9:22=E2=80=AFPM Thomas Monjalon > wrote: > > > > > 18/04/2023 16:56, Didier Pallard: > > > > This workaround was needed before version 1.0.1f. Do not build it f= or > > > > versions >=3D 1.1. > > > > > > > > Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL > library") > > > > Signed-off-by: Didier Pallard > > > > Cc: stable@dpdk.org > > > [...] > > > > +#if OPENSSL_VERSION_NUMBER < 0x10100000L > > > > /* Workaround open ssl bug in version less then 1.0.1f */ > > > > if (EVP_EncryptUpdate(ctx, empty, &unused, empty, 0) <=3D 0) > > > > goto process_auth_encryption_gcm_err; > > > > +#endif > > > > > > What happens if we build with OpenSSL 1.1 and run with OpenSSL 1.0? > > > Can we have a runtime check? > > > Or is it better doing the workaround always as before? > > > > --000000000000a9a4ac05ff05f887 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 26, 2023 at 12:04=E2=80= =AFPM Thomas Monjalon <thomas@mon= jalon.net> wrote:
26/06/2023 11:13, Didier Pallard:
> HI,
> not sure to understand how it is possible.
> If build=C2=A0 OPENSSL_VERSION_NUMBER <=C2=A0 0x10100000L, linker s= hould link binary
> with libcrypto.so.1.0.0.
> libcrypto.so.1.1 if build for 0x10100000L and libcrypto.so.3 for
> 0x30000000L
> loader should not allow to link with a library different from the one = used
> at build time, no?

You are probably right.
libcrypto.so.1.1 and libcrypto.so.1.0 are incompatible versions?
I think so. Can someone else confirm?
=C2=A0
=
If we are linking against libcrypto.so.1.1 and you did exactly
a check for lower than libcrypto.so.1.1, then it should be OK.


> On Sun, Jun 25, 2023 at 9:22=E2=80=AFPM Thomas Monjalon <thomas@monjalon.net> = wrote:
>
> > 18/04/2023 16:56, Didier Pallard:
> > > This workaround was needed before version 1.0.1f. Do not bui= ld it for
> > > versions >=3D 1.1.
> > >
> > > Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for = OpenSSL library")
> > > Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
> > > Cc: sta= ble@dpdk.org
> > [...]
> > > +#if OPENSSL_VERSION_NUMBER < 0x10100000L
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Workaround open ssl bug in vers= ion less then 1.0.1f */
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0if (EVP_EncryptUpdate(ctx, empty, = &unused, empty, 0) <=3D 0)
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto p= rocess_auth_encryption_gcm_err;
> > > +#endif
> >
> > What happens if we build with OpenSSL 1.1 and run with OpenSSL 1.= 0?
> > Can we have a runtime check?
> > Or is it better doing the workaround always as before?



--000000000000a9a4ac05ff05f887--