From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 483123858D20 for ; Wed, 3 May 2023 05:47:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 483123858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1ab01bf474aso21190395ad.1 for ; Tue, 02 May 2023 22:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683092820; x=1685684820; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NFRFQvozToCD2GcPpKUPUyWr0UMF6z5dn/ZyXDRA5i8=; b=c5c75+SaoOEgUy0F52dO7B6RQaU0iRmiUfqRnA7P72Mlwo5gEPXXn4EczHYJkSuMEK dsxAa0VoulECzzY6eP6GVgL6pWz3Vzg0wn+Tl1cYmHv03FnKhl73swVR+Mjsm2L2C+kj HJaeWE064MYccGAwBSHPPMqOMDqfCLQn64+3lqrcEfOpHCT0x6E9YChoZvSktlI9W9/w O/OpDjYwIHEZJbNS6pmaCqWiBOK3yAgNYwJBu7Yxkt9824g8jKMsggD9AGzqLpJsWJjb D9IMyeUAoNqBRWiBUVmQpD0whyLl+MT1cDFMYmMitUe+N7ody28MIv3YGIgPuBo7fw6W JKKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683092820; x=1685684820; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NFRFQvozToCD2GcPpKUPUyWr0UMF6z5dn/ZyXDRA5i8=; b=dJnkFoqYQ9RHO8PGAVzIgUbYlU6pOr1g8qMUgVIYypNz/ObJXpc/pWhlOeb2zh0WAo rvhX/7IWiJPZ1ytjyI+miXFWYNRLCxFiSGdTJeYfJT5JCZpZOhD50oHgmlWIod28SRV7 dtOdqk/PlnGoGhir4wyrz8tuHJwlQwa+pHc0ZEjfXGz/3SOpSZ33+u9D6Wj/Dmoy8ybV yQro41epLt6DSYUftp5c24zoJTmAoS6/9wqEUhURFEga4+Ryrx3WOAdTIhd6dwbwc7lL eBiDUl7ipzYSNmM4vNK9d8iXegEq/t1ehflFAKCgf33YYHaWqv5fZ+RhoK+zr+ASBkDd NGng== X-Gm-Message-State: AC+VfDwRM8AC4mLE0cIsupi8UqcB5sdCRrUzy9A9XsotNJLH/FL11teh INjXWRNqoKWCh3A3oNsKFltY0sj2WEs= X-Google-Smtp-Source: ACHHUZ4CIegeKek2K3zhKV9F1zd0n9q2odhIGZg8IgldjN976REGPN3l8a8nqU2E7INUIAaJHPETGQ== X-Received: by 2002:a17:903:494:b0:1a1:bfe8:4fae with SMTP id jj20-20020a170903049400b001a1bfe84faemr1127568plb.43.1683092820360; Tue, 02 May 2023 22:47:00 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id p8-20020a1709026b8800b001a04ff0e2eesm20688941plk.58.2023.05.02.22.46.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 May 2023 22:46:59 -0700 (PDT) Message-ID: Date: Tue, 2 May 2023 23:46:58 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: Probe emission in fstack-clash-protection Content-Language: en-US To: gcc@gcc.gnu.org References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 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,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: On 5/2/23 22:36, Varun Kumar E via Gcc wrote: > Hello, > > https://godbolt.org/z/P3M8s8jqh > The above case shows that gcc first decreases the stack pointer and then > probes. > > As mentioned by Jeff Law (reference > ) > under "More issues with -fstack-check". If an asynchronous signal is > received between the decrement of stack pointer and probing of the pages. > *"In that case, the stack pointer could be pointing beyond the guard into > the heap. The signal arrives and the kernel transfers control to the > registered signal handler. That signal handler is then running while its > stack is pointing into the heap. Thus, the attacker has clashed the stack > and heap, and there's a reasonable chance they can gain control over the > program" * > > So, Shouldn't we first probe and if successful only then update the stack > pointer? Or Maybe I have understood it incorrectly. That may ultimately be better for -fstack-check to make it more robust, but it still wouldn't be a viable alternative for stack clash protection for the reasons laid out in that blog post. jeff