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.
>
> +-
[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
