BSDCan 2025 Trip Report – Mark Johnston | FreeBSD Foundation
July 11, 2025
The FreeBSD Foundation kindly sponsored my trip to Ottawa for the BSDCan 2025 conference and FreeBSD developer summit. We had the usual two-day developer summit on June 11th and 12th, followed by the conference proper on the 13th and 14th. Per my usual routine, I took the train from Toronto to Ottawa to attend BSDcan, this time with the wrinkle of bringing my ARM Morello desktop along for use in Brooks Davis’ talk on CHERI and upstreaming support for it to FreeBSD. Ed Maste kindly picked it up and drove it for me, which made my trip to Ottawa much easier; on the way back I had to lug it along on the train in an oversized luggage case. I had never tried to transport a desktop computer that way before and I was pretty relieved that it still booted up fine when I got it back home!
The first day of the developer summit consisted mostly of talks, with generous breaks in between to give folks a chance to chat and catch up, or hack on some side project. During conferences I usually have some small project or two that I work on during breaks and in the evenings at the hacking lounge in 90U; this time it was some GDB scripts for kernel debugging, prompted by a discussion with Kristof, our esteemed pf maintainer. At the time of writing, I have not yet finished what I wanted to get done during the conference, but I really will finish it soon!
The main highlight for the first morning was the usual core@ update, where attending FreeBSD Core Team members presented updates on various topics. Of particular interest to me was a draft policy on the use of LLM-based programming tools in the FreeBSD project. To summarize quite heavily, the policy will forbid the incorporation of LLM-generated code into the project, while allowing their use in the development process in other ways, e.g., to help review patches, or to help write commit messages or other content that is not explicitly licensed. The policy comes out of a desire not to "taint" the FreeBSD project with code of dubious provenance; it is well-known that many LLM models are trained on code with licenses incompatible with the BSD license that we strive to use everywhere in the project, and thus far there is not much legal precedent to suggest that we would certainly be safe from copyright violation claims should the project decide to incorporate their output.
On the face of it, this seems like a reasonable policy: it tries to balance the need to preserve the integrity of the project’s licensing (a big draw for large *BSD users) with the general desire to use these new tools to aid development. While the use of LLMs for programming does feel rather overhyped these days, I do find them useful for certain types of work[*], and during the ensuing discussion I was a bit disappointed by what I perceived as a quite negative stance towards LLMs in general from the room. Nonetheless, core@’s approach feels even-handed and in line with other large OSS projects, and I’m interested to see how the landscape developers over the next few years. My personal view is that–licensing considerations aside–we should encourage expert developers to leverage LLMs as much as they are willing to. Longtime OSS developers are already quite used to scrutinizing and tweaking code that we did not write ourselves, and I don’t see why that same skepticism shouldn’t be enough to gate sub-par LLM outputs.
After lunch, we had a talk by Rick Miller from Verisign on the use of FreeBSD as part of a defense-in-depth strategy for core Internet DNS infrastructure. He presented on the general use of OS diversity as a way to improve security, and on why FreeBSD in particular is a good candidate for one of the operating systems to use as part of that strategy. As part of such a strategy, Verisign uses both Linux and FreeBSD in similar roles within their infrastructure, and even uses different application frameworks on each OS to further reduce their reliance on a single technology stack. In particular, while Verisign’s applications use DPDK on Linux, they can also use FreeBSD’s Netmap framework to get similar low-level access to network hardware. Rick also described various kernel security vulnerabilities that were present in one of Linux and FreeBSD but not the other, though I would expect that a large majority of CVE-worthy kernel bugs are highly OS-specific, given that many of them a memory safety bugs. I found it impressive that Verisign commits so fully to such a strategy and hope to see more examples of this in the future.
Following Rick’s talk, I and other members of the FreeBSD srcmgr team gave a presentation, similar to the morning’s core@ update, where we talked about what the srcmgr team has been up to and the problems we are working on solving. Of particular note was a call for lurkers to join the team and participate in calls without being official members of srcmgr. The aim there is to give...