NetBSD Blog

NetBSD 11.0 RC3 available!

martin — Mon, 6 Apr 2026 14:13:39 +0000

The NetBSD project is pleased to announce the third (and probably final) release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

Unfortunately the first release candidate had a few defects that we had to fix, including speed enhancements for the ftp(1) client when downloading large files, an updated tmux(1), reliability fixes for blocklistd(8) and fixes for the Mesa library. See the changes document for details.

Please note that various ISO images have been split into small ones for CD/R media and full featured DVD ones. If you are not restricted by the size limits of a CD/R medium, make sure to pick the image with "-dvd.iso" in the name.

If you want to test 11.0 RC3 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-11 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 11.0 RC2 available!

martin — Fri, 6 Mar 2026 20:58:23 +0000

The NetBSD project is pleased to announce the second release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

If you want to test 11.0 RC2 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-11 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

The NetBSD Foundation will participate in Google Summer of Code 2026!

Leonardo Taccari — Mon, 23 Feb 2026 11:32:46 +0000

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2026!

Would you like to learn how to contribute to open source? Google Summer of Code is a great chance to contribute to NetBSD and/or pkgsrc!

You can find a list of possible projects at Google Summer of Code project page. Please do not limit yourself to the project list... If have any cool idea/project about NetBSD and/or pkgsrc please also propose your one!

Please reach us via #netbsd-code IRC channel on Libera.Chat and/or via mailing lists.

If you are more interested about Google Summer of Code, please also check the homepage at g.co/gsoc.

Looking forward to a great Summer!

NetBSD 11.0 RC1 available!

martin — Sun, 8 Feb 2026 17:30:05 +0000

The NetBSD project is pleased to announce the first release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

If you want to test 11.0 RC1 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-11 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

Google Summer of Code 2025 Reports: Using bubblewrap to add sandboxing to NetBSD

Leonardo Taccari — Sat, 8 Nov 2025 15:00:19 +0000

This report was written by Vasyl Lanko as part of Google Summer of Code 2025.

Introduction

As of the time of writing, there is no real sandboxing technique available to NetBSD. There is chroot, which can be considered a weak sandbox because it modifies the root directory of the process, effectively restricting the process' view of the file system, but it doesn't isolate anything else, so all networking, IPC, and mounts inside this restricted file system are the same as of the system, and are accessible.

There has already been some research on implementing kernel-level isolation in NetBSD with tools like gaols, mult and netbsd-sandbox, but they haven't been merged to NetBSD. Other operating systems have their own ways to isolate programs, FreeBSD has jails, and Linux has namespaces.

Project Goals

The goal of this project is to bring a new way of sandboxing to NetBSD. More specifically, we want to implement a mechanism like Linux namespaces. These namespaces allow the isolation of parts of the system from a namespace, or, as the user sees it, from an application.

NetBSD has compat_linux to run Linux binaries on NetBSD systems, and the implementation of namespaces can also be utilized to emulate namespace-related functionality of Linux binaries.

A simple example to visualize our intended result is to consider an application running under an isolated UTS namespace that modifies the hostname. From the system's view, the hostname remains the same old hostname, but from the application's view it sees the modified hostname.

Project Implementation

Linux has 8 namespace types, in this project we will focus on only 2 of them:

UTS namespace, it is the simplest so we can focus on building the general namespace infrastructure with little namespace-specific details
mount namespace, it is a prerequisite to most other namespace types because UNIX follows the philosophy of "everything is a file", so we need a separate mount namespace to have different configuration files on the same location as the system.

Linux creates namespaces via the unshare or clone system calls, and it will also be our way of calling the namespace creation logic.

We setup the base for implementing Linux namespaces in the NetBSD kernel using kauth, the subsystem managing all authorization requests inside the kernel. It associates credentials with objects, and because the namespace lifecycle management is related to the credential lifecycle it handles all the credential inheritance and reference counting for us. (Thanks kauth devs!)

We separate the implementation of each namespace in a different secmodel, resulting in a similar framework to Linux which allows the isolation of a single namespace type. Our implementation also allows users to pick whether they want to have namespace support, and of what kind, via compilation flags, just like in Linux.

UTS namespace

UTS stands for UNIX Timesharing System, because it allows multiple users to share a single computer system. Isolating the utsname can be useful to give users the illusion that they have control over the system's hostname, and also, for example, to give different hostnames to virtual servers.

The UTS namespace stores the namespace's hostname, domain name, and their lengths. To isolate the utsname we need to first create a copy of the current UTS information, plus we need a variable containing the number of credentials referencing this namespace, or, in simpler terms, the reference count of this namespace.

This namespace specific information needs to be saved somewhere, and for that we use the credential's private_data field, so we can use a UTS_key to save and retrieve UTS related information from the secmodel. The key specifies the type of information we want to retrieve from the private_data, hence using a UTS_key for the UTS namespace. The key for each namespace is a fixed value (we don't create a new key for every credential), but the retrieved value for that key from different credentials may be different.

We had to modify kernel code that was directly accessing the hostname and domainname variables, to instead call get_uts(), which retrieves the UTS struct for the namespace of the calling process. We didn't modify occurrences in kernel drivers because drivers are not part of any namespace, so they should still access the system's resources directly.

MNT namespace

The MNT namespace isolates mounts across namespaces. It is used to have different versions of mounted filesystems across namespaces, meaning a user inside a mount namespace can mount and unmount whatever they want without affecting or even breaking the system.

The mount namespace structure in Linux is fairly complicated. To have something similar in NetBSD we need to be able to control the mounts accessed by each namespace, and for that we need to control what is each namespace's mountlist, this is also enough for unmounting file systems, because in practice we can just hide them.

For the mount_namespace, mountlist structure and the number of credentials using the mount namespace are stored in the credential's private data with the MNT_key. Similarly to the UTS namespace, we had to modify kernel code to not directly access the mountlist, but instead go through a wrapper called get_mountlist() which returns the correct mountlist for the namespace the calling process resides in.

Implementation for the mount namespace is immensely more complex than for the UTS namespace, it involves having a good understanding of both Linux and NetBSD behaviour, and I would frequently find myself wondering how to implement something after reading the Linux man pages, which would lead to me looking for it in the Linux source code, understanding it, then going back to NetBSD source code, trying to implement it, and seeing it's too different to implement in the same way.

Project Status

You can find all code written during this project in GitHub at maksymlanko/netbsd-src gsoc-bubblewrap branch. Because I intend to continue this work outside of GSoC, I want to reinforce that this was the last commit still during GSoC on gsoc-bubblewrap branch and this was the last one for the mnt_ns still WIP branch.

The link includes implementation of general namespace code via secmodels, implementation of the UTS namespace and related ATF-tests, and the work-in-progress implementation of mount namespaces.

The mount namespace functionality is not finished as it would require much more work than the time available for this project. To complete it, it would be required invasive and non-trivial changes to the original source code, and, of course, more time.

Future Work

As previously mentioned, Linux has 8 namespace types, it is important to see which of the missing namespaces are considered useful and feasible to implement.

I believe that after mount namespaces it would be interesting to implement PID namespaces as this in combination with mount namespaces would permit process isolation from this sandbox. Afterwards, implementing user namespaces would allow users to get capabilities similar to root in the namespace, giving them sudo permissions while still restricting system-wide actions like shutting down the machine.

A lower hanging fruit is to implement the namespace management functionality, which in Linux is lsns to list existing namespaces, and setns to move the current process to an already existing namespace.

Challenges

Semantics. Did you know the unmount system call with MNT_FORCE flag in Linux (usually) returns EBUSY, and in NetBSD it forces the unmounting? One of them makes it easier to implement mount namespaces.
The behaviour of namespaces is not fully specified in the man pages. If something is not clear from the man pages you need to read the source code.
Unexpected need to learn a lot of VFS concepts and their differences in NetBSD and Linux.
There was a much bigger research component than I anticipated.

In the end, Linux and NetBSD are different operating systems, implemented in different ways. Linux is complex and it is not trivial to port namespaces to NetBSD.

Notes

The project is called "Using bubblewrap to add sandboxing to NetBSD" and was initially projected to emulate the unshare system call into compat_linux, but, seeing that having namespaces could be useful for NetBSD, and that it would be easy to add to compat_linux afterwards, we decided to instead implement namespaces directly in the NetBSD kernel. Implementing other system calls necessary to make the bwrap linux binary work correctly also wouldn't be as satisfying as implementing namespaces directly into NetBSD, so this was why the project was initially called "Using bubblewrap to add sandboxing to NetBSD" but nowadays it would be more accurate to call it "Sandboxing in NetBSD with Linux-like namespaces".

Thanks

I am very grateful to Google for Google Summer of Code, because without it I wouldn't have learned so much this summer, wouldn't have met with smart and interesting people, and for sure wouldn't have tried to contribute to a project like NetBSD, even if I always wanted to write operating systems code... But, the biggest thing I will take with me from this project is the confidence to be able to contribute to NetBSD and other open source projects.

I would also like to thank the members of the NetBSD organization for helping me throughout this project, and more specifically:

Taylor R. Campbell, Harold Gutch and Nia Alarie from IRC, for helping me fix a nasty LD_LIBRARY_PATH bug I had on my system which wouldn't let me finish compiling NetBSD, and general GSoC recomendations.
Emmanuel Dreyfus from tech-kern, with whom I discussed ideas for projects and proposal suggestions, and in the end inspired the namespaces project.
Christoph Badura and Leonardo Taccari who volunteered to be my mentors. They took time to research and answer my questions, anticipated possible problems in my approaches, and always pointed me in the right direction, daily, during all of GSoC's period. This project is from the 3 of us.

Google Summer of Code 2025 Mentor Summit in Munich, Germany: travel notes

Leonardo Taccari — Fri, 31 Oct 2025 11:41:23 +0000

I just came back home from Google Summer of Code 2025 Mentor Summit. We were 185 mentors from 133 organizations and it was amazing!

Google Summer of Code (GSoC) is a program organized by Google with the focus to bring new developers to open source projects.

The NetBSD Foundation has been participating in GSoC since 2005.

After nearly a decade being part of GSoC for The NetBSD Foundation, first as student and then as mentor and org admin, I finally attended my first GSoC Mentor Summit! That was a fantastic, very intense and fun experience! I met with a lot of new folks and learned about a lot of other cool open source projects.

Let's share my travel notes!

Wednesday 22, October 2025: arriving in Munich

Going to Munich is relatively doable by train from my hometown. I departed from Urbisaglia-Sforzacosta at 6:59 in the morning. I had around 25 minutes to wait for the change from Ancona to Bologna. I arrived in Bologna at around 11:30 where I met Andrea, my friend and favorite music pusher since childhood. We had lunch together, eating tasty miso veggie ramen, drank some hot sake and then we had coffee. He then accompanied me back to the station where I had the train to Munich Central Station at 13:50.

The scenery from the train was really nice. Near Trento and Bolzano/Bozen, full of vineyards and apple orchards with mountains in the background. It was cloudy for most of the travel but starting from Bressanone/Brixen I began to see «beautiful blue skies and golden sunshine». After Bressanone the scenery was more uncontaminated with light green grazing lands. Unfortunately when reaching Brennero/Brenner (last Italian city before Austria) it started to get dark and I had not enjoyed the rest of the scenery in Austria and Germany. I arrived in Munich at 20:50 and checked in at my hotel which was around 1km from the station.

For this journey I was not alone! Also Christoph Badura (<bad@>) was a delegate for Google Summer of Code and we had been in touch to get dinner and beers together. Christoph had some train delays but at 21:40 we were able to meet and went for a walk a bit to the south-east to find some places to eat and drink. I had done my homework for the beer places (obviously!) but the place in my TODO list to visit on Wednesday did not have a lot of food so we decided to first go to a restaurant and we found Ha Veggie - Vietnamese Cuisine. I had some Edamame and Bò xào sả ớt, a delicious dish with seitan, vegetables, lemongrass and chili pepper.

We then stopped at Frisches Bier, a bit too late, but the publican was kind enough and she permitted us a last round. I had a pint of a refreshing Hoppebräu Wuide Hehna Session IPA.

We then took a walk back to our hotels, talked a bit and went to sleep.

Thursday 23, October 2025: 1st day of Mentor Summit

Thursday was the first day of the Mentor Summit. The summit was in Munich Marriott Hotel, more in the north of the city, around 5km from the central station.

I checked out of my hotel and walked to the city center in Marienplatz and nearby. I also stopped in a couple of shops to grab some souvenirs for my family and friends and then took a long walk in the direction of Munich Marriott Hotel, to hopefully be there at 13:00 sharp for the start of check-in of GSoC Mentor Summit.

Rear of the Siegestor showing its inscription that can be translated to "Dedicated to victory, destroyed by war, urging peace"

I walked through Ludwigstraße and enjoyed the architecture around me, walking near LMU University and Siegestor. I then proceeded through Leopoldstraße and Ungererstraße and then arrived to the Munich Marriott Hotel.

Chris was already in the lobby and he had already checked in. We talked a bit and then I checked in as well. The room was huge and comfy! I quickly went back down to the lobby. We then checked in for Mentor Summit and I finally met Stephanie, Mary and Lucy, the GSoC Program Admins. I also took with me from home some classical and specialty Italian chocolate (Cioccolato di Modica) for the chocolate room (more about that later!) and left the bars in the chocolate room.

The time from 13:00-17:00 was reserved to actually permit mentors to arrive. At 13:00 there were still not a lot of mentors around so with Chris we decided to have lunch. We had lunch in a trattoria where we had an antipasto of grilled vegetables, penne all'arrabbiata with red wine from Montepulciano.

While eating Chris talked about the Tantris but we were already full. We had not tasted the haute cuisine but walked there to just look at the restaurant building. O:)

Tables full of chocolate and sweets from the chocolate room

When we came back to Munich Marriott Hotel, I went to the chocolate room to taste some chocolate/sweets. In GSoC Mentor Summit it is a tradition to bring great quality chocolate - or other sweets for places where chocolate is less usual - so folks can taste sweets from all over the world. That's a very nice initiative! I was curious more about non-chocolate sweets completely new to me so I had some Laddu and Kaju katli, both delicious!

I spent the rest of the afternoon down at the Champions Bar socializing with other mentors.

We had dinner at around 19:00 with good food accompanied by a couple of glasses of Primitivo.

At 20:15 we had the Opening Session. Stephanie, Mary and Robert warmly welcomed us. They shared the schedule and introduced to the unconference format of the sessions. We then had dessert and played the GSoC 2025 Mentor Summit Scavenger Hunt. The Scavenger Hunt is a game where you can meet and find 25 different folks with something that could be common (e.g. «prefers spaces (not tabs)») to something pretty rare (e.g. «has jumped out of a helicopter»). This game was nice because it was also a great conversation starter. I met a lot of mentors both of open source software that I regularly use but also learned about new interesting open source software and organizations while doing that!

We had time until Friday 12:30 and 10 lucky mentors who completed it (at the end around 60 of 185 were able to complete) got randomly selected and they got special prizes.

I stayed up until probably 1am or so, socializing a bit more in the lobby and then went back to my room to have some sleep, knowing that Friday was completely packed with Lightning talks and sessions!

Friday 24, October 2025: 2nd day of Mentor Summit

I had breakfast around 8:20 at the Green's Restaurant. I sat at a table together with other folks and after a minute I saw a known name in front of me: Lourival Pereira Vieira Neto <lneto@>! I was very happy to meet another NetBSD developer and that was a complete surprise. He was there as a mentor of the LabLua organization.

GSoC Program Admins welcomed us for the day and recapped the schedule for Friday and Saturday.

Lightning talks, round 1

The lightning talks consisted of mentors presenting their best GSoC 2025 projects. The format was fast and fun: a maximum of 3 minutes for the talk and a maximum of 4 slides! We had presentations from 18 different mentors and orgs and all of them were able to stay under 3 minutes!

That was a great occasion also to learn about open source projects, new orgs and the experiences shared were interesting too.

GSoC Feedback Session

After the 1st round of Lightning Talks I attended the GSoC Feedback Session. That was a Q&A session with program admins and org admins/mentors.

Hot topics this year were AI usage and spam applications that were not discussed as part of this session because there were two other separate sessions regarding that later.

If I only have one sentence to summarize this session... I should quote Robert sharing that Google Summer of Code is about the journey for the contributors and mentors to get involved in open source. The coding is only the means to an end.

"Hallway track", lunch and group photo

After the first session I decided to take a break and instead stay in the "hallway track" where I met new folks and socialized a bit. Another funny and at the same time a bit embarrassing for me thing of GSoC is that I often met someone and after a couple of minutes of talk I can associate the face with a name and I figured out that I'm an avid user / pkgsrc MAINTAINER of the software they contribute to! :)

At 12:30 we had lunch at Green's Restaurant and then at 13:40 we had a group photo and it was pretty tricky to put around 200 folks (program admins and mentors) on the stage of the Ballroom! :)

Let's talk about improving diversity + inclusion in FOSS!

In the afternoon I joined the session about improving diversity. In open source unfortunately there are a lot of underrepresented groups and we should fix that.

There were a lot of experiences shared from several orgs, food for thought for me! Only to name few topics: Outreachy, how to know and create safe spaces, importance of localization in software and documentation, be sure to make underrepresented folk as part of key people and also try to take the burden of other tasks off them.

GSoC and AI

Artificial Intelligence (AI), in particular Generative AI (GenAI) has been a hot topic since project proposals opened this year!

Some people consider it a speed-up for researching but at the same time it impedes learning.

In NetBSD - according to our Commit Guidelines - code generated by large language model (LLM) or similar technologies is considered tainted code because such models can be trained on copyrighted materials and such resulting code can then violate copyright.

More than 80% of GSoC contributors who filled an anonymous survey used AI, mainly for code generation, code completion, text generation, debugging and error detection.

Most mentors are usually not happy with the outcomes of AI with code often resulting in buggy/vulnerable and poor quality, violating copyright and some mentors also pointed out that as part of mentoring we should also make contributors aware of environmental/ecological impact of such use.

However, both contributors' and mentors' surveys on AI are relatively small dataset (around 90 mentors and 90 contributors).

Lightning talks, round 2

At 16:00 we had the 2nd and last round of Lightning talks. That was another great opportunity to learn more about more projects and organizations!

Asynchronous I/O by Ethan Miller

Christoph Badura (<bad@>) presenting his lightning talk

Christoph Badura (<bad@>) did a lightning talk too and he presented work done by Ethan Miller. Ethan also blogged about his work, please read Google Summer of Code 2025 Reports: Asynchronous I/O Framework if you missed it!

This code was also imported by Christos Zoulas (<christos@>), thanks Christos!, and is now part of -current and it will be in NetBSD 12.0.

GSoC spammy proposals

After the Lightning talks there was a break and then at 17:30 I joined the session about GSoC spammy proposals.

This year most organizations received many more proposals, mostly due contributors starting to massively use GenAI.

A lot of suggestions and tips were shared to make the mentor review job smooth and easy as possible.

The most important suggestion is that mentors must do a 1:1 conversation with potential contributors before accepting them. The weight of the project proposal is like 2/10 and the actual 8/10 weight is on conversations between mentors and contributor.

Dinner and social event

Around 19:00 we had dinner, desserts and socialized. Stephanie also did a final talk recapping GSoC 2025 and thanking all mentors for making that possible.

We then had drinks and it then started the karaoke session (and there were a lot of pro folks doing that, very nice!).

The karaoke session at Ballroom closed with the waiter singing Closing Time (not the one by Tom Waits that is mostly instrumental, but the one by Semisonics!, I did not know it but that's melancholic as well for me, just smells a little bit less of whisky and cigs compared to the Tom Waits one ;)).

We went downstairs to the Champions Bar, had two rounds of some good Higgins Ale Works IPA and socialized a bit more. Time passed pretty quickly and also the barman there at Champions Bar started singing Closing Time!

We went a bit outside and in the lobby talking with other mentors and then I went back to my room to get some sleep for the last day of the summit.

Saturday 25, October 2025: 3rd day of Mentor Summit

I had breakfast around 8:00, a bit earlier, given that on Saturday the first session started at 9:00.

Porting & Packaging

At 9:00 I joined a session about porting and packaging. We had both FreeBSD porters, pkgsrc maintainers and other package systems maintainers on one side. On the other side there were also a lot of upstreams.

We shared do-s and don't-s on packaging.

How to get students to engage with the community

Christoph Badura (<bad@>) proposed a session to share experiences on how to get contributors to engage with the community and a lot of mentors provided a lot of great suggestions.

One thing that most mentors agreed on and worked well was to invite contributors regular (or less regular, to avoid putting too much pressure on contributors) blog posts / status updates.

Some organizations also did that as part of their weekly / bi-weekly updates that are often video meetings. In that case they reserved a slot for the contributor so that they can share their status updates.

These are great opportunities for the contributor to get in touch with the community.

Open source tools for supply chain security

I then joined a session about open source tools for supply chain security.

We discussed about Software Bill of Materials (SBOM) and its importance in the context of regulations like EU Cyber Resilience Act (CRA).

We also discussed Common Platform Enumeration (CPE) and Package URL (PURL) schemas

We talked about vulnerability management and I shared a bit my experience in pkgsrc-security@ and how often the metadata in CVEs (like vendor, product and versions affected) is not that good. Most package systems have their own workflows and usually add extra metadata only for their vulnerability DB.

I also learned about Vulnerability Exploitability eXchange (VEX) that some package systems use.

There were also mentors from AboutCode and SW360, projects that looks very interesting and I should learn more about them!

Vintage computing

Before lunch I joined the Vintage computing session.

Everyone presented themselves and talked about the most vintage computer they had, how running old machines is both fun and productive and we also talked about old Unix-es and The Unix Heritage Society.

Lunch

I had lunch at Green's Restaurant with other mentors and then socialized a bit outside Ballroom.

Waitlisted Lightning talk and funny stories

At 14:00 we had the last sessions. I went to the waitlisted Lightning talk, that can be considered the Lightning talk, round 3! :)

Mentors from different organizations shared interesting projects.

After the lightning talks several of us shared funny stories/hacks. Like learning languages in interesting ways, taking photographs of garbage to train and realize a robot that cleans it, a sort of Tinder for food... And much more! :)

Closing session

At 15:30 we had the closing session.

Some of us stayed for another 1 or 2 hours and talked, socialized a bit more and said see you soon to each other.

Going near Munich East Station and dinner with Chris

Around 17:00 I left the Munich Marriott hotel to check in to my hotel for Saturday night near Munich East Station. It was raining for most of the morning and afternoon but luckily around 17:00 it stopped and the sky seemed fine. I decided to take a walk - a bit more than 6km - to reach the hotel. Also that time I'm happy that I took a long walk because I was able to stay for most of my walk in the Englischer Garten.

Glass of Camba Island (NEIPA) beer and list of draft beers

I checked in at my hotel and then went to Tap-House where with Christoph we planned to have dinner and a couple of beers. Tap-House had a really huge choice of craft beers with 40 drafts! We had a pinsa marinara, a flatbread similar to pizza and I had a couple of small IPAs from Camba Bavaria and Yankee & Kraut Pure HBC 630, a DNEIPA.

We decided to take a walk and went to BrewsLi for some last good night beers. BrewsLi was a very nice brew pub. We sat at a table and near us there were several board games. Chris took one of this board game Mensch ärgere Dich nicht and explained to me the rules. A lot of aleatory is involved but there is also some strategy and it was funny to play and we probably played for 40 minutes or so because most of our game pieces returned to the "out" section. I took a walk with Chris back to the nearest metro station and I came back to my hotel around 2:00.

Mensch ärgere Dich nicht board game

Sunday 26, October 2025: stop in Bolzano/Bozen

On Sunday I took a train from Munich East Station to Bolzano/Bozen because it was unfeasible to go back home by train to Marche region without a stop somewhere in Italy.

View of Bolzano from St. Oswald Promenade

I went for a walk Passeggiata di Sant'Osvaldo (St. Oswald Promenade) uphill to be able to enjoy a view of the city from the top until sunset.

