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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 74EC8C001B3 for ; Tue, 27 Jun 2023 17:42:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+IKfHd1Y22+Mj9jwYXnNNbAXRJtTlYLhkuv5i1VYF8g=; b=L4zrznYXOzc09M VKldEyfGhULc0j5sMV6j07fCwh/F8TitY3Oa1hE7qeO5AfPEt8uXggumb+73bm27ovX2t0o4KR7Z7 soOK6uS8iUkqLLDk2ow8InVkyq/7uHlhVk8sxruVkegByMZoRno6uYDWuofKVn6JPL1wfiP4/63L6 SttxpqtMmpCzMdB1OvsAqNFjOJNUbwO1q1dmeU0mYFwdmDhywiNdyd7bbtDTeFNw8YZdasiFd8qin K/YY7Ig3LfSSpNhhWmIk8wKysAq3qtMLMaGKp/kQCWOVOj7I2e5khQvlcEGEWIc3jKWuGsrmLZMVn uGspscFiUwNAefYno/NA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qEChL-00DkWH-2s; Tue, 27 Jun 2023 17:41:51 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qEChH-00DkUw-2k for linux-arm-kernel@lists.infradead.org; Tue, 27 Jun 2023 17:41:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kO2iKXXsZET/G5610pexMUWAdoIUZJiBA68vBWtBGeA=; b=kxDC4SecgZavL3ZYnWJimp1ekX pDqhq+Nn25lvTMqF+MnKlnKrALxhBNhX7E8h9L2aXADhvIIp4lPU7s23SmnU0pT1waqChZzj6T4KP OXQew+Gq0HciqgyraIXRuuDPr9UK5Wu3SPGrIyoO6588m/40VbgOIOItsTmgfHcw7v114+gvEuHKF OIM94mpOlqsrKN/FznavuQZVTbSwT/Gw6PnmSq4XxWUxlRGRYfveK9mstTwovxBn1o5fjsDhAaVQ5 Wsz0hqc4gep77YdgMVtlW9lYxCDaDQJW1Aqfvnm2Q3G0882itkqJSHOSdDZ45NXCjTujOiVnMHq30 J3DZyFSw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:53300) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qECh2-0005K8-2Z; Tue, 27 Jun 2023 18:41:32 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1qECh2-0005v0-63; Tue, 27 Jun 2023 18:41:32 +0100 Date: Tue, 27 Jun 2023 18:41:32 +0100 From: "Russell King (Oracle)" To: Ard Biesheuvel Cc: Sebastian Andrzej Siewior , linux-arm-kernel@lists.infradead.org, Thomas Gleixner Subject: Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). Message-ID: References: <20230615101656.1308942-4-bigeasy@linutronix.de> <20230627124100.10UOAye6@linutronix.de> <20230627130602.bawVcRiS@linutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230627_104148_362128_704E54A9 X-CRM114-Status: GOOD ( 49.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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) > > > > 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! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel