Deep Integration of Filesystem Extended Attribute Support

I've been working on integrating filesystem extended attribute support in tmpfs, libarchive, and pkg(8).

Other operating systems tag ELF objects with various flags. We in HardenedBSD prefer not to use such a heavy-handed approach. Making use of filesystem extended attributes enables out-of-band (OOB) management of security flags. HardenedBSD makes use of extended attributes to toggle exploit mitigations on a per-binary basis. Using an OOB method provides flexibility along with an easy avenue for future growth.

I've made changes to libarchive in the base OS and have submitted a patch upstream. The patch takes a best-effort approach to restoring system-level extended attributes. Setting system-level extended attributes is a privileged operation. If an archive entry contains a systeam-level extended attribute and the extraction process is not privileged, setting the extended attribute will fail. The failure will be ignored and the extraction process will continue as normal. (The same holds true today without the patch.)

Extended attribute support in tmpfs is a bare minimum, with the ability to add and list, but not remove extended attributes. Anyone desiring to provide complete extended attribute support is welcome to provide a patch.

Finally, HardenedBSD forked FreeBSD's package manager, aptly named pkg. The package manager must be aware of filesystem extended attributes. pkg can now include any filesystem extended attribute and is not limited to HardenedBSD's use. I will make some attempt at upstreaming the changes to pkg after the changes to libarchive have been upstreamed.

The future is bright for filesystem extended attributes. One could imagine a future in which pkg stores the hash of files as extended attributes, and the kernel checks the hash against the stored attribute. The sky is the limit.

I am now integrating exploit mitigation toggling into the ports tree such that HardenedBSD ships packages with exploit mitigations toggled for those misbehaving applications (like firefox, java, nodejs, etc.)

HardenedBSD June 2020 Status Report

Now that HardenedBSD's infrastructure has found its new home, it's time to ramp up development again. We're working out kinks with regards to bandwidth and hope to increase bandwidth to our infrastructure on the inside of two months.

I've started working on adding filesystem extended attributes support to tmpfs. Once support is added, we should be able to integrate with ports/packages such that our users will no longer need to worry about toggling exploit mitigations--they'll already come pre-toggled for misbehaving applications.

I suspect this work will take a few months to complete. I've never done filesystem development, so I'm treading new waters. Once filesystem extended attribute support is added, I plan to integrate exploit mitigation toggling in the ports tree.

When all is said and done, I'm thinking around six months time frame. Granted, I have health issues, so there's no guarantees. I'll keep everyone updated.

My next goal will be integration of SafeStack into the RTLD. This is needed in order to apply SafeStack to both shared libraries and applications. This integration work relates directly with Cross-DSO CFI support, since Cross-DSO CFI requires the same/similar types of integrations.

I'm interviewing a few people to add to the HardenedBSD Board of Directors. We've added Jordan Boland to the team. He will help maintain the infrastructure. I plan to get with him once the bandwidth issues have been resolved.

I've included an intro to Jordan below. We will have more exciting news to share soon with regards to the Board of Directors.

I'm very excited to be getting more involved with HardenedBSD and to have an opportunity to serve on the Board.

I'm a lifelong tinkerer and open-source enthusiast. I was introduced to Linux in middle school and was fascinated with it until I was introduced to FreeBSD while in college. I ran FreeBSD on my personal machines for almost a decade until I was introduced to HardenedBSD, which quickly took over as my OS of choice.

My degree includes a specialization in network administration, and although I love that field I've worked in too many small IT shops to avoid becoming a generalist, and these days I do nothing related to it in my professional life. I've worked in higher education,
healthcare, telecommunications, and (to the complete surprise of my 17-year-old self) have somehow arrived at Microsoft, where I am a support engineer in the research division.

I'm not a programmer, I'm a person who occasionally has a problem that requires writing some code. On that journey I've dabbled in C, C++, C#, Java, Python, Perl, Powershell, and BASH/Bourne Shell (extensively). I really admire those that can write kernel code
and have such a deep understanding of the hardware and what is happening "under the hood", and I'd love to have that kind of proficiency someday. In the meantime, my best contribution to this project will likely be infrastructure-related. Deployment of Kerberos
and LDAP comes to mind, and perhaps digging around inside Gitea to understand why it gives 5xx errors to us. Let me know if you have any questions I didn't cover here. I'm excited to get to work with all of you!


