Over the past few months, the core HardenedBSD team has been investigating kernel panic issues that only happen under high load. We initially suspected our ASLR code, but we kept having issues after making adjustments. We beat our infrastructure into submission. Our Jenkins build server typically sees very high load for up to ten hours sustained every day. Our package building server sees a sustained extremely high load for multiple days. Having the server crash in the middle of building 25,000 packages is quite daunting. In our investigations, we were able to find potential trouble spots with our ASLR implementation. We've since fixed those issues and have incorporated the fixes into our latest patch that hit FreeBSD's review system last week. No matter how robust we got our ASLR implementation, something else seemed to be incorrect. We had switched our randomness provider from using arc4 to chacha20. Why would that cause an issue? It wasn't chacha20 itself that caused issues, but it was a single commit required for a proper chacha20 implementation.

We have removed ChaCha20 support from HardenedBSD due to a flaw in the Virtual Memory (VM) system it introduced. In order to properly support ChaCha20, a new flag to mmap(2) was introduced. This patch was originally reviewed by the FreeBSD development team and ultimately rejected by FreeBSD. It was rejected because it's buggy and can cause issues on a system under high load. This code was introduced into HardenedBSD regardless in order to support ChaCha20. Because of the seriousness of this bug, we have fully reverted this commit and all chacha20 related work. We have also bumped HardenedBSD's version to 16. Reverting this commit has completely fixed the kernel panics. Please update ASAP.