Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry().

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Jun 27, 2023 at 02:32:39PM +0100, Russell King (Oracle) wrote:
> On Tue, Jun 27, 2023 at 03:26:16PM +0200, Ard Biesheuvel wrote:
> > On Tue, 27 Jun 2023 at 15:22, Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > > as the patch system is down for the long term until Debian
> > > fix their mariadb security regression which prevents a server requiring
> > > a minimum of TLS v1.2 accepting connections from Debian Bookworm
> > > systems (which regress from supporting TLS v1.3 to a maximum of TLS
> > > v1.1).
> > >
> > > I reported this as a bug to the debian BTS last week, and as I have
> > > come to expect from useless waste of space distro bug tracking systems,
> > > there has been zero reaction - and as the bug has already been reported
> > > by others, and they've been fobbed off by the package maintainer, I am
> > > not hopeful that this regression will ever be fixed.
> > >
> > > It seems to me that Debian is ripe for having a CVE raised against
> > > Bookworm for the regression, especially as TLS v1.1 is now regarded
> > > as vulnerable due to downgrade attacks - and maybe that will make
> > > Debian sit up and take notice.
> > >
> > 
> > Does this mean the ARM tree is closed for business a the moment? Is
> > there no way to carry on without the patch system?
> 
> Only if you want to see just how utterly terrible I am trying to pick
> patches off the mailing list...
> 
> IMHO, the better thing would be to apply pressure to Debian to get
> them to at least recognise their cockup, so that then we have some
> idea when stuff can be resurected.

Doing a bit more digging, it seems my /usr/bin/mysql was leading me
somewhat astray - it was mariadb-client-core-10.1 despite following
the recommended debian upgrade path over the years - so that dates
from a time when TLS v1.1 was the max.

However, that's just a distraction. libdbd-mysql-perl refuses to
even attempt to connect - it seems to bail out before even trying.

The confusing thing is that /usr/bin/mysql was reporting error 2026,
and when one traces libdbd-mysql-perl, the trace file also reports
error 2026:

imp_dbh->bind_type_guessing: 0
imp_dbh->use_server_side_prepare: 0
imp_dbh->disable_fallback_for_server_prepare: 0
                --> do_error
SSL connection error: Enforcing SSL encryption is not supported error 2026 recorded: SSL connection error: Enforcing SSL encryption is not supported
                <-- do_error
    <> DESTROY(DBI::db=HASH(0x255d118)) ignored for outer handle (inner DBI::db=HASH(0x256ca80) has ref cnt 2)

However, these two error numbers, although identical, are totally
different. I haven't yet figured out where "error 2026" comes from
in libdbd-mysql-perl.

_This_ 2026 error comes from libdbd-mysql-perl itself, and after
quite a bit of research, it's due to:

        if (ssl_enforce) {	<== true
    #if defined(HAVE_SSL_MODE_ONLY_REQUIRED) <== not defined
...
    #elif defined(HAVE_SSL_ENFORCE) <== not defined
...
    #elif defined(HAVE_SSL_VERIFY) <== defined
              if (!ssl_verify_also_enforce_ssl()) {
                set_ssl_error(sock, "Enforcing SSL encryption is not supported");
                return NULL;
              }

ssl_verify_also_enforce_ssl() does this:

static inline bool ssl_verify_also_enforce_ssl(void) {
#ifdef MARIADB_BASE_VERSION
        my_ulonglong version = mysql_get_client_version();
        return ((version >= 50544 && version < 50600) || (version >= 100020 && version < 100100) || version >= 100106);
#else
        return false;
#endif
}

and mocking up a program to print the result from on Bookworm,
mysql_get_client_version() gives:

Version = 30305

Where does that come from...

#define MARIADB_CLIENT_VERSION_STR      "10.11.3"
#define MARIADB_BASE_VERSION            "mariadb-10.11"
#define MARIADB_VERSION_ID              101103
#define MYSQL_CONFIG_NAME               "my"
#define MYSQL_VERSION_ID                101103
#define MYSQL_SERVER_VERSION            "10.11.3-MariaDB"
#define MARIADB_PACKAGE_VERSION "3.3.5"
#define MARIADB_PACKAGE_VERSION_ID 30305

So, mysql_get_client_version() for mariadb reports the mariadb _package_
version, not the mysql version.

The same under Bullseye:

Version = 100519

#define MARIADB_CLIENT_VERSION_STR      "10.5.19"
#define MARIADB_BASE_VERSION            "mariadb-10.5"
#define MARIADB_VERSION_ID              100519
#define MYSQL_CONFIG_NAME               "my"
#define MYSQL_VERSION_ID                100519
#define MYSQL_SERVER_VERSION            "10.5.19-MariaDB"
#define MARIADB_PACKAGE_VERSION "3.1.20"
#define MARIADB_PACKAGE_VERSION_ID 30120

So, libdbd-mysql-perl believes that mariadb 10.11.3 is ancient compared
to mariadb 10.5.19.

I think I need to update that bug with this new information - and it
points to a mariadb problem, specifically with libmariadb, and not a
TLS regression after all.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel