From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) by sourceware.org (Postfix) with ESMTPS id 969473AA9C5F for ; Thu, 24 Jun 2021 11:33:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 969473AA9C5F Received: by mail-qk1-x72d.google.com with SMTP id bl4so13518179qkb.8 for ; Thu, 24 Jun 2021 04:33:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7OZRlGw5QTvg5x9uwTnxf4To3m8GLytlEY9ET/ReNcY=; b=SY22DO5YsEY8Avc0I4kAQpn70yfLS6YeKsCNkPtEOhK1o+zdU+gMHdDvu5rESQ8sFe WA4AYj/fJWuWWzOfExhgccetMiGpjnlL9gTarYYFjqVNh27wyhKceH9FHN+PFdTMqGrj esVOIPSYE/rkzB3vZblj+AIbkfmz6kraBgfsNqFVv7Td0rhh0V/d1xrhoq1sGIIR+8VR JljlkK1fUS8tdkNVWZGhm8L4T3pE5zAbZ6Pd0BCKHPW1eFOFT4DF9cZkEbhYdbaag8V3 tbkgmPU+pvq9uQKcVO3EDwpskJCJnMGYmd7cuIuam2uo6h35QJp4cdAEICjMZhP4d6SV p3AQ== X-Gm-Message-State: AOAM5304PJqhDv9HMsVBfNKt0am0PkKiNThco5FDHW29xGU66PX0oIbD Ub9HlzTvItP4D1zT0j1qcZxzOB7bilqnpg== X-Google-Smtp-Source: ABdhPJwDedR9/l9tkGM+6DfYR3DcBUGOY/1kGcVkM0pYv09X+rzbIfvTjjglUf7K0raNTWkzc+3mUQ== X-Received: by 2002:a05:620a:2052:: with SMTP id d18mr5104389qka.185.1624534417582; Thu, 24 Jun 2021 04:33:37 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id m19sm1745119qtp.93.2021.06.24.04.33.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Jun 2021 04:33:37 -0700 (PDT) Subject: Re: [PATCH v6 1/5] support: Add support_stack_alloc To: Florian Weimer , Adhemerval Zanella via Libc-alpha References: <20210623185115.395812-1-adhemerval.zanella@linaro.org> <20210623185115.395812-2-adhemerval.zanella@linaro.org> <87pmwblj3d.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Thu, 24 Jun 2021 08:33:35 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87pmwblj3d.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 11:33:39 -0000 On 24/06/2021 06:15, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> diff --git a/support/support_stack_alloc.c b/support/support_stack_alloc.c >> new file mode 100644 >> index 0000000000..08323f43d5 >> --- /dev/null >> +++ b/support/support_stack_alloc.c >> @@ -0,0 +1,76 @@ > >> + /* The guard bands need to be large enough to intercept offset >> + accesses from a stack address that might otherwise hit another >> + mapping. Make them at least twice as big as the stack itself, to >> + defend against an offset by the entire size of a large >> + stack-allocated array. The minimum is 1MiB, which is arbitrarily >> + chosen to be larger than any "typical" wild pointer offset. >> + Again, no matter what the number is, round it up to a whole >> + number of pages. */ >> + size_t guardsize = roundup (MAX (2 * stacksize, 1024 * 1024), pagesize); >> + size_t alloc_size = guardsize + stacksize + guardsize; >> + /* Use MAP_NORESERVE so that RAM will not be wasted on the guard >> + bands; touch all the pages of the actual stack before returning, >> + so we know they are allocated. */ >> + void *alloc_base = xmmap (0, >> + alloc_size, >> + PROT_NONE, >> + MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE|MAP_STACK, >> + -1); >> + xmprotect (alloc_base + guardsize, stacksize, PROT_READ | PROT_WRITE); >> + memset (alloc_base + guardsize, 0xA5, stacksize); >> + return (struct support_stack) { alloc_base + guardsize, >> + stacksize, guardsize }; >> +} > > Missing _STACK_GROWS_DOWN/_STACK_GROWS_UP support for guard location > handling, and missing executable stack handling (in case it's needed on > Hurd for trampolines; I'm not sure what the current state there is). > > But I see it was already missing, so maybe that's not a big deal. It seems a worth addition, I will update the patch.