Date: Fri, 19 Nov 2021 19:32:22 -0700 From: Kristof Provost <kp@freebsd.org> To: Marcin Wojtas <mw@semihalf.com> Cc: Li-Wen Hsu <lwhsu@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, Fabien Thomas <fabien.thomas@stormshield.eu>, MARECHAL Boris <boris.marechal@stormshield.eu>, Rafal Jaworowski <raj@semihalf.com>, Damien DEVILLE <damien.deville@stormshield.eu> Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main Message-ID: <AB060D84-8115-48B8-82F8-2C4E820BEB53@freebsd.org> In-Reply-To: <CAPv3WKfPtRjKtByneMEKv9gPSK8iCRJ-j847fGhkKUqmh4AtEw@mail.gmail.com> References: <CAPv3WKfPtRjKtByneMEKv9gPSK8iCRJ-j847fGhkKUqmh4AtEw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 18 Nov 2021, at 11:43, Marcin Wojtas <mw@semihalf.com> wrote:
> czw., 18 lis 2021 o 19:07 Li-Wen Hsu <lwhsu@freebsd.org> napisa=C5=82(a):
>>=20
>>> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas <mw@semihalf.com> wrote:
>>>=20
>>> As of b014e0f15bc7 the ASLR (Address Space Layout
>>> Randomization) feature becomes enabled for the all 64-bit
>>> binaries by default.
>>>=20
>>> 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 difficult=
>>> (especially when combined with other methods, such as W^X).
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> The known issues (such as PR239873 or PR253208) have been fixed in
>>> HEAD up front, however please pay attention to the system behavior after=
>>> 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
>>>=20
>>> The change is a result of combined efforts under the auspices
>>> of the FreeBSD Foundation and the Semihalf team sponsored
>>> by Stormshield.
>>>=20
>>> Best regards,
>>> Marcin
>>=20
>> Thanks very much for working on this. FYI, there are some test cases
>> seem to be affected by this:
>>=20
>> https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/
>>=20
>> 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..
>>=20
>> I'm still checking them, but hope more people can join and fix them.
>>=20
>=20
> Thanks for bringing this up! Apart from
> sys.netpfil.common.dummynet.pf_nat other are 23 are new.
I=E2=80=99ve just managed to reproduce that one locally (it only happens if i=
pfw is also loaded) and will dig in soon. It=E2=80=99s not going to be aslr r=
elated. You can ignore that failure.=20
Kristof=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AB060D84-8115-48B8-82F8-2C4E820BEB53>