From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 30BE2385801B for ; Tue, 2 Aug 2022 17:44:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 30BE2385801B Received: by mail-pg1-x52b.google.com with SMTP id s206so12958272pgs.3 for ; Tue, 02 Aug 2022 10:44:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8egmJrCLr5Nj8Q8upslaWQlh2/v/B0Zdn3uF0cmHv1s=; b=Nayec8z8thl8QmfRJNS5/AdqjAO3QwcGXV2n5YP0CshbfE3/SIbTmxHQJnxWvfd8tn 5eUsYChJjmr990/7qnaTgZrmoPJGv+E9KCtUOFvwB9m7/GwCrCNdaB6Px7KlSmgiMh5p PI6TGkCnu+RqA7FG5ZZJCTHTM0NCy32WYde8EKYktk54RJabG0//8H0mAfv4GFPPMofT 0N9MOAln6g0PAaompRZrHToXpSqxR7bpmbU+kuG2RHALaj2dMfcYzxhMSc+96sBt4HnJ 3ZCk0nKjKC+AtVKTGRr2PW450zWlU9hFkvghbwgRG6XEu+4Ap+dXchN5k6LZgXsbK8Tk gBZw== X-Gm-Message-State: ACgBeo0lDlA4uUUqbYwv+DNWIfOmTYxGV6NnCcRDHRD8ZdaRN9pBqBFG OAObmyYRP84R56XFC7aY9chN5sKMwybjtmopIGo= X-Google-Smtp-Source: AA6agR6b+DFBSD9xBhFAovdz9z4BhQAr8Y2dRMgTSk6cocO+KIX4sAlburTtSxs7mw+xhdVbasEhSFx4Mr23bk4ig48= X-Received: by 2002:a05:6a00:1589:b0:52d:2f20:47e2 with SMTP id u9-20020a056a00158900b0052d2f2047e2mr15011958pfk.64.1659462272983; Tue, 02 Aug 2022 10:44:32 -0700 (PDT) MIME-Version: 1.0 References: <20220714215522.359952-1-hjl.tools@gmail.com> <8088866d-2dd2-35ff-587b-567cb60db84e@gmail.com> In-Reply-To: <8088866d-2dd2-35ff-587b-567cb60db84e@gmail.com> From: "H.J. Lu" Date: Tue, 2 Aug 2022 10:43:57 -0700 Message-ID: Subject: Re: [PATCH] stack-protector: Check stack canary for noreturn function To: Jeff Law Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2022 17:44:36 -0000 On Sat, Jul 30, 2022 at 1:30 PM Jeff Law via Gcc-patches wrote: > > > > On 7/14/2022 3:55 PM, H.J. Lu via Gcc-patches wrote: > > Check stack canary for noreturn function to catch stack corruption > > before calling noreturn function. For C++, check stack canary when > > throwing exception or resuming stack unwind to avoid corrupted stack. > > > > gcc/ > > > > PR middle-end/58245 > > * calls.cc (expand_call): Check stack canary for noreturn > > function. > > > > gcc/testsuite/ > > > > PR middle-end/58245 > > * c-c++-common/pr58245-1.c: New test. > > * g++.dg/pr58245-1.C: Likewise. > > * g++.dg/fstack-protector-strong.C: Adjusted. > But is this really something we want? I'd actually lean towards > eliminating the useless load -- I don't necessarily think we should be > treating non-returning paths specially here. > > The whole point of the stack protector is to prevent the *return* path > from going to an attacker controlled location. I'm not sure checking > the protector at this point actually does anything particularly useful. throw is marked no return. Since the unwind library may read the stack contents to unwind stack, it the stack is corrupted, the exception handling may go wrong. Should we handle this case? -- H.J.