Sergey Bugaev committed public headers for the GNU Mach AArch64 port. He writes that

...there is now a real port of GNU Mach to AArch64, using these headers as its actual API/ABI. We got the Mach port to run glibc, several Hurd servers, and simple Unix programs, including things like fork/exec and signal delivery & handling working, which exercises these architecture-specific definitions (thread state & exceptions). We have also managed to do some testing on real hardware; although not everything is working yet, we have seen thread state manipulation & Mach handling an unaligned SP fault work as expected.

His email also mentions that the GCC patches that enable GCC to compile GNU/Hurd programs on AArch64 have been merged! This apparently will make it easier to merge his AArch64 specific glibc patches.

He also added new tests to check that threads handle signals well, and he also fixed a use-after-free in vmmappageable_scan(). He also hosted a lengthy Hurd code jam (apologies for the poor audio quality).

He also very notably added support to copy a send once right to Mach and MIG.

Some time ago, Sergey also wrote the terrible-mdns-responder, and if you would like to be able to type in ssh HOSTNAME.local and connect to a locally running Hurd, then you may want to try it!

Flávio Cruz fixed some issues with the Hurd compiling on GCC 14.

Luca Dariz fixed message sizes, where the size was not set by userspace, and he added another test to check message sizes on various code paths.

Debian GNU/Hurd now offers an experimental SMP GNU Mach kernel (32-bit only) and the official rustc compiler! Now that we have ported rustc to Debian GNU/Hurd, we can compile important packages like librsvg. Debian GNU/Hurd now can compile 71% of the packages from the Debian archive.

Now for something trivial but fun! I updated the guide on the Hurd wiki that shows how one can run their own personal ext2fs translator.

You could go crazy even! Why not make something like this:

 ~/silly <--> silly.fs
    |   \
    |    \
    |     \
    |      \
    |       \
   \|/       \/
  silly1 <-> silly1.fs
        ...

 /hurd/joshua/silly/silly1/silly2/silly3/silly4

Each sillyN is another ext2fs filesystem! Make sure that as N gets bigger sillyN.fs gets smaller. Let us know in the #hurd irc channel how "silly" you are.

The current record is ~/silly1/silly2 where each sillyN is a different ext2fs. Does anyone want to volunteer to beat the current record?

So if you want to test if your favorite packages work on the Hurd and contribute towards making the full GNU system usable for a wider range of people, please check the contributing page.

The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). More detailed.

GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides an Inter Process Communication (IPC) mechanism that the Hurd uses to define interfaces for implementing in a distributed multi-server fashion the services a traditional operating system kernel provides. More detailed.

Etienne Brateau modified console-client to use xkbcommon instead of x11 for xkb extended support, which improves keyboard layout coverage a lot!

Flavio Cruz also worked on porting GDB to the 64-bit Hurd, implemented setcontext/getcontext/makecontext/swapcontex () in glibc, and implemented child process resource accounting. The latter implementsgetrusage(RUSAGE_CHILDREN, ) and populates child related data in times().

He fixed the perl testsuite for the Hurd, and he also posted a RFC to enhance tracing utilities, which he used to port the RPC format to 64 bit.

Flavio also had a smattering of fixes here, here, here, here, and here.

Damien Zammit had some fixes including fixing the console with APIC enabled, patching GNU Mach to support ACPI v2, fixing baud rate on com ports, porting the Hurd to some AMD CPUs (WIP), adding HPET (high precision timers). He also worked on making ext2fs use xattr by default to store translators.

Damien also worked on more SMP fixes here, here, here, here, here, and here. Hurd currently boots in SMP mode on the BSP. Damien wrote a test program that lets you run a task on the APs.

Sergey Bugaev patched binutils to support the GNU/Hurd on AArch64, and he wrote some patches to make the Hurd easier to port here, here, and here,

Sergey also posted a fairly large RFC patch series for his AArch64 port. He writes:

MIG seems to just work (thanks to all of Flávio's work!). I'm using
 the same message ABI as on x86_64, and haven't seen any issues so far
 — neither compiler errors / failed static assertions (about struct
 sizes and such), nor hardware errors from misaligned accesses.

He also mentions that "the hardware hardening features (BTI, MTE, PAC) are currently 'not really supported', but I do want to support them in the future." Samuel merged many of the patches.

In Sergey's later glibc patch series, he wrote about the AArch64 port progress. He wrote:

Last time, there was no AArch64 port of GNU Mach, and so the only testing
 I have done was running a simple statically-linked executable on Linux under
 GDB, which, nevertheless, helped me identify and fix a number of issues.

 Since then, however, I have been (some may say, relentlessly) working on
 filling in the missing piece, namely porting GNU Mach (with important help &
 contributions by Luca D.). I am happy to report that we now have an
 experimental port of GNU Mach that builds and works on AArch64! While that may
 sound impressive, note that various things about it are in an extremely basic,
 proof-of-concept state rather than being seriously production-ready; and also
 that Mach is a small kernel (indeed, a microkernel), and it was designed from
 the start (back in the 80s) to be portable, so most of the "buisness logic"
 functionality (virtual memory, IPC, tasks/threads/scheduler) is explicitly
 arch-independent.

 Despite the scary "WIP proof-of-concept" status, there is enough
 functionality in Mach to run userland code, handle exceptions and
 syscalls, interact with the MMU to implement all the expected virtual
 memory semantics, schedule/switch tasks and threads, and so on.
 Moreover, all of GNU Mach's userspace self-tests pass!

 This meant there was enough things in place for me to try running
 glibc on it, and the amazing thing is my simple test executable, the
 same one I previously tested on Linux with GDB, just worked on real
 Mach without me having to make any additional changes to the glibc
 side, or even recompile it.

 But I did not stop there, and I got several of the core Hurd servers
 working!  Namely, these are ext2fs, exec, startup, auth, and proc
 servers. All of them but ext2fs are dynamically linked; ld
 aarch64.so.1 sucessfully locates and maps the programs themselves
 and their required dependencies, and Mach pages in code and data
 pages from ext2fs as they are accessed, transparently to the
 program, just as one would expect it to.

Be sure to read more from his announcement email.

Sergey also announced a new Alpine distro based on Hurd (it currently does not have a name). His goal is to add another Hurd distribution, which will force the Hurd to work with different software and hopefully fix more bugs. Alpine Linux also usually runs the latest software, so this new Hurd distribution will be for those who like living on the bleeding edge. He writes:

I have ported many Alpine packages to build with (i386, for now) GNU
 Mach, the Hurd, and glibc, replacing Linux and musl. If you want a
 specific number: as of yesterday, I have 299 installable packages; the
 number of source packages is of course several times less than that.
 Still, this includes things like curl, ncurses, nano, native binutils
 & gcc & mig, libffi, openrc, openssl, util-linux, busybox, apk-tools,
 ... and of course gnumach, hurd (with dependencies like libdaemon,
 parted, ...), and glibc. Importantly, all this cleanly bootstraps
 using the scripts/bootstrap.sh script that they provide; this is too
 somewhat like Flávio's scripts, but it uses the real full Alpine
 package definitions for e.g. GCC (patched by me for glibc / Hurd
 support).

 Above the kernel and libc, things remain much as they were in upstream
 Alpine: the system boots (will boot — I haven't tried it yet) with
 busybox init & OpenRC, and uses busybox as its basic userland. GNU
 software such as Bash is installable, too.

This new Hurd distribution currently does not have a mailing list, irc room, or website. If you are interesting in helping Sergei to develop it further, then please email [email protected].

Luca Dariz added userspace tests, which work with qemu. We currently test the Hurd in qemu on a GNU/Linux host. He also described how he currently uses the 64-bit Hurd. Perhaps you should follow that advice if you want to try running a 64-bit Hurd on qemu.

Manolo de Medici made a WIP patch series that gets qemu to run on the Hurd.

I organized a belated GNU/Hurd Christmas party. We had 6 or 7 attenders, which was pretty awesome! I was not able to record the event, so perhaps we should try for another meet perhaps at the end of Q2. If you would like to help me plan/organize/join such a party, then please email [email protected].

If you want to test if your favorite packages work on the Hurd and contribute towards making the full GNU system usable for a wider range of people, please check the contributing page.

The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). More detailed.

GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides an Inter Process Communication (IPC) mechanism that the Hurd uses to define interfaces for implementing in a distributed multi-server fashion the services a traditional operating system kernel provides. More detailed.

Samuel Thibault fixed gcc's Hurd's default pie and added static pie support. He also added a whatis command to GNU Mach's kernel debugger, which can determine what an address points to (a stack? a port? some kalloc? ...). He also added hurd-amd64 support to GCC.

Samuel requested that the Hurd team set up a continuous integration, so that when developers make code changes, they can be certain that they did not break anything. It turns out that the Hurd supports several different environments: 32 bit, 64 bit, 32-on-64 bit, ACPI, non-ACPI, SMP, non-SMP, Xen, etc. Apparently Flavio has a personal CI, but it is set up in a Debian independent way. If you are interested in helping the Hurd project set up a CI, then please get in touch!

Luca Dariz worked on adding some simple GNU Mach user-space tests . With a working MiG, a GNU/Linux machine can run make check in the GNU Mach source code, which will launch qemu to ensure that 32 bit (PAE and non PAE), 32 on 64 bit, and full 64 bit GNU Mach works. We currently do this testing on GNU/Linux, because qemu does not run on the Hurd.

Many people worked on the Hurd's new x86_64 bit support. A 64-bit debian buildd is set up, and we can bootstrap a chroot! The hurd-amd64 wanna-build infrastructure is also set up. We are having issues reliably building packages on a 64-bit Hurd, which lead Samuel to uncover and fix a proc leak.

Flavio Cruz improved GNU Mach's IPC by reordering mach_msg_type_t fields to byte align msgt_name and msgt_size. He also created a patch series to avoid message resizing for x86_64. He also removed untyped mach RPC code. GNU Mach uses typed IPC. The Hurd could support both typed and untyped, but it appears that the Hurd only uses typed RPC. So it seems best to remove any untyped RPC code.

Sergey Bugaev added GNU Mach entry re-coalescing support. Essentially, Mach was not always able to merge two vm entries that are made next to each other, which was slowing down ext2, bash, etc. Sergey allowed GNU Mach to merge entries in the common cases, which greatly helps ext2fs for instance.

Sergey is also working on porting the Ladybird web browser to the Hurd. The author of this post uses the netsurf web browser on the Hurd, which works on simple websites like wikipedia, but it badly renders javascript heavy websites, which makes many websites un-useable. If Sergey is successful in porting Ladybird, then Hurd users could start using sites like Github! It is worth noting that someone should update the Firefox port as well.

Sergey also started porting the Hurd to AArch64! While a port to RISC-V might be more exciting, it is worth mentioning that AArch64 is more established. What is interesting is that Sergey is already able to build Hurd servers for AArch64! Normally, in order to run the binaries, one would port GNU Mach to AArch64. Luckily for us, he turned to GDB and directly ran a 'Hello World' Hurd AArch64 binary on Linux! This helped him fix some bugs along the way. We still need to define the ABI and complete the GNU Mach port, but this is exciting news!

Tobias Platen started porting GNU Mach to Power9.

So if you want to test if your favorite packages work on the Hurd and contribute towards making the full GNU system usable for a wider range of people, please check the contributing page.

The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). More detailed.

GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides an Inter Process Communication (IPC) mechanism that the Hurd uses to define interfaces for implementing in a distributed multi-server fashion the services a traditional operating system kernel provides. More detailed.

Joan Lledo modified the PCI arbiter to prevent mapping I/O region files. He previously sent some patches to implement mapping region and ROM files using mmap(). However, a BAR region can represent either memory or I/O space, and only memory should be allowed to be mapped. Since I/O BARs only contain I/O addresses, he went ahead and prevented the mapping of I/O region files. The next step is to make IO spaces available for users through the pci-arbiter. He plans to add a new RPC that checks for permission and calls i386_io_perm_create(). Then it returns the resulting port.

Our Google summer of code student Vedant Tewari decided to port rust, and the rust porting effort is making good progress. The build process is a bit wonky, and Debian is using an older rust version. Check out the rust pull request that adds Hurd support!

Samuel worked on setting up PAE, which will eventually let us use more than 4GB of RAM on a 32-bit Hurd! It is also useful for the X86_64 architecture. He also fixed the jemalloc build.

Samuel was incredibly productive this quarter making the X86_64 bit port more stable. He fixed the 64-bit Hurd PIE build, and he got git working on the 64-bit port! Though a few of the git tests are failing on both X86_64 and the 32 bit port. He fixed the glibc build, which involved fixing pmap_remove and pmap_protect. He discovered that core dumping is currently causing problems on the 64-bit port, and he temporarily encourages people to disable core dumping. Samuel fixed some networking issues and a dpkg issue for the 64-bit port. It was hard to discover what the problem was, because the debugging tools have not been ported to the 64-bit port. He add some helpers to locking to fix some bugs, and he encourages other developers to help him fix the debugging tools for X86-64. It seems that most developers are currently running the 64-bit Hurd in a virtual machine and not in real hardware.