HardenedBSD April 2020 Status Report

Hey HardenedBSD Community,

It has been a while since I've written a status report, and now is definitely time to do so. Over the past few months, I've put my focus on infrastructure stability and merge conflict resolution. The work on exploit mitigations is still somewhat on pause, though I've made slight progress on Cross-DSO CFI.

Our build infrastructure has been hosted at my current employer for a few years now. I'm so grateful for G2, Inc (now Huntington Ingalls Industries) for their support and help in ensuring the continued success of the project.

After over five years of service at my current employer, I've tendered my letter of resignation. The people I've met, the projects I've worked on, and the culture and virtues instilled in me made me fall in love with G2.

I've decided to take a new employment opportunity. BlackhawkNest will host the HardenedBSD build infrastructure with room to grow. I've architected the infrastructure such that the migration should be mostly plug-n-play, only needing to change a few IP addresses.

I plan to shut down the infrastructure in preparation for the migration on 02 May 2020, which is one week in advance of my start date. Builds will resume once the infrastructure has been deployed at the new facility. Note that published builds and package repos will still be accessible. Only the build infrastructure, which is separate from the infrastructure serving the builds and package repos, will be down. I do not currently have a date for when the infrastructure will be back online, but I suspect around two to three weeks from 02 May 2020.

I'm excited for this new opportunity, and especially for BlackhawkNest for agreeing to host the build infrastructure. I'm positive that the relationship between HardenedBSD and BlackhawkNest will be symbiotic.

Thank you so much for your help for and support of the project.


HardenedBSD Tor Onion Service v3 Nodes

I've been working today on deploying Tor Onion Service v3 nodes across our build infrastructure. I'm happy to announce that the public portion of this is now completed. Below you will find various onion service hostnames and their match to our infrastructure. lkiw4tmbudbr43hbyhm636sarn73vuow77czzohdbqdpjuq3vdzvenyd.onion qspcqclhifj3tcpojsbwoxgwanlo2wakti2ia4wozxjcldkxmw2yj3yd.onion eqvnohly4tjrkpwatdhgptftabpesofirnhz5kq7jzn4zd6ernpvnpqd.onion rfqabq2w65nhdkukeqwf27r7h5xfh53h3uns6n74feeyl7s5fbjxczqd.onion dacxzjk3kq5mmepbdd3ai2ifynlzxsnpl2cnkfhridqfywihrfftapid.onion

A GPG-signed version of this post is here:


The Idealistic Future of HardenedBSD

In the last status report, we stood up our own git server. Since then, we've migrated our entire infrastructure to point to our self-hosted git as the source-of-truth repo.

Over the past month, we purchased and deployed the new 13-CURRENT/amd64 package building server. We published our first 13-CURRENT/amd64 production package build using that server. We then rebuilt the old package building server to act as the 12-STABLE/amd64 package building server. This post signifies a very important milestone: we have now fully recovered from last year's death of our infrastructure. Our 12-STABLE/amd64 repo, previously out-of-date by many months, is now fully up-to-date!

We now have four build servers in total:

  1. nightly build server for 13-CURRENT/amd64 and 13-CURRENT/arm64.
  2. nightly build server for 12-STABLE/amd64.
  3. Package building server for 13-CURRENT/amd64.
  4. Package building server for 12-STABLE/amd64.

From here, we have two major improvements to make:

  1. Deploy Kerberos + LDAP across our infrastructure. Not only do we have those four servers, but we have others along with a number of jails. Unifying authentication would drastically simplify management.
  2. Set up various Tor Onion Service v3 endpoints for the various parts of our infrastructure. Distribute those Onion Service hostnames to the various stake holders (there will be a notion of public endpoints versus private).

HardenedBSD is in a very unique position to provide innovative solutions to at-risk and underprivileged populations. As such, we are making human rights endeavors a defining area of focus. Our infrastructure will integrate various privacy and anonymity enhancing technologies and techniques to protect lives. Our operating system's security posture will increase, especially with our focus on exploit mitigations.

