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 69DDBEB64D9 for ; Tue, 27 Jun 2023 15:02:47 +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=Kc+UneCerg6isMoHBCZr6aBjUH+KNtp/KMFdJCSSv5w=; b=0nkXslv97eQEy4 NkCZtQ0QdejIyYHj7RD7miUmqTmTi0dCMNpMf/Y9PwVZM4+DsMAoztf7t9mGBnCN+r/PwxZjtdYxu 9uE3MVfnNjocwG2FbaWRbYy/m/ZsqEupYLEWz+aNpYPLqGwfdYroL95BNrIYdHF896QbnQHQ5GlPQ MAfhgV/rGoCWQj3rMK1my8POZvTQAvSn1vX6ohebmay5DLFgb4tsIJ5aQandFOEEsrCOr9+RRvXL/ 9yp18JF70/aYCptPNN7cWaLzBXqM7MdPOKFFoqL1ZA01toL/HERIcdrQ7Nj3ENSVHnW/rFccamIao w1p6yGINrA5BjjSb0AXw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qEACo-00DSFu-2X; Tue, 27 Jun 2023 15:02:10 +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 1qEACm-00DSFQ-1X for linux-arm-kernel@lists.infradead.org; Tue, 27 Jun 2023 15:02:10 +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=lm2B+toKdSt4xGmOr45PJgoZcdhddjnjzFK0N3VH0RI=; b=GLVTm5qlgP5AMBx9ZFy8G09hMU jHimAu5o6BRpCVHMnr27deuI9ncQhGOdvte0eSFu41VTOPbaNaQkDgR2p6KovRB4VghgQAzYd3QzG xpyzmthagFC8Cyq1M2c4SHpgyIDfYhTlCfq6w2zfseSAd7plYQ9Qi/VlWohXgmVocP05TM6lY8A/z bCvsKZfIPa74q5m2Prr+sPXNpjKOqd36gR7714LFWpqtWReVPVQ06qI0w0287RN+SL4gZDTbEgtvU hcyXtGAbWqkVmy3hf7UgIv6Otj4ED/vofkF47IkDgUwbAZCy8WFPcRaXFUZNIxI2ZYYJnf3H4IXGJ bSdsb4EA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:41582) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qEACj-00053Y-18; Tue, 27 Jun 2023 16:02:06 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1qEACi-0005oj-QL; Tue, 27 Jun 2023 16:02:04 +0100 Date: Tue, 27 Jun 2023 16:02:04 +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-1-bigeasy@linutronix.de> <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_080208_669470_EE8CED2E X-CRM114-Status: GOOD ( 42.30 ) 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 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. -- 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