From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 8FDA4386F465 for ; Mon, 11 May 2020 20:18:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8FDA4386F465 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jYEsc-0005D7-Kc; Mon, 11 May 2020 20:18:26 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jYEsc-0000Tn-Hs; Mon, 11 May 2020 22:18:26 +0200 From: Florian Weimer To: Adhemerval Zanella Cc: Adhemerval Zanella via Libc-alpha , Szabolcs Nagy Subject: Re: [PATCH 11/12] aarch64: redefine RETURN_ADDRESS to strip PAC References: <20200430173458.GV29015@arm.com> <20200430174518.GG29015@arm.com> <60967e5e-f6fb-c556-d7fb-ec3c737ed2fd@linaro.org> <20200511123850.GI7649@arm.com> <2cb466d5-fae2-d746-45ce-eab06e30562e@linaro.org> <8736865lbm.fsf@mid.deneb.enyo.de> Date: Mon, 11 May 2020 22:18:26 +0200 In-Reply-To: (Adhemerval Zanella's message of "Mon, 11 May 2020 17:13:43 -0300") Message-ID: <87blmu444t.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 20:18:36 -0000 * Adhemerval Zanella: > On 11/05/2020 16:21, Florian Weimer wrote: >> * Adhemerval Zanella via Libc-alpha: >> >>> On 11/05/2020 09:38, Szabolcs Nagy wrote: >>>> The 05/08/2020 14:44, Adhemerval Zanella via Libc-alpha wrote: >>>>> On 30/04/2020 14:45, Szabolcs Nagy wrote: >>>>>> +++ b/sysdeps/aarch64/sysdep.h >>>>>> @@ -35,6 +35,16 @@ >>>>>> >>>>>> #define PTR_SIZE (1<>>>>> >>>>>> +/* Strip pointer authentication code from pointer p. */ >>>>>> +#define XPAC(p) ({ \ >>>>>> + register void *__ra asm ("x30") = (p); \ >>>>>> + asm ("hint 7 // xpaclri" : "+r"(__ra)); \ >>>>>> + __ra;}) >>>>>> + >>>>>> +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ >>>>>> +#undef RETURN_ADDRESS >>>>>> +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) >>>>>> + >>>>> >>>>> Maybe use a inline function instead? >>>> >>>> macro seems more reliable to me than always_inline >>>> when poking at __builtin_return_address and x30, >>>> but i'm not against always_inline if that's >>>> considered better. >>> >>> I would prefer a static inline unless a macro is really required >>> (either due some compiler limitation or bug). >> >> I think __builtin_return_address is ill-defined: Does the frame count >> that vanishes due to inlining? >> >> So it's probably a case similar to alloca, where a macro has to be >> used. > > This is at least what documentation states [1]: > > "When inlining the expected behavior is that the function returns the address > of the function that is returned to. To work around this behavior use the > noinline function attribute." > > [1] https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html Hmm, okay. It's still weird not to count those frames, but at least it's documented.