Navigating the intersection between human rights and information security directly impacts lives. HardenedBSD's 2020 mission and focus is to deliver an entire hardened ecosystem that is unfriendly towards those who would oppress or censor their people. This includes a subtle shift in priorities to match this new mission and focus. While we implement exploit mitigations and further harden the ecosystem, we will seek out opportunities to contribute a tangible and unique impact on human rights issues. Providing Tor Onion Services for our core infrastructure is the first step in likely many to come towards securely helping those in need.

We are grateful for the opportunity to serve. Let us welcome 2020 with a rebuilt infrastructure and a renewed purpose!


Happy Holidays From HardenedBSD

We at HardenedBSD would like to wish the community a happy end to 2019 and a joyful beginning to 2020.

Just today, we finished putting all the pieces in places to migrate away from GitHub. HardenedBSD's build infrastructure is now fully self-hosted. We plan to make the repos on GitHub read-only by the end of January.

We will still maintain a presence on GitHub. The repos will still live on at GitHub. However, they will be a read-only mirror of our self-hosted source-of-truth repository at

Going forward, please file bug reports and pull requests at our Gitea server:

We will likely make a more appealing subdomain (perhaps later. We'll keep everyone updated if/when we do.

We will update our site accordingly soon. Happy holidays and we hope the community enjoys this little end-of-year gift. :-)

December 2019 Infrastructure Status

I thought I'd take a moment to update the community on where we stand on the infrastructure.

Our infrastructure received its first community contribution over the last week with this completed and deployed pull request:

Earlier today, I deployed LetsEncrypt on, our primary mirror.

The last piece of the puzzle is to set up rsync once again such that our mirrors can re-enable syncing with us. I'll probably tackle this in January of 2020, taking a small break from this little bit, especially during the holidays.

If you love infrastructure work and want to contribute, take a look at these open issues:

As always, if you have an itch to scratch, don't wait for me to feel the same itch. Submit a patch to proactively help me scratch your itch. :)

My next major focus will be on package builds.

HardenedBSD Status Report

We at HardenedBSD have a lot of news to share. On 05 Nov 2019, Oliver Pinter resigned amicably from the project. All of us at HardenedBSD owe Oliver our gratitude and appreciation. This humble project, named by Oliver, was born out of his thesis work and the collaboration with Shawn Webb. Oliver created the HardenedBSD repo on GitHub in April 2013. The HardenedBSD Foundation was formed five years later to carry on this great work.

As I rebuild the HardenedBSD build infrastructure, I will be performing the following user-facing changes:

1. The hardenedBSD-STABLE.git repo will be archived off. HardenedBSD will still utilize the hardenedBSD-Playground.git repo for collaboration with third parties and extremely experimental code.
2. We are slowly transitioning to being fully self-hosted. It is my goal to complete the transition on or before 31 Dec 2019. This means we will stop using GitHub altogether.
3. Downgrading 11-STABLE to community support. Given all that's on my plate, I can only maintain 13-CURRENT and 12-STABLE right now. Therefore, if the community wants 11-STABLE support, the community will need to provide it.
4. git commits performed by our infrastructure will be signed by our dev key. Think: our auto-sync scripts that run every six hours.

Now for random bits of other news:

I am currently working on getting the sync scripts running on the new infrastructure. I'm not too far off, but it will likely take around another week to re-enable the auto-sync.

Our amd64 package builder is experiencing stability issues. Due to some upstream network changes, some packages are failing to sync. Our package repos for 13-CURRENT and 12-STABLE are woefully out-of-date. I'm actively working on this as time permits. I have no ETA for updated repos.

Ben La Monica from The HardenedBSD Foundation is looking into LDAP/Kerberos integration for our infrastructure. We're looking to unify everything in order to enable finer-grained control of our infrastructure along with easier centralized management.

The new build scripts are coming along very nicely. One last change I need to make is to skip the build if no commit happened between the last build and the freshly started one. With commit, the build scripts now track the revision of the source tree. This can be used to check whether there have been any updates since the last successful build.

By the end of November, I hope to turn the build scripts into a port/package. It is my goal to be able to `pkg install` our entire infrastructure.

Given the complete rebuild of our infrastructure, we will no longer use the domain Our primary mirror is now I will update our website to reflect the changes.

