From nobody Thu Nov 18 18:41:29 2021 X-Original-To: freebsd-current@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 0505A18A5FFE for ; Thu, 18 Nov 2021 18:41:42 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 4Hw7tY6Gz2z3Qgn for ; Thu, 18 Nov 2021 18:41:41 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lf1-x12c.google.com with SMTP id f18so30742251lfv.6 for ; Thu, 18 Nov 2021 10:41:41 -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=jeyv0SbDAht7cVXGpPhGjNmwFJjADvneH4tCy52viwQ=; b=7iGgBEhYAcD+ACIojntqorGheI/tGa1ytm4qbXkBTUk26kzDa7J1qrugNF30a0Q2Az BXmms0Pju8WOcO/2jy0VweqLj2K4+TCJjJiibQ7x/xAw3/nZu2J8KOwPWvRYWEhE3oLJ tG3OxN8VdOhcJOvXDJmX7DAt9XTc0UlhL981BksMnY5Jyhqcp1upjRXhSHqDAmDVLIve ScYUoNG+TjSO1Mv0OvQl4OLZdBqSwIc8dgSGAT+1c1uxFhPYuB1dG5B3kT+/S+1e4rAw 3lwEcmxc7MsJrs2jOpObW1GEoAcI/Z0vCsE2oFbl3Y6MGV/+NRr+RPV2PnVrmBFE6Jfj 1upg== 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=jeyv0SbDAht7cVXGpPhGjNmwFJjADvneH4tCy52viwQ=; b=BHi0Y6oDeEAXa249UvO1REmIuz2CNBtnxxikOo4ror6P7XEojtPcyIK+EoSRikSTVD OrjaNANppI1CPLJB6atz8EUW7jFC6Z63YlroYmrD1T0ekLOSXq9SLpST6ZPh1+zskW9V 0cQM4PHybfmgwSQNTgZRMqjTT84XFEm8xCbhI+yK2+PU/3fT4nA7qmIuI9Jy4boTl+NZ xM3Jlt2X6FC3X/deM4MawpmxzHnk0H86Aez6quGpW+uOpTjbn8+TYe0eBLdUdPxhdWuD tZqxPeK6HP66Oh7l4j8H8rGZHT+e8untfK+g05Wh4hFNiP3IHMbS59Eszg1pcZ8TZuLU jOkA== X-Gm-Message-State: AOAM531iFkH+2pSHEl2Ex6mohtY9nxRRYbKAbwwZMpjj7DKwNgYxuUw5 81+Ffs1O0KQ23+vS9a4ShBWR9iBDFni+ysiD/KQnQA== X-Google-Smtp-Source: ABdhPJxwX4T/4I3stAOIarW+iFcX9xhz26SRWzuOb0dLGngZ3kwxrdY+UK87yuGVxpE6jVqEC0MxcWK3sBTuiNAM4v8= X-Received: by 2002:a05:6512:10c2:: with SMTP id k2mr26463025lfg.209.1637260900351; Thu, 18 Nov 2021 10:41:40 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Thu, 18 Nov 2021 19:41:29 +0100 Message-ID: Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main To: Li-Wen Hsu Cc: freebsd-current , Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Hw7tY6Gz2z3Qgn 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, czw., 18 lis 2021 o 19:07 Li-Wen Hsu napisa=C5=82(a): > > On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote: > > > > As of b014e0f15bc7 the ASLR (Address Space Layout > > Randomization) feature becomes enabled for the all 64-bit > > binaries by default. > > > > Address Space Layout Randomization (ASLR) is an exploit mitigation > > technique implemented in the majority of modern operating systems. > > It involves randomly positioning the base address of an executable > > and the position of libraries, heap, and stack, in a process's address > > space. Although over the years ASLR proved to not guarantee full OS > > security on its own, this mechanism can make exploitation more difficul= t > > (especially when combined with other methods, such as W^X). > > > > Tests on the tier 1 64-bit architectures demonstrated that the ASLR is > > stable and does not result in noticeable performance degradation, > > therefore it is considered safe to enable this mechanism by default. > > Moreover its effectiveness is increased for PIE (Position Independent > > Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by > > default on 64-bit architectures"), building from src is not necessary > > to have PIE binaries and it is enough to control usage of ASLR in the > > OS solely by setting the appropriate sysctls. The defaults were toggled > > for the 64-bit PIE and non-PIE executables. > > > > As for the drawbacks, a consequence of using the ASLR is more > > significant VM fragmentation, hence the issues may be encountered > > in the systems with a limited address space in high memory consumption > > 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 changed > > at this time. Also, for the sake of safety the feature remains disabled > > 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 processes, > > making target's environment different between debug and > > non-debug runs. > > > > The known issues (such as PR239873 or PR253208) have been fixed in > > HEAD up front, however please pay attention to the system behavior afte= r > > upgrading the kernel to the newest revisions. > > In order to confirm/rule-out the dependency of any encountered issue > > on ASLR it is strongly advised to re-run the test with the feature > > 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 > > > > The change is a result of combined efforts under the auspices > > of the FreeBSD Foundation and the Semihalf team sponsored > > by Stormshield. > > > > Best regards, > > Marcin > > Thanks very much for working on this. FYI, there are some test cases > seem to be affected by this: > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/ > > The mkimg ones are a bit tricky, it seems the output is changed in > each run. We may need a way to generate reproducible results.. > > I'm still checking them, but hope more people can join and fix them. > Thanks for bringing this up! Apart from sys.netpfil.common.dummynet.pf_nat other are 23 are new. I checked a couple of next builds and the results seems to be consistent. There are: lib.libc.sys.setrlimit_test.setrlimit_stack lib.libc.regex.exhaust_test.regcomp_too_big sys.kern.coredump_phnum_test.coredump_phnum and 20 of usr.bin.mkimg.* We will also check and try to fix the new issues (however any help would be appreciated), it may be also worth to create dedicated tickets in bugzilla. Best regards, Marcin