I had a simple but very tasty onion soup and a Gose (really good, one of the best Gose I've drunk!) and Session IPA at Batzen Häusl.

I was not able to visit anything else in the night because I was pretty tired so I went to sleep earlier.

Monday 27, October 2025: back home

In the morning I took a walk to Walther Square and nearby. I got some souvenirs for the family and then I took the trains back home and spent most of my day on the trains.

Conclusion

Google Summer of Code 2025 Mentor Summit was an amazing experience!

I had the chance to participate in very interesting talks, sessions and discussions. I met a lot of mentors from all over the world and learned about new open source projects and organizations. All the folks were also extremely positive, easy to talk to and I had a lot of fun.

Thanks to program admins and all the mentors who made this possible! Thanks a lot also to Google for organizing it and thanks to The NetBSD Foundation that permitted me to go!

NetBSD hand-written logo on the GSoC guest book

If you are new to open source, consider applying for it! If you are a seasoned open source contributor, consider participating as a mentor! You can learn more about GSoC at Google Summer of Code (GSoC) website.

Google Summer of Code 2025 Reports: Enhancing Support for NAT64 Protocol Translation in NetBSD, part 2

Leonardo Taccari — Mon, 20 Oct 2025 14:19:28 +0000

This report was written by Dennis Onyeka as part of Google Summer of Code 2025.

This is the 2nd blog post about his work. If you have missed the first blog post please read Google Summer of Code 2025 Reports: Enhancing Support for NAT64 Protocol Translation in NetBSD.

Overview

Typical rules looks like:

map wm0 algo "nat64" 64:ff9b:2a4:: -> 192.0.2.33
map wm0 algo nat64 plen 96 64:ff9b::8c52:7903 <- 140.82.121.3

This tells NPF to translate outgoing IPv6 packets using the prefix 64:ff9b:2a4::/96, rewriting them to use the IPv4 address 192.0.2.33. When the packet returns and hits NPF, it changes source from GitHub's IPv4 to GitHub's IPv6 address and then it rewrites the header.

When an IPv6 packet from a client hits the NPF machine

The NAT64 translation routine (npf_nat64_rwrheader()) rewrites the IPv6 header to an IPv4 header.
- The source becomes the host's IPv4 address or any pool of IPv4 addresses.
- The destination becomes the IPv4 address of github.com extracted from IPv4 embedded IPv6 address defined in the rule configuration. (e.g. 140.82.121.3 from 64:ff9b::8c52:7903).
TCP/UDP/ICMP checksums are recalculated using in4_cksum() or in6_cksum().
The packet is then routed out to the IPv4 network.

When a reply packet comes back from the IPv4 server

NPF performs the reverse translation, embedding the IPv4 address inside the NAT64 prefix to form a valid IPv6 address using npf_embed_ipv4()
The IPv6 packet is then delivered back to the IPv6 client.

Project Accomplishments

Core Translation Path: Implemented IPv6 -> IPv4 header and reverse rewriting (npf_nat64_rwrheader() routines).
Address Mapping: Added functions for embedding and extracting IPv4 addresses within IPv6 prefixes.
Checksum Recalculation: Integrated checksum updates for IPv4/IPv6 and transport layers.
Rule Parsing: Extended npf.conf(5) syntax and parser to accept NAT64 configuration parameters.
Userland and Kernel Integration: Updated kernel headers, userland utilities, and rule constructors.
Testing: Verified translation with ping, curl and dig, observing packets using tcpdump and Wireshark.

Summary

This project successfully integrates NAT64 along with a separate DNS64 configuration into NPF, enabling IPv6-only clients to reach IPv4-only servers through seamless translation. Although there's a need for additional changes and implementation.

This is indeed the end of my GSoC Program, it was indeed an exciting moment working with system developers and certainly I'd be an active contributor to the NetBSD codebase.

Source code of the Google Summer of Code project can be found at the following branch.

Google Summer of Code 2025 Reports: Enhancing Support for NAT64 Protocol Translation in NetBSD

Leonardo Taccari — Mon, 15 Sep 2025 16:19:01 +0000

This report was written by Dennis Onyeka as part of Google Summer of Code 2025.

Introduction & Description

The goal of the NAT64 project is to implement IPv6-to-IPv4 translation inside NPF (NetBSD Packet Filter). NAT64 enables IPv6-only clients to communicate with IPv4-only servers by embedding/extracting IPv4 addresses in IPv6 addresses as per RFC 6052 and RFC 6145. We are using a 1:1 mapping for now, to implement NAT64 translation. Whereby an IPv6 host will use its IPv4 address to communicate with an IPv4 only server. As an example of IPv4, we will use github.com (140.82.121.3) that supports only IPv4. In order to enable NAT64 on NPF we will have a rule like this:

map wm0 algo "nat64" 64:ff9b:2a4:: -> 192.0.2.33

This means we want to use the host IPv4 address associated to wm0 interface 192.0.2.33 to access the public internet in order to communicate with GitHub's IPv4 server. During this process, IPv6 header will be rewritten to IPv4. Part of the IP structure requires source and destination address so our new IPv4 source address will be the Host IPv4 address (which is likely to change during further improvement) and the IPv4 destination address will be gotten from GitHub’s IPv4 embedded IPv6 address i.e. the IPv4 address embedded into IPv6 address (64:ff9b::8c52:7903) gotten from the DNS resolver. Note that NPF is our router so we will have to enable and configure a DNS caching resolver like unbound on the NetBSD machine. The job of the DNS64 is to synthesize AAAA responses from IPv4-only A records using the well-known prefix (64:ff9b::/96), then embed the Github’s IPv4 address (140.82.121.3) into it which will be (64:ff9b::8c52:7903). The hexadecimal values represent Github’s IPv4 address. When the packet is returning from GitHub, it uses the IPv6 interface, so the IPv4 address part will be embedded back into its required position based on the prefix length passed by the user on the configuration. Then it will be sent to the IPv6 interface of the host machine. So far, I’ve been focusing on the core translation path, making sure headers are rewritten correctly and transport checksums are updated. This also requires changes in the userland and kernel.

Current Status

Address Embedding and Extraction: Implemented functions that are responsible to extract IPv4 from IPv6 and embed IPv4 back into IPv6. Supports prefix lengths 32–96, with 96 as default.
IP Header Rewrite: Added a functionality that enables headers rewriting by stripping off the old IP header and creating a new header along with structures.
Rule Parsing: Added keyword support in npf.conf, so users can specify NAT64 prefix length.
Checksum Handling: Integrated checksum recalculation for IPv4, IPv6, and transport layers (TCP/UDP/ICMP).

More functionalities to be added (In the coming weeks)

State Integration: Hooked into NPF’s connection tracking so NAT64 works with stateful packet filtering.
Fine tune the checksum handling

Development Environment & Test Environment

Running NetBSD in a VM (on Windows host) for test implementation
Editing and building code on WSL (Windows Subsystem for Linux).

Testing

Testing traffic with ping, nc (netcat), curl, dig.
Using tcpdump/tshark/Wireshark on NetBSD to inspect packets before/after translation.

Debugging

Building kernel and userland via build.sh with kernel debug logs enabled
Tracing packet flow via ktrace
Incremental testing/unit: Test functions one by one.

Experience, Observation, Impressions

Experience: Working deep inside NetBSD’s kernel networking stack has been challenging but rewarding. It gave me hands-on experience with mbufs, packet parsing, and kernel-level checksums.

Observation

Testing NAT64 also requires real network setups, not just unit tests, since correctness depends on seeing the actual wire-format packets.
Prefix length handling is subtle, user input must be validated and handled gracefully (defaulting to 96).
The separation between userland rule parser and kernel execution path is strict, everything is serialized into structures properly.

Impressions about NetBSD

The codebase is clean and modular, but sometimes well-documented to an extent.
NetBSD’s networking stack is solid and flexible, NPF feels light and extensible.
The build system is stable.

Google Summer of Code 2025 Reports: Asynchronous I/O Framework

Leonardo Taccari — Sat, 30 Aug 2025 17:56:23 +0000

This report was written by Ethan Miller as part of Google Summer of Code 2025.

Introduction

The goal is to improve the capabilities of asynchronous IO within NetBSD. Originally the project espoused a model that pinned a single worker thread to each process. That thread would iterate over pending jobs and complete blocking IO. From this, the logical next step was to support an arbitrary number of worker threads. Each process now has a pool of workers recycled from a freelist, and jobs are grouped per-file so that we do not thrash multiple threads on the same vnode which would inevitably lock. This grouping also opens the door for future optimisations in concurrency. The guiding principle is to keep submission cheap, coalesce work sensibly, and only spawn threads when the kernel would otherwise block.

Project Details and Status

We pin what is referred to as a service pool to each process, with each service pool capable of spawning and managing service threads. When a job is enqueued it is distributed to its respective service thread. For regular files we coalesce jobs that act on the same vnode into one thread. If we fall back to the synchronous IO path within the kernel it would lock anyway, but this approach is prudent because if more advanced concurrency optimisations such as VFS bypass are implemented later this is precisely the model that would be required. At present, since that solution is not yet in place, all IO falls back to the synchronous pipeline. Even so there are performance gains when working with different files, since synchronous IO can still run on separate vnodes at the same time.

Through the traditional VFS read/write path, requests eventually reach bread/bwrite and block upon a cache miss until completion. This kills concurrency. I considered a solution that bypassed the normal vnode read/write path by translating file offsets to device LBAs with VOP_BMAP, constructing block IO at the buffer and device layer, submitting with B_ASYNC, and deferring the wait to the AIO layer with biodone bookkeeping instead of calling biowait at submission. This keeps submission short and releases higher level locks before any device wait. The assumptions are that filesystem metadata is frequently accessed therefore cached so VOP_BMAP usually does not block, that block pointers for an inode mostly remain stable for existing data, and that truncation does not rewrite past data. For the average case this would provide concurrency on the same file. In practice, however, it was exceptionally difficult to implement because the block layer lacks the necessary abstractions.

This is, however, exactly the solution espoused by FreeBSD, and they make it work well because struct bio is an IO token independent of the page and buffer cache. GEOM can split or clone a bio, queue them to devices, collect child completions, and run the parent callback. Record locks are treated as advisory so once a bio is in flight the block layer completes it even if the advisory state changes. NetBSD has no equivalent token. Struct buf is both a cache object and an IO token tied to UBC and drivers through biodone and biowait. For now the implementation of service pools and service threads lays the groundwork for asynchronous IO. Once the BIO layer reaches adequate maturity, integrating a bio-like abstraction will be straightforward and yield immediate improvements for concurrency on the same vnode. The logical next step is to design and port something comparable to FreeBSDs struct bio which would map very cleanly onto the current POSIX AIO framework.

My Development Environment

My development setup is optimised for building and testing quickly. I use scripts to cross-build the kernel and boot it under QEMU with a small FFS root. The kernel boots directly with the QEMU option -kernel without any supporting bootloader. Early on I tested against a custom init dropped onto an FFS image. Now I do the same except init simply launches a shell which allows me to run ATF tests without a full distribution. This makes it possible to compile a new kernel and run tests within seconds.

Lessons

One lesson I have taken away is that progress never happens overnight. It takes enormous effort to get even a few thousand lines of highly multi-threaded race-prone code to behave consistently under all conditions. Precision in implementation is absolutely required. My impression of NetBSD is that it is a fascinating project with an abundance of seemingly low-hanging fruit. In reality none of it is truly low-hanging or simple, but compared to Linux there remains a great deal of work to be done. It is not easy work but the problems are visible and the path forward is clearer.

I also want to note that I intend on providing long term support for this code in the case that any issues may arise.

The code written as part of this project can be found here.

NetBSD 11.0 release process underway

martin — Mon, 4 Aug 2025 09:16:17 +0000

If you have been following source-changes, you may have noticed the creation of the netbsd-11 branch! It comes with a lot of changes that we have been working on:

Install changes

Compatibility support code, like 32bit on 64bit machines, has been separated into special sets, to allow easy installation of machines that do not need to be able to run 32bit code.

Install media for some architectures has been split in small ("CD/R") images (w/o debug and compat sets), and full ("DVD-R") sets. This is also useful on hardware that came with a CD drive (instead of a DVD drive) and can not boot from a USB stick.

Manual pages come in two flavors, html and mandoc. Both have now their own sets, so one or the other can easily be left out of an installation.

All mac68k and macppc ISO images are now bootable.

Kernel changes

x86: PVH boot is now supported on non-XEN platforms (QEMU, Firecracker)
various new drivers for temperature (and other environmental) sensors and fan control
the heartbeat watchdog will detect locking errors that prevent softints from running or the timecounters from making progress on one of the CPUs
lots of enhancements for Linux emulation
new syscall: semtimedop(2)
new riscv port primarily targeting StarFive JH71XX-based devices
various bug fixes

Userland changes

libc and libm enhancements for C23 and POSIX.1-2024 support
userland support for manipulating/querying (U)EFI variables has been added
jemalloc has been updated to version 5.3
various bug fixes to libpthread and making functions signal safe
lots of miscelaneous bug fixes
the in-tree X.org components are all (well, nearly - there are a few minor/unimportant exceptions) up-to-date

3rd party software updates included

gcc for all architectures is now at version 12.5
gdb for all architectures is now at version 15.1
binutils for all architectures is now at version 2.42
OpenSSL got updated to the latest long term support version available: 3.5.1
OpenSSH is at version 10.0
many others updated, including dhcpcd, openresolv, unbound, nsd, ...

And a lot more...

... that we always forget to mention. The list of changes can be found in the beta build, split into changes upto the creation of the branch and changes pulled up to the branch before the 11.0 release.

Things that did not make it in-time for the branch

A few work-in-progress items unfortunately did not make it into this branch and will not be pulled up. The most missed ones are:

the next round of DRM/KMS updates to enhance x86 and arm graphics support
the big WiFi renewal project

These will happen in HEAD now carefully and after stabilization might be a good reason to create the next major branch earlier.

Please help us test this BETA!

We try to test NetBSD as best as we can, but your testing can help to make NetBSD 11.0 a great release. Please test it and let us know of any bugs you find.

Binaries are available on NetBSD daily builds and for various ARM based devices (with board dependent boot setup) on arm install images.

Please test NetBSD 11.0_BETA on your hardware and report any bugs you find!

Tentative schedule

No promises, but we will try to make this one of the shortest release cycles ever...

Ideally we will be in release candidate state at EuroBSDCon late in September, and cut the final release early in October.

New build cluster speeds up daily autobuilds

martin — Thu, 24 Jul 2025 13:09:58 +0000

Saying goodbye

For several years our autobuild cluster at Columbia University has been providing our CI and produced many official release builds.

Over the years, with new compiler versions and more targets to build, the build times (and space requirements) grew. A lot. A few weeks ago the old cluster needed slightly more then nine and a half hours for a full build of -current.

So it was time to replace the hardware. At the same time we moved to another colocation with better network connectivity.

Preparing for the future

But not only did the hardware age, the CI system we use (a bunch of shell scripts) needed a serious overhaul.

As reported in the last AGM, riastradh@ did most of the work to make the scripts able to deal with mercurial instead of cvs.

This is a necessary step in the preparation of our upcoming move away from cvs, which is now completed. While the build cluster currently (again) runs from cvs, we completed a few full builds from mercurial in the last few weeks.

User visible changes

The cvs runs for builds were purely time driven. To deal with latency between cvs.NetBSD.org and anoncvs.NetBSD.org there was a 10-minute lag built into the system, so all timestamps (the names of the build directories) were exact to the minute only and had a trailing zero.

This does not fit well with modern distributed source control systems. For a hg or git build the cluster fetches the repository state from the master repository and updates the checkout directory to the latest state of a branch (or HEAD). So the repository state dictates the time stamp for the build, not vice versa as we did for cvs.

As a result there is a difference between the time a build is started (wall clock) and the time of the last change of the current branch in the repository (build time or reproducible ID). You can see both times in the status page. Just right now it displays:

Currently building tag HEAD-lint, build 2025-07-22 19:19:02 UTC (started at: 2025-07-22 19:26:40 UTC).
No results yet.

And, obviously, we can now easily skip builds when nothing has changed - which happens often on old branches, but also may happen when all HEAD builds are done before anything new has been committed. Hurry up, you lazy developers!

While we are still running from cvs, the process of checking if anything has changed is quite slow (in the order of five minutes). So you may notice a status display like:

Currently searching for source changes...

while the "cvs update" is crawling. When running from hg (or git) this will be lot faster.

The new hardware

The new cluster consists of four build machines, each equipped with a dual 16 core EPYC CPU and 256 GB of RAM. As a "brain" we have an additional controller node with 32 GB RAM and a (somewhat weaker) Intel CPU. The controller node creates all source sets, does repository operations, and distributes sources but does not perform any building itself.

On the build machines we run each 8 builds in parallel, and each build with low parallelism (-j 4). This tries to saturate all cpus during most of the time of the overall build. Individual builds have several phases with little/reduced possibility of parallelism, e.g., initially during configure runs, or while linking llvm components, or near the end when compressing artefacts. The goal is not to run a single (individual) build as fast as possible, but the whole set of them in as little time overall.

The build log summary

The head of the result page create for each build now tries to give all the details necessary to recreate this particular build, e.g.:

From source dated Tue Jul 22 04:45:13 UTC 2025
Reproducible builds timestamp: 1753159513
Repository: src@cvs:HEAD:20250722044513-xsrc@cvs:HEAD:20250720221743

The two timestamps are the same, one in seconds since the Unix epoch, the other human readable.

The repository ID is, for cvs, again based on timestamps. But for hg or git you will see the typical commit hash values here.

Why a custom CI system?

We considered using an off-the-shelf CI system and customizing it to our needs instead of moving the fully custom build system forward. We also talked to FreeBSD release engineering about it and asked for their experience. Overall the work for customizing an off-the-shelf solution looked roughly equivalent to the work needed now to modify the existing working solution, and we saw no huge benefit for the future picking either of them.

What does our build infrastructure provide?

First and foremost, we can quickly verify if all of our supported branches indeed compile. While developers are supposed to commit only tested changes, usually they build at most one branch and architecture. But sometimes changes have unforeseen consequences, for example an install image of an exotic architecture growing more in size than expected.

Then, in theory, no NetBSD user has to waste any CPU cycles in order to install (for example) NetBSD-current or the latest NetBSD 9 tree. Instead you can simply download an image and install from that — no matter if your architecture is amd64 or a slightly more exotic one (but you will of course always be able to download the source tree and build that if that suits you better).

Note that a supported architecture is not just supported at one point in time and then as time progresses might start collecting dust and not compile anymore, making it hard to merge all current changes back into that tree. Instead once an architecture is supported, our CI system will without rest build that architecture as one of the many we support. Take the rather new Wii port as an example. Now that it is supported, you can at least for the foreseeable future download the latest and greatest NetBSD release, populate an SD card with the image and boot it. Now, in half a year, and in 10 years (and even further down the line).

Acknowledgements

We are grateful to Two Sigma Investments, LP for providing the space and connectivity for the new build cluster.

The NetBSD Foundation 2025 Annual General Meeting summary and logs

Leonardo Taccari — Wed, 28 May 2025 17:46:58 +0000

On May 17, 21:00 UTC we had The NetBSD Foundation Annual General Meeting on #netbsd-agm IRC channel on Libera.Chat.

We had presentations from:

board (billc)
secteam (billc)
releng (martin)
core (riastradh)
finance-exec (riastradh)
membership-exec (martin, christos)
pkgsrc-pmc (wiz)
pkgsrc-security (tm, leot)
gnats (dh)

At the end we also had a Q&A session open to anyone.

If you have missed it you can find the IRC logs here.

Welcome to Google Summer of Code 2025 contributors!

Leonardo Taccari — Thu, 8 May 2025 19:09:56 +0000

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2025 with 3 projects!

Here the list of the projects and contributors:

For the next 3 weeks mentors and contributors will get in touch for the community bonding period. Mentors will help contributors to get started with the project, introduce them to the community and get more familiar with the codebase and adjusting deliverables for the the project.

Welcome Dennis, Ethan and Vasyl!

The NetBSD Foundation will participate in Google Summer of Code 2025!

Leonardo Taccari — Thu, 27 Feb 2025 19:10:49 +0000

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2025!

Would you like to contribute to NetBSD and/or pkgsrc in the next months? Google Summer of Code is a great chance for that!

You can find a list of possible projects at Google Summer of Code project page. Of course, you can also propose your own!

Please reach us via #netbsd-code IRC channel on Libera.Chat and/or via mailing lists.

If you are more interested about Google Summer of Code please also check official homepage at g.co/gsoc.

Looking forward to a great Summer!

Google Summer of Code 2024 Reports: Test root device and root file system selection

Leonardo Taccari — Fri, 3 Jan 2025 20:42:15 +0000

This report was written by Diviyam Pat as part of Google Summer of Code 2024.

This summer I worked on NetBSD's kernel test framework to cover root device discovery and root file system selection. This area of the kernel is not very well documented and program flow has to be determined by reading the code.

I would also like to tell you about my early interactions with the project, let me start with project findings.

Why NetBSD?

Google Summer of Code 2024 is not my first time applying to GSoC. My first time was in 2022, in my first year of college. I have been fascinated with newer Windows versions since my Intel Core Duo i3 days as every new Windows version used to bring new changes and features, from Windows XP to Vista to 8.1 and then to 10 (cosmetic only) but was very heavy on my PC's memory usage that was upwards of 60% leaving very little room for applications and games.

My Intel i3 would be enough for it. This experience made me decide I wanted my project to be in the operating system space. I ventured into all OS projects on the Google Summer of Code website. Gentoo, Debian but that didn't turn out well. I then decided to explore BSDs. The community seemed friendlier, more responsive, and active in helping beginners. I started mailing all the mentors about my interests (I realized I should have done a lot more work before mailing them, it shows more dedication towards the project.)

Christoph explained the project in great detail to me, helped me with getting started and guided me through the hard parts of the project.

Project Details

Root device and file-system selection is made during the later stages of the boot process by the kernel. The kernel config file defines candidates for the root device and the kernel selects one after validating those options. If no options are defined, the auto config subroutines handle configuration. Head over to my docs for more details here. This functionality is handled primarily by the function setroot in file kern_subr.c. It also calls specialized functions for a number of cases. Our task was to add ATF tests for this function and some other functions that assist setroot. This part of the kernel works, and it has worked for over 30 years but the code is rather complex to read and there is no documentation. The only way to understand it is to read the code.

At any given stage when any condition fails the fallback option is to ask the user manually for the device. Thus this part of the kernel rarely needs attention. There are some global functions used in conditions inside setroot: rootspec, bootspec, etc. These variables are either set through the config file or through other machine-dependent kernel functions like findroot etc. We need to manually set them in our test cases and also need to stub kernel functions used by setroot and other functions. We wanted to make these test cases use 'vnd' devices, but we ran into bugs, and Christoph was trying to fix them. Therefore we had to resort to stubbing. We validate the global variables. We also test the tftproot_dhcpboot function that loads the contents of a memory disk device from a TFTP server and uses that as root device. Devices are represented by the device_t struct which is populated by the kernel. We mock this behavior through the create_device function and use this in the test programs. User input is handled by stubbing the cngetsn function. Global variables and arguments are set to test values in the body of the test cases and the function being tested is called. The test file is divided into 3 parts: 1) setroot_root, 2) setroot_ask, and 3) tftproot_dhcp. In the file kern_subr.c setroot() calls these functions but here we test them independently

