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 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@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.

-- 
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