To our mirror operators: due to the complete rebuild of our infrastructure, I have not yet re-enabled rsync on our primary mirror. I will be taking a different approach to authentication than before. I will provide example steps to convert your existing configuration to the new one.

I'm excruciatingly behind with the administrative side of HardenedBSD. If you have donated and I have not reached out to you, please forgive my tardiness. Know that you're not forgotten and I will get to you soon. HardenedBSD, and especially me, appreciate every contribution, no matter the form it comes in (code, money, advocacy, etc.)

Lastly, I'd like to thank everyone for their patience. I know this downtime has been extensive. I'm grateful to have the opportunity to serve the community in my spare time. Thank you for providing me the opportunity to serve you.

Stable release: HardenedBSD-stable 12-STABLE v1200059.3

HardenedBSD-12-STABLE-v1200059.3 -


  • MFC r350645: Correct ICMPv6/MLDv2 out-of-bounds memory access (6d7f541fdbb75dd9cc790d444ff37e07c5fdeb3e) [CVE-2019-5608 FreeBSD-SA-19:19.mldv2]
  • MFC r350635: bsnmp: add asn1 message length validation (be804d75b90865776e2d1174d40b6286a0679b950 [CVE-2019-5610 FreeBSD-SA-19:20.bsnmp]
  • MFC 350618: Validate guest-supplied length of headers for TSO transmit requests. (34ae5e48301f4335eab70b8f038cc06466f8c5d5) [CVE-2019-5609 FreeBSD-SA-19:21.bhyve]
  • MFC of 349589, 350070, 350071, 350096, and 350187: Make filesystem-full messages limited per filesystem rather than systemwide; Add "untrusted" option to mount command (7b0bf49d917630384de9b314ec18d4cd34aa8ec3)
  • MFC r350362 r367068: stack protector fixes for LLVM generated codes (ad1889b30609a8069c5c53365124ad27a6ddf907) [FreeBSD-SA-Candidate]
  • HBSD: set LC_COLLATE to C by default (1ec32fd40173ccc1ed7a3d32fef6839d382a76f4)
  • MFC r350310: Fix the turnstile_lock() KPI. (5a909d99e63dfd80e01cf83d49a5f1542492ba3f) [FreeBSD-EN-19:14.epoch FreeBSD-SA-Candidate]

Installer images:


SHA512 (HardenedBSD-12-STABLE-v1200059.3-amd64-bootonly.iso) = 5557676ae6108964f2da47d28803da1912fd70cfa0a9d388e066f78a0e9bad58f7c5a2abad247116f11c7f399f79de2f74bc60c89823c14d6a9ddc8a3597d338
SHA512 (HardenedBSD-12-STABLE-v1200059.3-amd64-disc1.iso) = d49899b7f8b9922da3212c937e1b9ddd29c127002b6c257209694d24b0bc58758c8c785b906bdfe45c3fb8071f3d3bd127ace6d06a4eed3ddc15e3796eb669af
SHA512 (HardenedBSD-12-STABLE-v1200059.3-amd64-memstick.img) = abb3d156c423a55c23070b01a64f705eed33dc833fe56090c00cb6de69d63be2d880f3a4350ae860eaeb5e0b25eb02cddadb154c6d3b31d489f4ab28e8322da0
SHA512 (HardenedBSD-12-STABLE-v1200059.3-amd64-mini-memstick.img) = 1d812808356714e0df7048740e7d7d1e7b6b62de0fb5e0551bbb8e950a40a8f9f241b3c14d26fc9269bb1d00febe027ad65b7f6e60cb3c171d616c965e27e2f7




Stable release: HardenedBSD-stable 12-STABLE v1200059.2

HardenedBSD-12-STABLE-v1200059.2 -


  • MFC r349800,r349801: Fix misc fs fuzzing issues. (abeb80bc5ee82a9a96da492c241fcbe91ad3e22b) [FreeBSD-SA-Candidate]
  • MFC r349802 (from fsu@): Add additional check for 'blocks per group' and 'fragments per group' superblock fields. (fcbcaebd25f0e43b12eb6b7b8302730153258350) [FreeBSD-SA-Candidate]
  • MFC r347695, r347696, r347697, r347957, r349326: Lockless delayed invalidation for amd64 pmap. (388f0c181108947d84d1233cc47b24024bd410e7)
  • MFC r349880: Let linuxulator mprotect mask unsupported bits before calling kern_mprotect. (bc326df65733684bc27deb22858a39981dd6b854)
  • MFC r350260: mqueuefs: fix struct file leak (bcc86242833757585d3c8b9663d8e9c55f8ed3ff) [FreeBSD-SA-19:15.mqueuefs CVE-2019-5603]
  • MFC r350244: bhyve: correct out-of-bounds read in XHCI device emulation (04ce7e77c7a5db5aed779d54632b9b19ed0ba9b0) [FreeBSD-SA-19:16.bhyve CVE-2019-5604]
  • MFC r350156: Fix leak of memory and file refs with sendmsg(2) over unix domain sockets. (19e53c56013af9f42f2e6177da6c6451c44156a4) [FreeBSD-SA-19:17.fd CVE-2019-5607]
  • nand: create device with 0640 permission (88f580f1ce2c81ab9c16df41fc9edf987cf5e792)
  • MFC r349890: telnet: fix a couple of snprintf() buffer overflows (7e735c9feedada921a291c023836b26b6547d032) [FreeBSD-SA-19:12.telnet CVE-2019-0053]
  • MFC r349733: Defer funsetown() calls for a TTY to tty_rel_free(). (4c06d4c0cc403122e743fc35e2f5fdefedb562b1) [FreeBSD-SA-19:13.pts CVE-2019-5606]
  • MFC r349834 Ignore kern.vt.splash_cpu without graphics (b9fd7203ae04df3457cd5c4aca370de6b4ba3646)
  • MFC r349581 netmap: fix two panics with emulated adapter (2672ab35fd1ea58da0a7dcad23925d977425ac1e)
  • MFC r349913: Ensure that mds_handler always points to a valid method. (c411b3266a9f97903667e7ab70fcb1a4a26f977a) [FreeBSD-EN-19:13.mds]
  • MFC r349876: Apply a workaround to be able to build clang 8.0.0 headers with clang 3.4.1, which is still in the stable/10 branch. (4453d146f0d636f8108822c3ef898c73adfdea46)
  • MFC 347238: vmm(4): Pass through RDSEED feature bit to guests (e64222ca6e6aac4bbba4e56ccfb6b136c71ec5d6)
  • MFC 339911,339936,343075,343166,348592: Various AMD CPU-specific fixes. (2c0a81ad596517f49c5069ce32d1ec6754dc0e4a)
  • MFC r349753 netmap: Remove pointer leakage in netmap_mem2.c (b158d710d859111d1370c945ac79f250750cffeb)
  • MFC r349527,349538: Sync libarchive with vendor. (2767b0a23c9249e482b7c9681cac0cce5d832bf0) [FreeBSD-SA-Candidate]
  • cxgbe updates
  • libbe updates
  • bhyve updates
  • LLVM and Clang updates

Installer images:


SHA512 (HardenedBSD-12-STABLE-v1200059.2-amd64-bootonly.iso) = 825d5f5ac4aae2e7146984d4f267dbb235b72ec4d87037227a44474172d1665976c8cd21a58c2fd5b661a799aee861f3c7e99e25c5a13851fbff76ff9925e1ec
SHA512 (HardenedBSD-12-STABLE-v1200059.2-amd64-disc1.iso) = 517554a50ae942a5689b063188fd2b15fcadd3cf6cd890953072d1e949936a5134fcaee57fbcdac3a2b7f095f90957e9bc62e6962f1e5087218231758c54000f
SHA512 (HardenedBSD-12-STABLE-v1200059.2-amd64-memstick.img) = 6dc3d2b2ffb7d74798b24c5d56cdeea0bad48630a26c5c69ed94f95d9a0e622486d81a44d6fd6823e4944c9b957da2c122f4c741229ded2120200e765213adf9
SHA512 (HardenedBSD-12-STABLE-v1200059.2-amd64-mini-memstick.img) = 1e7c2e6c64d0fcb6687e15fb8f6efe313891a69532f806f8bb1dee333a1b07b8de0d217532c2be41d9459c7b7148efaec469ccf3993385396721c7b4756ee947





Subscribe to HardenedBSD RSS