Luca Dariz got a patch series merged for the 64 bit port.

Sergey implemented MAP_EXCL and provided MAP_FIXED_NOREPLACE and MAP_TRYFIXED as aliases of (MAP_FIXED|MAP_EXCL) as well other mmap work. He explains:

MAP_FIXED is defined to silently replace any existing mappings at the address range being mapped over. However, this is dangerous and only rarely desired behavior.

Various Unix systems provide replacements or additions to MAP_FIXED.

• SerenityOS and Linux provide MAP_FIXED_NOREPLACE. If the address space already contains a mapping in the requested range, Linux returns EEXIST. SerenityOS returns ENOMEM, however that is a bug, as the MAP_FIXED_NOREPLACE implementation is intended to be compatible with Linux.

• DragonFly BSD, NetBSD, and OpenBSD provide MAP_TRYFIXED, but with different semantics. DragonFly BSD returns ENOMEM if the requested range already contains existing mappings. NetBSD does not return an error, but instead creates the mapping at a different address if the requested range contains mappings. OpenBSD behaves the same, but also notes that this is the default behavior even without MAP_TRYFIXED (which is the case on the Hurd too).

Since the Hurd leans closer to the BSD side, add MAP_EXCL as the primary API to request the behavior of not replacing existing mappings. Declare MAP_FIXED_NOREPLACE and MAP_TRYFIXED as aliases of (MAP_FIXED|MAP_EXCL), so any existing software that checks for either of those macros will pick them up automatically. For compatibility with Linux, return EEXIST if a mapping already exists.

Damien Zammit added a USB mass storage translator via rumpusbdisk. Though it has some issues as he explains:

Netdde sneems to exhibit a bug when running ifdown /dev/eth0 simultanously to running the rumpusbdisk translator, because to the two devices share the same IRQ.

Damien also worked on the Hurd's SMP support (much of his SMP contributions is based on the earlier work done by Almudena Garcia):

• He tweaked GNU Mach's scheduler, and he merged three GNU Mach commits.

• He added a show all runqs command to GNU Mach's kernel debugger.

• He also improved SMP in GNU Mach by storing the struct processor in a percpu area and avoiding an expensive cpu_number every call of current_processor(), as well as getting the cpu_number from an offset in the percpu area. Further improvements can be made by using other percpu areas. It was untested on 64 bit.

• Damien also taught GNU Mach to use the x86 CPUID instruction to get the CPU ID for speed. He reduced the time it takes to get the CPUID. He made it 100 times faster!

• He mentioned some issues: 60% of the time, booting a 32 bit Hurd, with SMP enabled, fails to boot (sometimes apparently getting stuck in the rumpdisk). When it does boot, it is not particularly stable and likely to crash.

Essentially, the SMP work is progressing, but it is not ready for production use. His recent work made the non-SMP faster, and a 32 bit Hurd, with SMP enabled and only one core, appears relatively stable (but slow to boot). The 32-bit SMP enabled Hurd may soon be as fast as the non-SMP Hurd. Eventually the SMP enabled Hurd will be faster than a non-SMP Hurd.

Flavio Cruz halved the size of mach_msg_type_long_t, from 16 to 8 bytes. He also simplified the overall 64bit RPC ABI, removing "holes" in mach_msg_type_t or mach_msg_type_long_t, which prevents possible leakages to userspace.

Some Hurd people talked to Kent Overstreet, the author of bcachefs to discuss the possibility of porting Linux's newest filesystem to the Hurd; the conversation was recorded. While most Hurd developers believe that it would possible to port bcachefs to the Hurd, all agree that it would be difficult to port and hard to maintain. No Hurd developers are currently planning or working on porting bcachefs to the Hurd. But perhaps you want to?

So if you want to test if your favorite packages work on the Hurd and contribute towards making the full GNU system usable for a wider range of people, please check the contributing page.

The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). More detailed.

GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides an Inter Process Communication (IPC) mechanism that the Hurd uses to define interfaces for implementing in a distributed multi-server fashion the services a traditional operating system kernel provides. More detailed.

It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2023.

This is a snapshot of Debian "sid" at the time of the stable Debian "bookworm" release (June 2023), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release.

Read the announcement email.

The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). More detailed.

GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides an Inter Process Communication (IPC) mechanism that the Hurd uses to define interfaces for implementing in a distributed multi-server fashion the services a traditional operating system kernel provides. More detailed.