Conclusion

I have worked on enhancing NetBSD's ATF tests to test the root device and file system selection process, testing the setroot function and its dependencies. These tests shall improve coverage of the ATF tests to the setroot function and in general, to root device selection. In the future, contributors can rely on these tests for kern_subr.c's functionality.

NetBSD 10.1 available!

martin — Thu, 19 Dec 2024 11:55:00 +0000

The NetBSD project is pleased to announce the first update of the NetBSD 10 release branch NetBSD 10.1! See the release announcement for details.

This release includes 9 months of bug fixes and a few new features after the 10.0 release in March. It also gives those still using older release a good reason to finally update to the NetBSD 10 release branch, even if they avoid dot-zero releases by all means.

If you want to try NetBSD 10.1 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

EuroBSDcon 2024 in Dublin, Ireland: some notes after the conference

Leonardo Taccari — Fri, 4 Oct 2024 13:19:58 +0000

I have not been at EuroBSDCon for a while, unfortunately! My last EuroBSDCon was EuroBSDcon 2017 in Paris, France (and I have also blogged about it)!

I was very excited to come back to EuroBSDCon. Meet again in person with people. Talk in the "hall track"... and, why not!, have some fun and do some shenanigans in the nights! :)

And... definitely it was very nice, instructive and fun!

