[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: aarch64-gnu (and Happy New Year!)
From: |
Sergey Bugaev |
Subject: |
Re: aarch64-gnu (and Happy New Year!) |
Date: |
Tue, 2 Jan 2024 00:04:24 +0300 |
On Mon, Jan 1, 2024 at 10:21 PM Luca <luca@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