From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122293 invoked by alias); 27 Mar 2018 06:31:31 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 122016 invoked by uid 89); 27 Mar 2018 06:31:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*i:sk:sq8RrNw, H*f:sk:sq8RrNw X-HELO: mx1.redhat.com Subject: Re: RFA: Need to extend x86 psABI to support thread cancellation and alternate signal stack To: "H.J. Lu" , GNU C Library , GCC Development , Carlos O'Donell References: From: Florian Weimer Message-ID: Date: Tue, 27 Mar 2018 06:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-03/txt/msg00561.txt.bz2 On 03/27/2018 12:43 AM, H.J. Lu wrote: > On Linux, when alternate signal stack is used with thread cancellation, > _Unwind_Resume fails when it tries to unwind shadow stack from signal > handler on alternate signal stack. The issue is that signal handler on > alternate signal stack uses a separate shadow stack and we must switch > to the original shadow stack to unwind it. But frame count will be wrong > in this case. For thread cancellation, there is no need to unwind shadow > stack since it will long jump back and exit. > > One possibility is > > 1. Add _URC_NO_REASON_CANCEL. > 2. unwind_stop in libpthread returns _URC_NO_REASON_CANCEL. > 3. _Unwind_ForcedUnwind_Phase2 sets frames to 1 for > _URC_NO_REASON_CANCEL I assume the sequence of events goes like this: 1. The program receives a signal with a SA_ONSTACK handler. 2. The program switches to the alternate signal stack (including an alternate shadow stack) and runs the handler. 3. The handler reaches a cancellation point. 4. Cancellation is acted upon. During unwinding, INCSSP is executed as needed. The switch from the alternate signal stack is implicit in the SP register restore. But there is no corresponding stack switch back to the original shadow stack. This means that INCSSP faults once the alternate stack is empty. Is this description accurate? I think this has to be fixed entirely within the libgcc unwinder. Otherwise, any application which throws from a (synchronous) signal handler will have the same issue, and I think this is something we need to support. It may be possible to implement this without kernel changes: Patch the interrupted context to continue unwinding, and then call sigreturn to switch both stacks at the same time. Thanks, Florian