Hi,
czw., 18 lis 2021 o 19:07 Li-Wen Hsu <lw...@freebsd.org> napisał(a):
>
> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas <m...@semihalf.com> 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 difficult
> > (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 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=0
> > kern.elf64.aslr.pie_enable=0
> >
> > 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