I have not fully unpacked the bag but it's time to share some notes!

Friday (20/09): arriving in Dublin

I arrived in Dublin on Friday afternoon. After some sightseeing on foot I got lost in the paintings of the National Gallery of Ireland.

I then spent the rest of the evening and night in Porterhouse Temple Bar. I had a tasty soup and garlic bread and several delicious craft beers!

Saturday (21/09): 1st day of conference talks and social event

My hotel was a 40 minutes walk from University College Dublin (UCD). I arrived a bit early for the registration. I then met some other NetBSD folks that I had missed in person since 2018 and met new ones.

View from O'Reilly Hall, University College Dublin.

After the Opening Session that welcomed us, the conference started with the opening keynote Evidence based Policy formation in the EU what Evidence are we Presenting to the EU? by Tom Smyth. Tom Smyth shared his experience on evidence based policy formation in the European Union from a point of a relatively small ISP. EU is open to feedback and as a BSD community we can shape and influence policies.

Flipping Bits: Memory Errors in the Machine, Taylor R Campbell

Taylor talked about bit flips, the memory errors in the machine.

Memory errors caught in the act: corruption of a filename in Riastradh's local machine.

He started sharing a catch of bit flip in a filename corruption on his local machine in NetBSD src repository. A bit flipped and that resulted from external/gpl3/gdb/dist/gdb/testsuite/gdb.linespec/cpls.cc to e\370ternal/gpl3/gdb/dist/gdb/testsuite/gdb.linespec/cpls.cc (In ASCII lower case x is \170 that is 01111000 in binary, while \370 is 11111000, the most significant bit got flipped!).

He also opened several PRs - due to several experienced kernel panics mostly in ZFS - before he realized that it was bad RAM.

As part of the talk a lot of fundamentals concepts and theory behind Error Detection And Correction (EDAC), causes of memory errors, where memory errors can happen, error severity and error persistence were shared.

Taylor then talked and digged in ACPI Platform Error Interface (APEI) that is the standard interface in ACPI that abstract EDAC device registers.

In NetBSD APEI is supported by the apei(4) driver.

The apei(4) driver also exposes a sysctl interface to APEI EINJ (Error INJection) that permit to also inject errors. Using such interface Riastradh live demoed that and trigger a memory error that was corrected and reported by apei(4)!

Riastradh live demoing a memory error using APEI EINJ via apei(4).

The talk was great and super-interesting. Memory errors are also pretty common. Taylor also shared a lot of anecdotes and that make his talk even more fun and interesting!

An introduction to GPIO in RPi3B+ and NetBSD, building a wind-speed logger as an application, Dr. Nicola Mingotti

Dr. Nicola Mingotti talk was a great introduction (and more) to Generalized Pin Input Output (GPIO)!

He started really from the start by populating a uSD card and installing and configuring NetBSD on a Raspberry Pi 3 Model B+.

He then introduced GPIO, how the RPi3B+ pin maps to the GPIO number and then we were ready to get our hands on GPIO!

As first exercises he showed how to set a PIN state (on/off) and read a PIN state via gpioctl(8). This can be used respectively to turn a LED on/off and to read the state of a switch.

The second series of exercises looked on how fast gpioctl can be. This is limited for several applications and so Nicola introduced how to write and read pin states in C via ioctl(2). This is much faster and with that we can go from switches to square waves!

To avoid bit-banging and polling respectively gpiopwm(4) and gpioirq(4) can be used. Nicola shared several applications of them, like blinking LED and loopback. (Another possible application, left as an exercise to the reader is the "daemon toggler". The "daemon toggler" starts/stops a daemon (e.g. ntpd(8)) based on the state of a physical switch!)

He then shared a much bigger application a Wind-Speed Logger (AKA WSL). This was used by Nicola in order to evaluate if wind turbines could be installed or not. He also shared how he adjusted an RPi case and built housing for it (the RPi will be outside, needs to cool off so needs some ventilation but at the same time the housing should block rain!)

Nicola showing the sensor used to build the Wind-Speed Logger (WSL).

He concluded the talk on why he used NetBSD.

The talk was really educational. Nicola did a great job in summarizing and providing a lot of references. If you are more interested I suggest to catch up with the video recordings, slides and try to do the exercises in it!

"Hall track" and preparing for the social event

After Nicola's talk I have spent some time in the "hall track" talking with other people and missed a couple of talks (recording should be available so I will hopefully catch up!).

I have then attended Stefano Marinelli's talk Why (and how) we're migrating many of our servers from Linux to the BSDs.

