From nobody Thu Nov 18 15:28:52 2021 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4DA79188E90C; Thu, 18 Nov 2021 15:29:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hw3cZ3jmGz3M9B; Thu, 18 Nov 2021 15:29:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f182.google.com with SMTP id i9so1341188ilu.1; Thu, 18 Nov 2021 07:29:18 -0800 (PST) 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:content-transfer-encoding; bh=APgSH0H+l9LIZxgBIPx5QGCBXHZ3Lp1MpOvF2uXWlK8=; b=6OPO9iDBrVIujEmPXYvpH6fnmekp7lLguXK6lfKjhc96NeomwF49X8CR5zyWWnJMl/ ba3UsI5C1Ea9kVS0q7fy5HpTN+gD9javjF7VVYP1mMFYVBbe350D1ybelqzH4bpdx1F5 9pYxjpKGV0pOZUlq2ezMlwwK1m1D7o/Bovfg4+NshDjiO+d5OUQCmfBClSKiZ4jNIH78 RTxwndwX1KNfGYNGzP3zJLr1ims+bwn3+LJy9kYGzdMoiFuC76ux/iNGZO1eo1R+rHQA LJFXmgpFIkIrAUe3VwrpAitZNkh56AH30UbvtAggqHlBy476sVIWY6hmTHwxvKtS6vOc TWxw== X-Gm-Message-State: AOAM532pen/QBar9oVHncSsTl0otN6Zck+m6DRWvM5UUPev7lPa0b4qO fsLVWOsgwaFUngcLjFudOG+gZgZPKmGk/GaxPCk69h9Q+WI= X-Google-Smtp-Source: ABdhPJwiRT72NqlWINAADbKwst5LUZD7LghTa8x6N9IYiKyUZBD7IxaxnXALac+12iRCSus/W1uCz/tkaRs3mSQ8tg4= X-Received: by 2002:a92:d081:: with SMTP id h1mr16181087ilh.7.1637249352428; Thu, 18 Nov 2021 07:29:12 -0800 (PST) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202111162226.1AGMQg00099240@gitrepo.freebsd.org> <20211117054034.jr6wdl5o42dv2kb6@mutt-hbsd> In-Reply-To: <20211117054034.jr6wdl5o42dv2kb6@mutt-hbsd> From: Ed Maste Date: Thu, 18 Nov 2021 10:28:52 -0500 Message-ID: Subject: Re: git: b014e0f15bc7 - main - Enable ASLR by default for 64-bit executables To: Shawn Webb Cc: Kubilay Kocak , Marcin Wojtas , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Hw3cZ3jmGz3M9B X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.182:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.182:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Wed, 17 Nov 2021 at 00:40, Shawn Webb wrote= : > > It also doesn't make much sense to toggle AS{L}R for the different > parts of an executable image. AS{L}R is an "all or nothing" thing. There's not toggles for different parts of an executable image. The aslr_enable and pie_aslr_enable sysctls are for two different types of ELF objects. As for aslr_honor_sbrk, sbrk(2) is a legacy memory management interface - from the man page: The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. They are deprecated and n= ot present on the arm64 or riscv architectures. The mmap(2) interface should be used to allocate pages instead. The brk() and sbrk() functions are used to change the amount of memory allocated in a process's data segment. They do this by moving the location of the =E2=80=9Cbreak=E2=80=9D. The break is the first addre= ss after the end of the process's uninitialized data segment (also known as the =E2=80=9CB= SS=E2=80=9D). aslr_honor_sbrk determines whether the kernel reserves a region for brk/sbrk to grow into. If set to 1 the kernel reserves this area, and randomly-addressed mappings will not be placed there.