On Mon, Jan 1, 2024 at 10:21 PM Luca <l...@orpolo.org> wrote: > > MIG seems to just work (thanks to all the 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. > > Good to hear! so if I understand it correctly you tested it on aarch64 > GNU/Linux?
(Non-GNU) Linux on aarch64, yes. More specifically, this is a phone running postmarketOS. I've run gdbserver on it, and connected GDB to it over SSH. > >> I actually have an armv8 server that would be handy for some > >> development, so I might be able to help with something in the future. > > > > Sounds great! (But you should also be able to use qemu, no?) > > You can emulate aarch64 from an amd64 machine, but it's not very > efficient. Also, I would realay like to run GNU/Hurd natively :) Eventually, sure; my point is you don't even need real hardware for starting to hack on aarch64 gnumach. > Do you mean Pointer Authentication Code? That seems quite a new feature, > so maybe not fundamental to have a first working kernel, but anyway I > don't see issues in having arch-specific data in tasks. Yes. Certainly not fundamental for an initial port; none of these hardening features are. But it also would be very nice to have support for eventually. Since the Hurd's code has seen a lot less scrutiny than that of Linux, it's likely much easier to find vulnerabilities caused by memory unsafety — I wouldn't be surprised if pfinet contains known old CVEs, for one thing. So hardening is even more relevant for us, if we want people to consider running GNU/Hurd on network-facing servers more seriously. Sergey
