From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [IPv6:2a01:4f8:1c0c:6b10::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E1F281F451 for ; Fri, 5 Jan 2024 21:25:16 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=vU2/GODr; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=eKaxHZ//; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id DC01381B68; Fri, 5 Jan 2024 21:25:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1704489908; bh=n1hveKpI/fI45hoXoYVH11sK/K+XVf93sRFx/m/X9Kc=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=vU2/GODrXT7d2uqcjMBbboKoHZ3S99dtqsKoPTJkyLNz82WyVF6YCw8D8hIWBOTnZ hxRaHYfQqEriZbiPzxLgDrLP5rtzryhgNlnohAIxOx4ATi0nHthd3QRYG6i20vbiLK JkqeS6iSSvbxcirAxEn8XKe5r34vXtE1tpovZ5hU= Received: from wrqvtvtt.outbound-mail.sendgrid.net (wrqvtvtt.outbound-mail.sendgrid.net [149.72.120.119]) by nue.mailmanlists.eu (Postfix) with ESMTPS id B86B2819B4 for ; Fri, 5 Jan 2024 21:25:04 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=eKaxHZ//; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=8zoc0PhM03oXoilat/MINLFHHtLnPWZGeCUkfJe9Tis=; b=eKaxHZ//4CbI43y/XksZEti+8bfJ/dRRJBFFhjCfWX2uu/mlE1EQFJ/VF/U57EJv1xnk KsjaDhRzug+2MQ96+ORoA0jfU5doJBJ2EYngVvufbifJZnPH8qVM6wOC6IbTfBMsRMinGY Cwud2ND2/Zj8loCHCigcbszqLWjFd4cFBv1ckbDehe9RV1oBVSixXsFILK5Qzboz7ehAiL PcZ6bjZREw/PHyfkkKq2zkh4s5iFLRRTjzUMXduHslDfHOd5dC4YZKzt8Bo8Jtz2Cl8qXv 5s8E04DQJPajIU0Xdw3iNKFPNIhIOwl+AEa6yMKF+V0c30CVSXEoPH+eq11PcfFg== Received: by filterdrecv-5bbdbb56cd-fdw6s with SMTP id filterdrecv-5bbdbb56cd-fdw6s-1-659873AF-26 2024-01-05 21:25:03.42882129 +0000 UTC m=+2179311.491091962 Received: from herokuapp.com (unknown) by geopod-ismtpd-28 (SG) with ESMTP id 3P7vrWeTRlSLXWECgBQxtQ for ; Fri, 05 Jan 2024 21:25:03.414 +0000 (UTC) Date: Fri, 05 Jan 2024 21:25:03 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20154 X-Redmine-Issue-Author: jprokop X-Redmine-Sender: jprokop X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 92601 X-SG-EID: =?us-ascii?Q?H46QOCwvUFDCSn1o93vkQf9On+EJgqdRglU6HFpNlmI8frpujmTYVnZabSPGoU?= =?us-ascii?Q?lDQV40KcZWXb9RAQvCkIsuKE+tb1ZdRBGPvmO6r?= =?us-ascii?Q?aYyKn+4ylsVbGvlavr7WUYV9C4mB0daP7uMRbn5?= =?us-ascii?Q?6GYX4LdWUVw=2FDz6OPvJbVnlz1t1feGGCsS8tAdY?= =?us-ascii?Q?E3O7dmPEedU8l9=2FEbAG3mWe8eSZx+Ozx555LjWD?= =?us-ascii?Q?mnhI2X2tlGUafw2z0ONIYdUqDzyzAYCY4YMHEP=2F?= =?us-ascii?Q?ndXiG9biAzSOyRsAc4Heg=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== Message-ID-Hash: VGN7HJJLWMYISH6COPKA3P4GMKOI4MGP X-Message-ID-Hash: VGN7HJJLWMYISH6COPKA3P4GMKOI4MGP X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:116039] [Ruby master Bug#20154] aarch64: configure overrides `-mbranch-protection` if it was set in CFLAGS via environment List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "jprokop (Jarek Prokop) via ruby-core" Cc: "jprokop (Jarek Prokop)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20154 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #20154: aarch64: configure overrides `-mbranch-protection` if it was set in CFLAGS via environment https://bugs.ruby-lang.org/issues/20154 * Author: jprokop (Jarek Prokop) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Recently a GH PR was merged For PAC/BTI support on ARM CPUs for Coroutine.S. Without proper compilation support in configure.ac it segfaults Ruby with fibers on CPUs where PAC is supported: https://bugs.ruby-lang.org/issues/20085 At the time of writing, configure.ac appends the first option from a list for flag `-mbranch-protection` that successfully compiles a program , to XCFLAGS and now also ASFLAGS to fix issue 20085 for Ruby master. This is suboptimal for Fedora as we set -mbranch-protection=standard by default in C{,XX}FLAGS: ``` CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ' export CFLAGS CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer' export CXXFLAGS ``` And the appended flag overrides distribution's compilation configuration, which in this case ends up omitting BTI instructions and only using PAC. Would it make sense to check if such flags exist and not overwrite them if they do? Serious proposals: 1. Simplest fix that does not overwrite what is set in the distribution and results in higher security is simply prepending the list of options with `-mbranch-protection=standard`, it should cause no problems on ARMv8 CPUs and forward, BTI similarly to PAC instructions result into NOP, it is only extending the capability. See attached 0001-aarch64-Check-mbranch-protection-standard-first-to-u.patch 2. Other fix that sounds more sane IMO and dodges this kind of guessing where are all the correct places for the flag is what another Fedora contributor Florian Weimer suggested: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CVTNF2OQCL3XZHUUFNYMDK6ZEF2SWUEN/ "The reliable way to do this would be to compile a C file and check whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case, define a *different* macro for use in the assembler implementation. This way, you don't need to care about the exact name of the option." IOW instead of using __ARM_FEATURE_* directly in that code, define a macro in the style of "USE_PAC" with value of the feature if it is defined, I think that way we shouldn't need to append ASFLAGS anymore. However it's also important to catch the value of those macros as their values have meaning, I have an idea how to do that but I'd get on that monday earliest. ---Files-------------------------------- 0001-aarch64-Check-mbranch-protection-standard-first-to-u.patch (1004 Bytes) -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/