Stefano shared his more than 2 decades old experience with BSD systems and how he made his passion his profession.

He shared his philosophy, experience with clients and why it is important to focus on solving problems.

During the talk he shared also several interesting stories with clients. In one of them to avoid possible bias on BSD systems he migrated client hosts without informing them. A client called alarmed because he noticed a massive performance boost!

His talk was inspiring and you can find more in his I Solve Problems blog post.

After Stefano's talk we gathered to join the social event and took a DART train (Dublin Area Rapid Transit).

Social event: BrewDog Dublin Outpost

The social event was in BrewDog Dublin Outpost.

We were in an area dedicated to EuroBSDCon participants so that we can eat, drink and talk. There was a buffet and we received tickets to grab beers.

Several folks gifted me an handful and I have definitely had a pretty ample beer tasting experience too! :)

I also had a Vegan Spicy Meaty pizza: a pizza with seitan, mushrooms, chilli flakes, fresh red chilli, tomatoes and vegan mozzarella. My italian-pizza-side is usally pretty orthodox and I usually go for a pizza marinara! :) But overall that was actually pretty nice and I really appreciated the topping!

I have staid with a couple of folks until the closure. With Christoph Badura (<bad@>) we walked in the desperate search of grabbing some more food. However, at the end we ended up in The Temple Bar Pub for "only another beer"! We met with some friendly Swedish and Swiss tourists and we started talking about BSD systems at 2:00 AM! The weather was pretty nice (it was always pretty cloudy but there was no rain for the entire conference) and we decided to continue walking back to our hotels. At the end we have walked for a bit less than 9 kilometers from Temple Bar to nearly Booterstown! That was a great walk though and definitely we had no traces of hangovers in the morning! :)

Sunday (22/09): 2nd day of conference talks

I wake up a bit late on Sunday and arrived in UCD at around 12:00 and staid until lunch in the "hall track".

For lunch the vegetarian dish was a vegetarian curry, pretty tasty!

On Sunday we had a longer lunch break also to take a family photo.

EuroBSDCon 2024 family picture. You can find more EuroBSDCon photographs taken by Ollivier Robert at EuroBSDCon 2024 - Dublin, Ireland album.

After lunch I have attended FreeBSD at 30 Years: Its Secrets to Success by Kirk McKusick. In this talk Kirk looked back at 30 years of FreeBSD history (and also more for BSD years!) and what made its success. He talked about a lot of different topics, including leadership, development, importance of adopting ideas and codes from NetBSD and OpenBSD, communication, documentation and project culture. He also shared several interesting statistics and demographic about FreeBSD.

I have then attended Confidential Computing with OpenBSD by Hans-Jörg Höxer. Hans-Jörg introduced concepts about confidential computing, the threat model that it cover and then digged in AMD Secure Encrypted Virtualization (SEV) and how he is using that in OpenBSD vmm(4).

Then I have attended Building an open native FreeBSD CI system from scratch with lua, C, jails & zfs by Dave Cottlehuber. In this talk Dave shared the design and implementation of a Continuous Integration (CI) system focused on FreeBSD technologies but that can be ported also to other BSDs.

The final talk I have attended was SIMD-enhanced libc string functions: how it's done by Robert Clausecker and Getz Mikalsen. In this talk Robert shared how several libc string functions were reimplemented in other to use SIMD techniques on amd64 and arm64. Getz worked on porting such work on arm64 as part of Google Summer of Code 2024 and he shared his work and challenges in porting that. The talk was interesting and micro-benchmarking showed performance increase by factor of 5 on average!

Then I have joined the Closing Session.

There was a wrap up of the conference and some stats about it.

And *drumrolls* the next EuroBSDCon location was announced! EuroBSDCon 2025 will be in Zagreb, Croatia!

After the Closing Session with other NetBSD folks we met again for one last dinner. We met with Andy Doran (<ad@>) and we had some junk food and several beers.

Conclusion

I had not traveled a lot in the last years and I have missed several EuroBSDCon-s and I really regret that! EuroBSDCon 2024 was great: very interesting talks, friendly folks and it was some time that I did not had so much fun!

Dublin was also really nice. All the locals were also very friendly. I hope to come back to both Dublin and Ireland to do some much more sightseeing in a more relaxed pace. Enjoy food, beers, drinks and more. Talk with locals.

I would like to thanks a lot to all the EuroBSDCon organizers for the amazing conference!

I also would like to thanks The NetBSD Foundation that funded my EuroBSDCon registration.

If you have never been to EuroBSDCon and you are curious about BSDs... I strongly suggest to attend either as participant or speaker! Folks are super-friendly, there are a lot of interesting tutorials and talks and I'm pretty sure you will have fun too!

And... if you are still reading until here... thank you too! :)

Google Summer of Code 2024 Reports: ALTQ refactoring and NPF integration

Leonardo Taccari — Thu, 3 Oct 2024 10:15:26 +0000

This report was written by Emmanuel Nyarko as part of Google Summer of Code 2024.

Alternate Queuing has been of great need in the high Performance Computing space since the continuous records of unfair disruption in network quality due to the buffer bloat problem. The buffer bloat problem still persists and not completely gone but modern active queue managements have been introduced to improve the performance of networks.

ALTQ was refactored to basically improve maintainability. Duplicates were handled, some compile time errors were fixed and also performance has been improved too.

This improves the quality of developer experience on maintaining the ALTQ codebase.

The Controlled Delay (CoDel) active queue management has also been integrated into the netbsd codebase. This introduces improvements made in the area of quality of service in the netbsd operating system. CoDel was a research led collaborative work by Van Jacobness and Kathleen Nichols which was developed to manage queues under control of the minimum delay experienced by packets in the running buffer window.

As it stands now, ALTQ in NetBSD is integrated in PF packet filter. I am currently working to integrate it in the NPF packet filter. The code in NetBSD is on the constant pursuit to produce clean and maintainable code.

I'll also be working to improve quality of service in NetBSD through quality and collaborative research driven by randomness in results. As a research computer scientist, I will be working to propose new active queue managements for the NetBSD operating system to completely defeat the long lasting buffer bloat problem.

More details of the work can be found in my Google Summer of Code 2024 work submission.

NetBSD 8.3 released and end of support for netbsd-8

martin — Tue, 7 May 2024 18:52:08 +0000

The NetBSD Project is pleased to announce NetBSD 8.3, the third and final release from the NetBSD 8 stable branch.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 8.2 in March 2020, as well as some enhancements backported from the development branch. It is fully compatible with NetBSD 8.0.

This also represents the end-of-life for the netbsd-8 release branch. No further security updates will happen. Users running 8.2 or an earlier release are strongly recommended to upgrade to a newer branch, preferably the recent NetBSD 10.0 release.

Pkgsrc has already desupported the netbsd-8 branch.

See the full release announcement (including download links).

X.Org on NetBSD - the state of things

Nia Alarie — Sat, 4 May 2024 12:05:20 +0000

A few years ago, I wrote a "state of things" blog post about Wayland on NetBSD. It's only natural that I should do one about X11, which is used by far more people to get a graphical environment on NetBSD.

There are a lot of differences from how NetBSD and the typical distributor ship X.Org. For one, we ship it as an optional monolithic package rather than separate individual packages. This means every driver is included on every system, rather than as an optional module. Sometimes, this means we need to fine-tune driver selection to ensure the correct drivers are loaded on the correct hardware, since multiple conflicting drivers can claim a video output. We also want sensible fallbacks, since if you're using a GPU from the future with an old OS version, you probably want X to seamlessly fall back to a regular framebuffer.

Secondly, the way our "xsrc" repository is set up, it's effectively functioning as a fork of X.Org that regularly pulls from upstream freedesktop.org (but does not push back). This allows X development to happen as part of NetBSD.

Thirdly, we use our own build system based purely on BSD makefiles, not X.Org's based on GNU autotools. This fits well with our build.sh cross-compilation system.

We have a number of drivers which have not made their way upstream. Perhaps the most ubiquitous of these is xf86-input-ws, a driver which came from OpenBSD, targets an API from NetBSD, and continues to be developed in both. This is a generic input driver that can support any pointing device that the kernel supports. Unlike xf86-input-mouse, it doesn't assume the device is a mouse, and can support advanced touchpad and touchscreen features. Other NetBSD exclusives include xf86-video-pnozz, xf86-video-mgx, and xf86-video-crime. While these all share the "xf86" name inherited from the historical XFree86 distribution, none of them are exclusively for x86.

There are a number of drivers that are accelerated when used in NetBSD, but the acceleration support is missing upstream. This is mostly due to the work of macallan@, who has diligently worked on drivers for accelerators found on SPARC and PowerPC hardware.

X.Org has historically supported two 2D acceleration modes, XAA and EXA. XAA seems complicated - according to the X.Org Foundation it supports accelerating "patterned fills and Bresenham lines" (eh?). XAA was removed from the X.Org server in 2012, and many old drivers were not updated to support the newer and simpler EXA model, except in NetBSD, over a time period of several years.

