HardenedBSD May 2021 Status Report

[Shawn Webb]

Hey all,

HardenedBSD saw a lot of work in May 2021. Here are the most notable
changes:

1. We hardened the kenv(2) syscall. Unprivileged or jailed users, even
a jailed privileged account, should not be able to inspect the
kernel environment. This is just one more hardening technique to
mitigate "kernel infoleak as feature" type of issue.

2. We fixed an issue with our ASLR implementation interfering with
FreeBSD's ASR implementation. This was due to a mismerge a while
ago when FreeBSD made changes to their ASR implementation and we
had to adjust ours in the ELF image activator.

3. We bumped bhyve's max vCPU count to 48 from 16. HardenedBSD's
infrastructure now has systems with greater than 30 cores, so being
arbitrarily limited to 16 meant we weren't utilizing the server to
its greatest potential.

4. We hardened dumping non-dumpable memory mappings. FreeBSD
implemented an interface to tell the kernel "even though this
mapping has been marked as non-dumpable, go ahead and dump it when
dumping a process' core."

5. FreeBSD's random stack gap implementation creates problems for
certain applications, like ntpd. Rather than fix the issue, FreeBSD
is explicitly disabling the stack gap for certain applications. We
reverted those changes and are carrying on like normal.

6. We performed network maintenance. The build infrastructure's
firewall is now directly connected to the internet, rather than
being behind the corporate firewall. This should drastically help
increase the robustness of the network, especially our IPv6 setup.

7. If you boot in UEFI mode, you'll notice a new bootloader screen.
Thanks to Loic, HardenedBSD's logo should be nice and pretty on the
UEFI bootloader screen.

8. Loic and I fixed some ports entries, getting errant ports to
compile again in our package builds.

9. We're researching GitLab anti-spam measures. Ben La Monica from the
HardenedBSD Foundation Board of Directors has been kindly
maintaining our GitLab instance. We may experiment with different
anti-spam measures and may experience minimal downtime as we do
that research.

10. And for the big one: We now build (nearly) all of 14-CURRENT/amd64
world with LTO, including libraries. We introduced a new build
configuration, MK_LTOLIB, to tell the build framework whether to
build static/shared libraries with LTO. As a precursor to
supporting Cross-DSO CFI, we must build as much of the base OS with
LTO as possible. This gets us closer to our goal of an OS with
Cross-DSO CFI fully enabled for the userland. The compiler
toolchain, libthr, and the various bootloaders are NOT compiled
with LTO. A set of one or more follow-up commits will enable LTO
for arm64 as well. We're doing our first package build with amd64
as we speak. It will still be a while before we support Cross-DSO
CFI, but this is a great step in the right direction.

I'm excited for the progress we're making. I'm grateful to serve the
community and I'm more grateful for the community's support.

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc