From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id E16973858D1E for ; Wed, 2 Aug 2023 13:17:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E16973858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690982256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xPgPKT0Vq/zj4PIjkN/vppR6Jtk9L7FK2Vz6a0u8kFU=; b=gNQ6fKrbN6fQ4T94A/dwt9zokR6YVeAB0+iRiSs6Kjr88kjqKXrEZcNLScyHtCRHDE4fYr yqXaBAU9cSKTJImrGYSK25CFm+8AP8xHBgQR+TkP1OCvF+Bv/WY5G0k3Kcj+pqUk3oJhT0 8dBLhifrQh0obu+HdAfSGle7C6STQeA= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-237-22YIfCFkM_WDcOqphDIEuA-1; Wed, 02 Aug 2023 09:17:35 -0400 X-MC-Unique: 22YIfCFkM_WDcOqphDIEuA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1133A3810D49; Wed, 2 Aug 2023 13:17:35 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 768082166B25; Wed, 2 Aug 2023 13:17:34 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Netto Cc: Adhemerval Zanella via Libc-alpha , Carlos O'Donell Subject: Re: [PATCH 1/2] setjmp: Use BSD sematic as default for setjmp References: <20230731171900.4065501-1-adhemerval.zanella@linaro.org> <20230731171900.4065501-2-adhemerval.zanella@linaro.org> <871qgn5fds.fsf@oldenburg.str.redhat.com> <40947004-fcac-d50c-feea-3a6512a10d69@linaro.org> <87cz05yivp.fsf@oldenburg.str.redhat.com> <87r0olsjiq.fsf@oldenburg.str.redhat.com> Date: Wed, 02 Aug 2023 15:17:33 +0200 In-Reply-To: (Adhemerval Zanella Netto's message of "Wed, 2 Aug 2023 09:48:11 -0300") Message-ID: <87jzudshw2.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Adhemerval Zanella Netto: > On 02/08/23 09:42, Florian Weimer wrote: >> * Adhemerval Zanella Netto: >> >>> On 02/08/23 04:59, Florian Weimer wrote: >>>> * Adhemerval Zanella Netto: >>>> >>>>> On 01/08/23 05:35, Florian Weimer wrote: >>>>>> * Adhemerval Zanella via Libc-alpha: >>>>>> >>>>>>> POSIX relaxed the relation of setjmp/longjmp and the signal mask >>>>>>> save/restore, meaning that setjmp does not require to be routed to >>>>>>> _setjmp to be standard compliant. >>>>>>> >>>>>>> This is done to avoid breakage of SIGABRT handlers, since to fully >>>>>>> make abort AS-safe, it is required to remove the recurisve lock >>>>>>> used to unblock SIGABRT prior raised the signal. >>>>>>> >>>>>>> Also, it allows caller to actually use setjmp, since from >>>>>>> 7011c2622fe3e10a29dbe74f06aaebd07710127d the symbol is unconditionally >>>>>>> routed to _setjmp. >>>>>> >>>>>> Doesn't this have non-trivial performance impact? >>>>> >>>>> Yes, it is two extra sigprocmask to get/set the signal mask. This is >>>>> not *strictly* required, but the SIGABRT on abort generates racy >>>>> conditions on process creation and. This patch can be dropped, but it >>>>> would mean that to get expected semantic for abort handlers will need >>>>> to use sigsetjmp (..., 1) instead of setjmp. >>>> >>>> Sorry, I don't understand? With the current locking, this change should >>>> really not be required because the user SIGABRT handler does not run >>>> with the signal mask changed. >>>> >>> >>> This change is only required to keep the same semantic of setjmp/longjmp >>> regarding SIGABRT handler, where current code keeps subsequent SIGABRT >>> installed with default flags to not keep the signal masked. Otherwise, >>> users that callers that handle SIGABRT will need to either a different >>> sigaction mask that do no change the blocked signals while handling >>> the signal, call sigprocmask after SIGABRT returns from longjmp, or >>> use sigsetjmp. >> >> Sorry, I still don't see it. The new code switches the handler to >> SIG_DFL atomically and blocks further sigaction calls. This extends to >> subprocesses because creating them is inhibited, too. I think this >> means that the difference in signal handler masking is not observable. > > But this change it no to handle if raise returns, but rather if you have > a SIGABRT handler that does not (like the fortify tests) installed with > default flags. In this case, the kernel will add SIGABRT on the masked > signal, longjmp will return to setjmp with the SIGBRT handler set mask, > and the next SIGABRT won't trigger the handler Ahh, you mean because use removed the signal unblocking from abort? If the signal is blocked, it is not delivered before it is unblocked. This means that the handler will not observe it blocked. But POSIX says this: | The abort() function shall override blocking or ignoring the SIGABRT | signal. It also says: | The SIGABRT signal shall be sent to the calling process as if by means | of raise() with the argument SIGABRT. Strictly speaking, it is impossible to comply with both requirements, but I think the handler is expected to run even if SIGABRT is blocked. As far as I understand it, the new code terminates the process in this case, without ever running the handler. Thanks, Florian