Did you know that Nvidia used to have an open source graphics driver? It supported 2D acceleration for a range of cards. In NetBSD, it's retained for platforms that included embedded Nvidia chips and aren't capable of (or predate, or don't want) the modern novueau driver. Six years ago, it was updated in NetBSD to support EXA acceleration.

There are a few ways our X integration could be improved. While lots of attention has been paid to the server, less has been paid to clients (programs). Did you know that X includes a text editor, and that text editor supports syntax highlighting and spell checking?

NetBSD includes its own command-line spell checker and associated dictionaries, spell(1), inherited from the BSD UNIX of yore. It's pretty basic, and only supports variations of English. To get spell checking to work in xedit, you need to install ispell (another command-line spell checker) from pkgsrc, install a dictionary, then set some Xresources (or create symlinks) to make sure xedit finds ispell. This could surely be streamlined by teaching xedit about spell.

We also ship every program that has been included with historical X.Org distributions. This includes well-known things like xterm, slightly less well-known things like xbiff(1), and obscurities like bitmap(1) (apparently a 1-bit-per-pixel alternative to MS Paint). A while ago, we removed some libraries which are no longer used by the modern X server, and maybe we should evaluate whether we need all of these programs too. xmh(1) is a frontend for a mail system that isn't included in base. Together, bitmap and xmh are around 300 kilobytes.

We include fonts, bitmaps and scalable, for a wide range of computing devices. In the latest versions of NetBSD, the font size will automatically scale with the screen size to support HiDPI displays as well as small mobile devices. However, we don't ship a scalable cursor theme at the moment. We're also missing high-resolution fonts for Japanese, a shame considering the popularity of NetBSD in Japan. Koruri looks interesting and is suitably small, maybe we should import it.

While we have many useful simple programs by default (a clock, a calculator, an editor, a window manager, a compositor, a terminal emulator...), we're notably missing a screen locking program for X in the default install, although we have lock(1) for the tty.

The big question - does all this have a future? The good news is that all new hardware has generic support in X. Someone writes either a modesetting kernel driver or a classical wsdisplay kernel driver and they will be automatically supported by the associated drivers in X. The bad news is that to have applications running we require access to a larger open source ecosystem, and that ecosystem has a lot of churn and is easily distracted by shiny new squirrels. The process of upstreaming stuff to X.Org is an ongoing process, but it's likely we'll run into things that will never be suitable for upstream.

Of course, on NetBSD, you also have the option of trying vanilla modular X.Org from pkgsrc, or using something else entirely.

NetBSD 9.4 released

martin — Tue, 23 Apr 2024 05:14:21 +0000

The NetBSD Project is pleased to announce NetBSD 9.4, the fourth release from the NetBSD 9 stable branch.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.3 in August 2022, as well as some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0. Users running 9.3 or an earlier release are strongly recommended to upgrade.

The general NetBSD community is very excited about NetBSD 10.0, the latest NetBSD release, but if for some reason you can not (or do not want to) update to 10.0, it is strongly recommended to update to 9.4. This is especially true for users still using a NetBSD 8.x release as that old release branch will be desupported by the end of April 2024.

Full release notes, including download links

NetBSD 10.0 available!

martin — Sat, 30 Mar 2024 19:55:38 +0000

The NetBSD project is pleased to announce the eighteenth major release of the NetBSD operating system NetBSD 10.0!
See the release announcement for details.

The netbsd-10 release branch is more than a year old now, so it is high time the 10.0 release makes it to the front stage. This matches the long time it took for the development branch to get ready for branching, a lot of development went into this new release.

This also caused the release announcement to be one of the longest we ever did.

If you want to try NetBSD 10.0 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

Statement on backdoor in xz library

Nia Alarie — Sat, 30 Mar 2024 09:09:06 +0000

Recently, a backdoor was discovered in the xz compression library. xz/liblzma are included as a part of NetBSD and used by the project for distribution of new releases and packages.

The version of xz shipped in all stable (and unstable) versions of NetBSD predates any code changes by the author of the backdoor. NetBSD is therefore safe and unaffected by the recent discoveries. It is believed that the attack only targets Linux/glibc, but checking this allowed us to rule out any other attempts at compromising the library by the author.

The version of xz shipped in pkgsrc, however, is affected. Using xz from pkgsrc is a non-default setting on NetBSD, and requires explicit opt-in. Most users of NetBSD will not install xz from pkgsrc because the version from the base system is preferred. However, users of pkgsrc on other platforms will need to take precautions.

Regardless of NetBSD being affected or not, the discovery of the backdoor is a wake-up call and further discussion will be happening internally over how to proceed.

NetBSD 10.0 RC6 available!

martin — Wed, 13 Mar 2024 23:10:11 +0000

The NetBSD project is pleased to announce the sixth release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

This also caused the release announcement to be one of the longest we ever did.

Since RC1 there have been numerous changes, including major updates to external software included in the release: Postfix, OpenSSH, and the firmware used for Raspberry PI devices. Various issues with RC1 have been fixed, including installer (sysinst) crashes. Lots of architecture specific fixes happend, e.g. various toolchain changes for VAX (so it is now finaly self-hosting again), and kernel changes for macppc, netwinder, and alpha.

For RC3 only few (relatively) minor changes were made, including https certificate verification in libfetch (which is used by pkg_ad(1)), and also improvements to the EFI bootloader to better deal with booting from CD (or in virtual machines ISO images), plus lots of various bug fixes.

RC4 became necessary as a few very important DRM/KMS issues especially for Intel GPUs have been resolved. And as an (unexpected) bonus support for the Nintendo Wii has been added to the evbppc port.

RC5 has a few important security related updates of third party components (named, nsd, unbound, wpa_supplicant).

RC6 fixes a few issues with the new named/bind imported for RC5 plus several minor issues.

Especially on amd64 machines please notes that we got a new DRM/KMS subsystem version, and this may lead to fallout on some hardware. Unfortunately not all known bugs from the release engineering pre-release task list could be fixed in time for this release - we will continue to improve the current state and hope to have more of them solved for the next (10.1) release.

If you want to test 10.0 RC6 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 10.0 RC5 available!

martin — Wed, 28 Feb 2024 19:37:19 +0000

The NetBSD project is pleased to announce the fifth (and probably last) release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

This also caused the release announcement to be one of the longest we ever did.

RC4 became necessary as a few very important DRM/KMS issues especially for Intel GPUs have been resolved. And as an (unexpected) bonus support for the Nintendo Wii has been added to the evbppc port.

RC5 has a few important security related updates of third party components (named, nsd, unbound, wpa_supplicant).

If you want to test 10.0 RC5 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 10.0 RC4 available!

martin — Wed, 7 Feb 2024 15:58:51 +0000

The NetBSD project is pleased to announce the fourth (and probably last) release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

This also caused the release announcement to be one of the longest we ever did.

RC4 became necessary as a few very important DRM/KMS issues especially for Intel GPUs have been resolved. And as an (unexpected) bonus support for the Nintendo Wii has been added to the evbppc port.

If you want to test 10.0 RC4 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 10.0 RC3 available!

martin — Wed, 17 Jan 2024 18:11:06 +0000

The NetBSD project is pleased to announce the third (and probably last) release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

This also caused the release announcement to be one of the longest we ever did.

If you want to test 10.0 RC3 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 10.0 RC2 available!

martin — Thu, 4 Jan 2024 08:21:36 +0000

The NetBSD project is pleased to announce the second (and probably last) release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

This also caused the release announcement to be one of the longest we ever did.

If you want to test 10.0 RC2 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 10.0 RC1 available!

martin — Sat, 11 Nov 2023 13:56:20 +0000

The NetBSD project is pleased to announce the first release candidate of the upcoming 10.0 release, please help testing!
See the release anouncement for details.

The netbsd-10 release branch is more than a year old now, so it is high time the 10.0 release makes it to the front stage. This matches the long time it took for the developement branch to get ready for branching, a lot of developement went into this new release.

This also caused the release anouncement to be one of the longest we ever did.

If you want to test 10.0 RC1 please check the installation notes for your architecture and download the prefered install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

FOSDEM 2023

Pierre Pronchery — Wed, 8 Feb 2023 17:25:39 +0000

FOSDEM took place last week-end, as an offline-first event again for the first time since 2020. It was located as usual at the university campus of the ULB in Brussels. It was packed with developers, users, passionate and professionals of Open Source software, and while NetBSD did not have a booth this year, its presence could be felt on Saturday morning at the BSD DevRoom thanks to the many developers who made it to the conference.

Together with Rodrigo Osorio of the FreeBSD project, I had the pleasure to help manage the DevRoom, have a front seat for the talks, and even start the session by introducing the BSD Driver Harmony initiative.

The staff and respective speakers are currently busy uploading slides and reviewing videos, so keep in mind to check again for new content in the coming few days and weeks if you missed anything or need to dig further into any event from this awesome conference!

Finally, I would like to thank the NetBSD Foundation for sponsoring me to manage the room and attend the GSoC meet-up.