[PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry().
Russell King (Oracle)
linux at armlinux.org.uk
Tue Jun 27 10:41:32 PDT 2023
On Tue, Jun 27, 2023 at 04:02:04PM +0100, Russell King (Oracle) wrote:
> On Tue, Jun 27, 2023 at 03:40:10PM +0100, Russell King (Oracle) wrote:
> > 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 at 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.
>
> And doing more digging...
>
> https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965706f9a062baaba0c494dd6efb2c306
>
> So, a change in what the mariadb developers thought was a good idea
> to report though this interface breaks the perl DBD library... and
> given that it effectively winds-back the value returned from
> mysql_get_client_version(), who knows if there's now any sane way of
> testing the numerical result of that function.
Oh, and this just keeps getting better.
Read the entire thread on:
https://github.com/mariadb-corporation/mariadb-connector-c/pull/219
Whoever thought it was a good idea that mysql_get_client_version()
should suddenly be wound back to a smaller number... clearly wasn't
thinking the implications through when users of the library are going
to be doing stuff like:
https://github.com/perl5-dbi/DBD-mysql/blame/master/dbdimp.h#L107
which is over six years old.
It really makes me wonder why we try in the kernel not to regress
userspace when userspace people don't themselves seem to "get it"
and make idiotic changes like this.
Anyway, I've now found what seems to be a workaround - telling perl's
DBD driver that SSL is optional turns off enforced SSL, and thus
stops the DBD driver checking the library version. Not ideal, but at
least it gets stuff working again, while the mariadb people work out
how to fix their gigantic cockup.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
More information about the linux-arm-kernel
mailing list