From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 299F23858408 for ; Tue, 2 Aug 2022 23:35:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 299F23858408 Received: by mail-pl1-x62b.google.com with SMTP id d16so6745177pll.11 for ; Tue, 02 Aug 2022 16:35:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=9dJoNblV1ZRHb/7+TQ5uffjQCYN4AK7yBgZEh1EbYzs=; b=39oiDA9+b7Lpnmuu2AvILlWvbnNDaW+HxiWvuPYcZ62jTrj2b/RTceF8B2cC/qm6Pz lTeZsxPJfuXnWep5W9g06sBdKD41FdkgG/s0g6s6JTy6Sjg30x8TJRmiBcrcBk3cVXC9 Ziv3AaWDse5K7OYL3UOLNnTqUNSkVsNME11IclLQ1zkycvZkuKRZcmWYZuk+1hrXi7Ib f8tTgwM94Q23o2sFHsCcykWBMnWqBeA+nJH9/zkRqL4+mwrBod/TxF6ZzEJrFcehgQ3d Iqk6QUJ1YFdvzm447XRg+BXCRUgsJ6Rj2WGiO+ZVD9eoseny0qQw3PaHXc9wSwWsLqHz 0pDg== X-Gm-Message-State: ACgBeo1zxEld39tGQnyCllq8+hydXbJiMC3KQyuvedTY8b9dKDO1ADjQ iphSZ9pNO04z6t8XYZyz/ZI= X-Google-Smtp-Source: AA6agR5wF0m8DDdm80fJyBqBWjzk+cclKCHNrYDYsTvJd28dyRHvmn1HnLyaxz09OBo2IgOPiR+VTw== X-Received: by 2002:a17:902:8693:b0:16c:db86:1c86 with SMTP id g19-20020a170902869300b0016cdb861c86mr23447042plo.9.1659483299043; Tue, 02 Aug 2022 16:34:59 -0700 (PDT) Received: from [172.31.0.204] (c-73-98-188-51.hsd1.ut.comcast.net. [73.98.188.51]) by smtp.gmail.com with ESMTPSA id x5-20020a654545000000b0041bff78c095sm4833518pgr.1.2022.08.02.16.34.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Aug 2022 16:34:58 -0700 (PDT) Message-ID: Date: Tue, 2 Aug 2022 17:34:57 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] stack-protector: Check stack canary for noreturn function Content-Language: en-US To: "H.J. Lu" Cc: GCC Patches References: <20220714215522.359952-1-hjl.tools@gmail.com> <8088866d-2dd2-35ff-587b-567cb60db84e@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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 23:35:02 -0000 On 8/2/2022 11:43 AM, H.J. Lu wrote: > 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? That's the question I think we need to answer.  The EH paths are a known security issue on Windows and while ours are notably different I'm not sure if there's a real attack surface in those paths.  My sense is that if we need to tackle this that doing so on the throw side might be better as it's closer conceptually to when//how we check the canary for a normal return. jeff > > -- > H.J.