[PATCH] open_issues/arm_port.mdwn: documented Sergeys AArch64 port status.
I figure that we might as well document the AArch64 port status on the wiki. --- open_issues/arm_port.mdwn | 172 +- 1 file changed, 134 insertions(+), 38 deletions(-) diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn index 26e0b770..8a2bc27f 100644 --- a/open_issues/arm_port.mdwn +++ b/open_issues/arm_port.mdwn @@ -9,56 +9,152 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -Several people have expressed interested in a port of GNU/Hurd for the ARM -architecture. +Several people have expressed interested in a port of GNU/Hurd for the +ARM architecture. Luckily a userspace port of the Hurd servers and +glibc is underway. As early as January 1, 2024 an AArch64 port is +making some progress. Sergey did some hacking on glibc, binutils, +GCC, and added some headers to GNU Mach. He was able to build the +core Hurd servers: ext2fs, proc, exec, and auth. +One would think that he would need to port GNU Mach to run the +binaries, but Sergey ran a statically linked hello world executable on +GNU/Linux, under GDB, being careful to skip over and emulate syscalls +and RPCs. The glibc port has the TLS setup, hwcaps / cpu-features, +and ifuncs. -# IRC, freenode, #hurd, 2012-07-28 +Now to some of the more technical things: - Has anyone heard about porting hurd and gnu/mach to arm - architecture? - mcsim: i think so - mcsim: why are you asking ? - I found an article where author stated that he has ported hurd to - arm, but I have never met this information before. - He wrote ethernet driver and managed to use ping command - author's name is Sartakov Vasily - well that's possible, a long time ago - and it was probably not complete enough to be merged upstream - like many other attempts at many other things - Not so long. Article is dated by June 2011. - do you have a link ? - Yes, but it is in Russian. - oh - well i don't remember him sharing that with us - mcsim: he did some work on porting Mach, but AIUI never got it - nearly finished - nowadays he does L4 stuff - was also at FOSDEM +- The TLS implementation is basically complete and working. We're +using `tpidr_el0` for the thread pointer (as can be seen in the listing +above), like GNU/Linux and unlike Windows (which uses x18, apparently) +and macOS (which uses `tpidrro_el0`). We're using "Variant I" layout, as +described in "ELF Handling for Thread-Local Storage", again same as +GNU/Linux, and unlike what we do on both x86 targets. This actually +ends up being simpler than what we had for x86! The other cool thing +is that we can do `msr tpidr_el0, x0` from userspace without any +gnumach involvement, so that part of the implementation is quite a bit +simpler too. +- Conversely, while on x86 it is possible to perform "cpuid" and +identify CPU features entirely in user space, on AArch64 this requires +access to some EL1-only registers. On Linux and the BSDs, the kernel +exposes info about the CPU features via `AT_HWCAP` (and more recently, +`AT_HWCAP2`) auxval entries. Moreover, Linux allows userland to read +some otherwise EL1-only registers (notably for us, `midr_el1`) by +catching the trap that results from the EL0 code trying to do that, +and emulating its effect. Also, Linux exposes `midr_el1` and +`revidr_el1` values through procfs. -## IRC, freenode, #hurd, 2012-10-09 +- The Hurd does not use `auxval`, nor is gnumach involved in `execve` anyway. +So I thought the natural way to expose this info would be with an RPC, +and so in `mach_aarch64.defs` I have an `aarch64_get_hwcaps` routine that +returns the two hwcaps values (using the same bits as `AT_HWCAP{,2}`) and +the values of `midr_el1`/`revidr_el1`. This is hooked to `init_cpu_features` +in glibc, and used to initialize `GLRO(dl_hwcap)` / `GLRO(dl_hwcap2)` and +eventually to pick the appropriate ifunc implementations. - bootinfdsds: There was an unfinished port to arm, if you're - interested. - mcsim: Has that ever been published? - tschwinge: I don't think so. But I have an email of that person and - I think that this could be discussed with him. +- The page size (or rather, paging granularity) is notoriously not +necessarily 4096 on ARM, and the best practice is for userland not to +assume any specific page size and always query it dynamically. GNU +Mach will (probably) have to be built support for some specific page +size, but I've cleaned up a few places in glibc where things were +relying on a statically defined page size. +- There are a number of hardware hardening features available on AArch64 +(PAC, BTI, MTE — why do people keep adding more and more workarounds, +including hardware ones, instead of rewriting software in a properly +memory-safe language...). Those are not really supported right now; all
Re: [PATCH] open_issues/arm_port.mdwn: documented Sergeys AArch64 port status.
Applied, thanks! jbra...@dismail.de, le mar. 09 janv. 2024 15:20:47 -0500, a ecrit: > I figure that we might as well document the AArch64 port status on the wiki. > > --- > open_issues/arm_port.mdwn | 172 +- > 1 file changed, 134 insertions(+), 38 deletions(-) > > diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn > index 26e0b770..8a2bc27f 100644 > --- a/open_issues/arm_port.mdwn > +++ b/open_issues/arm_port.mdwn > @@ -9,56 +9,152 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. > A copy of the license > is included in the section entitled [[GNU Free Documentation > License|/fdl]]."]]"""]] > > -Several people have expressed interested in a port of GNU/Hurd for the ARM > -architecture. > +Several people have expressed interested in a port of GNU/Hurd for the > +ARM architecture. Luckily a userspace port of the Hurd servers and > +glibc is underway. As early as January 1, 2024 an AArch64 port is > +making some progress. Sergey did some hacking on glibc, binutils, > +GCC, and added some headers to GNU Mach. He was able to build the > +core Hurd servers: ext2fs, proc, exec, and auth. > > +One would think that he would need to port GNU Mach to run the > +binaries, but Sergey ran a statically linked hello world executable on > +GNU/Linux, under GDB, being careful to skip over and emulate syscalls > +and RPCs. The glibc port has the TLS setup, hwcaps / cpu-features, > +and ifuncs. > > -# IRC, freenode, #hurd, 2012-07-28 > +Now to some of the more technical things: > > - Has anyone heard about porting hurd and gnu/mach to arm > - architecture? > - mcsim: i think so > - mcsim: why are you asking ? > - I found an article where author stated that he has ported hurd to > - arm, but I have never met this information before. > - He wrote ethernet driver and managed to use ping command > - author's name is Sartakov Vasily > - well that's possible, a long time ago > - and it was probably not complete enough to be merged upstream > - like many other attempts at many other things > - Not so long. Article is dated by June 2011. > - do you have a link ? > - Yes, but it is in Russian. > - oh > - well i don't remember him sharing that with us > - mcsim: he did some work on porting Mach, but AIUI never got it > - nearly finished > - nowadays he does L4 stuff > - was also at FOSDEM > +- The TLS implementation is basically complete and working. We're > +using `tpidr_el0` for the thread pointer (as can be seen in the listing > +above), like GNU/Linux and unlike Windows (which uses x18, apparently) > +and macOS (which uses `tpidrro_el0`). We're using "Variant I" layout, as > +described in "ELF Handling for Thread-Local Storage", again same as > +GNU/Linux, and unlike what we do on both x86 targets. This actually > +ends up being simpler than what we had for x86! The other cool thing > +is that we can do `msr tpidr_el0, x0` from userspace without any > +gnumach involvement, so that part of the implementation is quite a bit > +simpler too. > > +- Conversely, while on x86 it is possible to perform "cpuid" and > +identify CPU features entirely in user space, on AArch64 this requires > +access to some EL1-only registers. On Linux and the BSDs, the kernel > +exposes info about the CPU features via `AT_HWCAP` (and more recently, > +`AT_HWCAP2`) auxval entries. Moreover, Linux allows userland to read > +some otherwise EL1-only registers (notably for us, `midr_el1`) by > +catching the trap that results from the EL0 code trying to do that, > +and emulating its effect. Also, Linux exposes `midr_el1` and > +`revidr_el1` values through procfs. > > -## IRC, freenode, #hurd, 2012-10-09 > +- The Hurd does not use `auxval`, nor is gnumach involved in `execve` anyway. > +So I thought the natural way to expose this info would be with an RPC, > +and so in `mach_aarch64.defs` I have an `aarch64_get_hwcaps` routine that > +returns the two hwcaps values (using the same bits as `AT_HWCAP{,2}`) and > +the values of `midr_el1`/`revidr_el1`. This is hooked to `init_cpu_features` > +in glibc, and used to initialize `GLRO(dl_hwcap)` / `GLRO(dl_hwcap2)` and > +eventually to pick the appropriate ifunc implementations. > > - bootinfdsds: There was an unfinished port to arm, if you're > - interested. > - mcsim: Has that ever been published? > - tschwinge: I don't think so. But I have an email of that person > and > - I think that this could be discussed with him. > +- The page size (or rather, paging granularity) is notoriously not > +necessarily 4096 on ARM, and the best practice is for userland not to > +assume any specific page size and always query it dynamically. GNU > +Mach will (probably) have to be built support for some specific page > +size, but I've cleaned up a few places in glibc where things were > +relying on a statically defined page size. > > +- There