From nobody Wed Nov 17 20:08:34 2021 X-Original-To: dev-commits-src-all@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 A3FB118A5401 for ; Wed, 17 Nov 2021 20:08:47 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 4HvYsW3t3Qz4khZ for ; Wed, 17 Nov 2021 20:08:47 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lf1-x12b.google.com with SMTP id y26so14072460lfa.11 for ; Wed, 17 Nov 2021 12:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e97sq6wMyLFYhcGHCUuH1iMaUELMEx4HXqcNa3EoOX8=; b=6uz1Nr2efSe3LZZ/Su9Dsh0BQEuSWMOp+71OhpG9tvnoR4AuumUuxRd/ReLM1mVUSn xLsdbm0p5PKt24TzrfDcky9nkHOwHskQ++dYiGvsu4+VxlZ13AQUXsQ+105tQ0tcZww5 KA6fY6oj0Zm88ylptqQQjcrwlREQ0zix+vpd07YeXos+22INWDNklTGswHqNFpWNCQkn oZ3hsSQDni4EC7EHTT0Y/W+R9TWsCOPHGeyH3jb8BxQf/4H/CPb8PMD7dFFrVRxMSOwf 5tjpEmo5/e1ieW2J9QHpPfrR6sT/TXkxZz7eVpPgw6O81xMU7x1CjNmIjt29WJVAE+tP D7Bw== 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=e97sq6wMyLFYhcGHCUuH1iMaUELMEx4HXqcNa3EoOX8=; b=heivP5pvAa8MeCkEGjuuX9bTRgjQ0pai6OAtz97m+UDqSnvuKV86x1ADwmJkmrKtfO hhA2bn4eTSFqp0uXv/Cc0I6IM032iGUkOItfjdO6PD5DXL5gV1Lrew4U6sFnMw5tm3Ad S/CdSb34XaPS9+MX0V+yGnBr0HZy2DO09vC7VE25wkNkt6bBVmEuSm/g/4HE96KabbSV 9DOta8LZyr0bawwvul9Og7QpnaYP+cv307cL+TARlDJmzOoJPYnyedvfOXzi66hUm3/f jsYngMqyotgCOSiv15txuwX5yrTlN8CVdtdV7kO3M9ADcKYVCUVZ7DumLB5fGLji0E1D 3Rig== X-Gm-Message-State: AOAM530fF3dZiMGoVzoh2slr2eIATjudyqv7xECtEKB9vQOH0cvavkQ5 gD2zOHKEogxjDq4dBLM3W5p8XxSJnL4zeNdVQOyH5IU2FqupDw== X-Google-Smtp-Source: ABdhPJygOa0ODnNlLprGs+/t9o4wIHsS4oTJlvcQ6/nHjag6XsNLdIlsvsFVDFgx4LoMf6oCItkRO7sc3htBVXj7Fwo= X-Received: by 2002:a05:651c:113b:: with SMTP id e27mr10630992ljo.474.1637179725287; Wed, 17 Nov 2021 12:08:45 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202111162226.1AGMQg00099240@gitrepo.freebsd.org> <20211117054034.jr6wdl5o42dv2kb6@mutt-hbsd> In-Reply-To: <20211117054034.jr6wdl5o42dv2kb6@mutt-hbsd> From: Marcin Wojtas Date: Wed, 17 Nov 2021 21:08:34 +0100 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-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4HvYsW3t3Qz4khZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, =C5=9Br., 17 lis 2021 o 06:40 Shawn Webb napis= a=C5=82(a): > > On Wed, Nov 17, 2021 at 10:42:12AM +1100, Kubilay Kocak wrote: > > On 17/11/2021 9:26 am, Marcin Wojtas wrote: > > > The branch main has been updated by mw: > > > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=3Db014e0f15bc73d80ef49b6= 4fd1f8c29f469467cb > > > > > > commit b014e0f15bc73d80ef49b64fd1f8c29f469467cb > > > Author: Marcin Wojtas > > > AuthorDate: 2021-10-24 14:53:06 +0000 > > > Commit: Marcin Wojtas > > > CommitDate: 2021-11-16 22:16:09 +0000 > > > > > > Enable ASLR by default for 64-bit executables > > > Address Space Layout Randomization (ASLR) is an exploit mitigati= on > > > technique implemented in the majority of modern operating system= s. > > > It involves randomly positioning the base address of an executab= le > > > and the position of libraries, heap, and stack, in a process's a= ddress > > > space. Although over the years ASLR proved to not guarantee full= OS > > > security on its own, this mechanism can make exploitation more d= ifficult. > > > Tests on the tier 1 64-bit architectures demonstrated that the A= SLR is > > > stable and does not result in noticeable performance degradation= , > > > therefore it should be safe to enable this mechanism by default. > > > Moreover its effectiveness is increased for PIE (Position Indepe= ndent > > > Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE= by > > > default on 64-bit architectures"), building from src is not nece= ssary > > > to have PIE binaries. It is enough to control usage of ASLR in t= he > > > OS solely by setting the appropriate sysctls. > > > This patch toggles the kernel settings to use address map random= ization > > > for PIE & non-PIE 64-bit binaries. It also disables SBRK, in ord= er > > > to allow utilization of the bss grow region for mappings. The la= tter > > > has no effect if ASLR is disabled, so apply it to all architectu= res. > > > As for the drawbacks, a consequence of using the ASLR is more > > > significant VM fragmentation, hence the issues may be encountere= d > > > in the systems with a limited address space in high memory consu= mption > > > cases, such as buildworld. As a result, although the tests on 32= -bit > > > architectures with ASLR enabled were mostly on par with what was > > > observed on 64-bit ones, the defaults for the former are not cha= nged > > > at this time. Also, for the sake of safety keep the feature disa= bled > > > for 32-bit executables on 64-bit machines, too. > > > The committed change affects the overall OS operation, so the > > > following should be taken into consideration: > > > * Address space fragmentation. > > > * A changed ABI due to modified layout of address space. > > > * More complicated debugging due to: > > > * Non-reproducible address space layout between runs. > > > * Some debuggers automatically disable ASLR for spawned proces= ses, > > > making target's environment different between debug and > > > non-debug runs. > > > In order to confirm/rule-out the dependency of any encountered i= ssue > > > on ASLR it is strongly advised to re-run the test with the featu= re > > > disabled - it can be done by setting the following sysctls > > > in the /etc/sysctl.conf file: > > > kern.elf64.aslr.enable=3D0 > > > kern.elf64.aslr.pie_enable=3D0 > > > Co-developed by: Dawid Gorecki > > > Reviewed by: emaste, kib > > > Obtained from: Semihalf > > > Sponsored by: Stormshield > > > MFC after: 1 month > > > Differential revision: https://reviews.freebsd.org/D27666 > > > --- > > > sys/kern/imgact_elf.c | 20 +++++++++++++++++--- > > > 1 file changed, 17 insertions(+), 3 deletions(-) > > > > > > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c > > > index 898f0f66a532..38ad61d8720b 100644 > > > --- a/sys/kern/imgact_elf.c > > > +++ b/sys/kern/imgact_elf.c > > > @@ -161,19 +161,33 @@ SYSCTL_NODE(__CONCAT(_kern_elf, __ELF_WORD_SIZE= ), OID_AUTO, aslr, > > > ""); > > > #define ASLR_NODE_OID __CONCAT(__CONCAT(_kern_elf, __ELF_WORD_S= IZE), _aslr) > > > -static int __elfN(aslr_enabled) =3D 0; > > > +/* > > > + * While for 64-bit machines ASLR works properly, there are > > > + * still some problems when using 32-bit architectures. For this > > > + * reason ASLR is only enabled by default when running native > > > + * 64-bit non-PIE executables. > > > + */ > > > +static int __elfN(aslr_enabled) =3D __ELF_WORD_SIZE =3D=3D 64; > > > SYSCTL_INT(ASLR_NODE_OID, OID_AUTO, enable, CTLFLAG_RWTUN, > > > &__elfN(aslr_enabled), 0, > > > __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) > > > ": enable address map randomization"); > > > -static int __elfN(pie_aslr_enabled) =3D 0; > > > +/* > > > + * Enable ASLR only for 64-bit PIE binaries by default. > > > + */ > > > +static int __elfN(pie_aslr_enabled) =3D __ELF_WORD_SIZE =3D=3D 64; > > > SYSCTL_INT(ASLR_NODE_OID, OID_AUTO, pie_enable, CTLFLAG_RWTUN, > > > &__elfN(pie_aslr_enabled), 0, > > > __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) > > > ": enable address map randomization for PIE binaries"); > > > > The current description seems ambiguous with respect to the added comme= nt. > > If the sysctl (=3D1) applies ASLR "only" for PIE binaries, where the = =3D0 > > (sysctl disabled) case applies it unconditionally, a better description > > might be: > > > > "Enable address map randomization only for PIE binaries" > > > > What is the actual/correct behaviour of the control? > > 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. > Really, there should be only a single toggle with four modes: > > 1. AS{L}R force disable > 2. AS{L}R opt out > 3. AS{L}R opt in > 4. AS{L}R force enable > I think a single knob can simplify the situation, I'd need to take a look if that's easily achievable. What's the use case of the opt in/out options? Best regards, Marcin > HardenedBSD has found that users get confused or are unsure of having > too many toggles. "What happens when I do ?" In this case, you'd > probably have to have deeper knowledge of how FreeBSD's AS{L}R is > implemented. Having a single sysctl knob makes life easier for users > and reduces implementation complexity. > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc