Re: [RFC PATCH 00/23] aarch64-gnu port

[Maxim Kuvyrkov]

> On Jan 3, 2024, at 21:14, Sergey Bugaev <bugaevc@gmail.com> wrote:
> 
> Hello!
> 
> This is my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM.
> 
> To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG),
> and GNU Mach headers for AArch64. I have posted the patches for
> binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches
> are required to build aarch64-gnu-mig.
> 
> glibc fully builds and produces all the exepected libraries (including
> libmvec) and binaries. It can then be used to build other programs, in
> particular many core Hurd servers seem to build just fine.
> 
> There is no AArch64 port of GNU Mach yet; I'm trying to get the ball
> rolling by making this port of glibc. I have only added some AArch64
> headers to GNU Mach, but no actual runnable code. My versions of
> <mach/aarch64/exception.h>, <mach/aarch64/thread_status.h> (and others)
> are by no means final, they are more of preliminary sketches of the API
> so I have something to port glibc against. If there are changes
> resulting from discussions and (hopefully) an eventual Mach AArch64
> port, we'll need to make corresponding changes to glibc.
> 
> There not being a Mach build means that it's not currently possible to
> run or test any of this port on a real Mach. It is possible to run
> simple statically linked executables on Linux (or, I guess, other
> kernels which use ELF and similar enough ABI wrt how the arguments are
> placed on the stack) as long as you emulate the syscalls and RPCs in
> some way. I have done that, and verified that simple statically linked
> executables in the bootstrap configuration (i.e. without a Hurd exec
> server, with arguments already placed on the stack by Mach) start up
> fine.
> 
> I have also done a quick i686-gnu build (to see if static-start.S or
> init-first.c changes have broken something), and a statically linked
> hello world seems to still work as expected.
> 
> As usual, the disclaimer about me not knowing what I'm doing: I don't!
> I especially am not at all familiar with AArch64, even less so than with
> x86_64. I could have done something incredibly stupid; please do review!
> 
> That being said, these changes seem smaller and a lot less radical than
> the x86_64 port patchset; they're mostly adding things rather than
> reworking them, so there is less of a chance to break the x86 targets.
> Evidently, we've done enough rewrokings and portability fixes (notably,
> various 64-bit fixes) during the x86_64 port to make it easier to add
> new ports. This port itself continues this trend somewhat too, with
> init-first.c now finally becoming only sysdeps/mach/hurd -specific, and
> HTL gaining support for TLS_DTV_AT_TP.
> 
> As I said in the previous letter on bug-hurd, the hardware hardening
> features (BTI, MTE, PAC) are currently "not really supported", but I do
> want to support them in the future. I'm extremely interested in getting
> feedback or suggestions about these. For example: what should our API
> for controlling PAC keys look like, should we just allow userland to
> read and write all the keys? Are there, for example, any gotchas with
> BTI that we need to be aware of? Is it possible to start using PAC after
> initial start-up (once /dev/random becomes available, so PAC keys can be
> initialized) — how would we do that without crashing on e.g. ret
> pointers that have not been encrypted?
> 
> Finally, a couple of words about the page size. My plan is for userland
> to not assume any static value of page size, and always query it
> dynamically, unlike on x86, even though GNU Mach will likely be compiled
> with some fixed value of page size; my understanding is this is also how
> things are done on GNU/Linux. To that end, I've tried to reduce the
> reliance on <mach/vm_param.h> and on EXEC_PAGESIZE being defined.
> Currently, Mach headers still define *something* named PAGE_SIZE
> unconditionally, causing __mach_init () to pick it up and use it instead
> of querying the page size dynamically. We should make sure this does not
> happen (i.e. <mach/vm_param.h> should not define PAGE_SIZE on AArch64),
> this is just something I haven't figured out a nice way to fix yet.
> 
> Sergey
> 
> P.S. I have not forgotten about my other unmerged patch series! (Most
> importantly, O_IGNORE_CTTY everywhere and the fcntl fortification.) I
> hope to find some time to hack on them, hopefully some time soon.
> 
> Sergey Bugaev (23):
>  hurd: Add some missing includes
>  hurd: Declare _hurd_intr_rpc_msg* with protected visibility
>  Allow glibc to be compiled without EXEC_PAGESIZE
>  mach: Drop some unnecessary vm_param.h includes
>  hurd: Disable Prefer_MAP_32BIT_EXEC on non-x86_64 for now
>  mach: Drop SNARF_ARGS macro
>  hurd: Pass the data pointer to _hurd_stack_setup explicitly
>  hurd: Drop x86-specific assembly from init-first.c
>  hurd: Make init-first.c no longer x86-specific
>  hurd: Only init early static TLS if it's used to store stack or
>    pointer guards
>  hurd: Initializy _dl_pagesize early in static builds
>  aarch64: Make cpu-features definitions not Linux-specific
>  aarch64: Add dl-procinfo
>  aarch64: Allow building without kernel support for BTI
>  mach: Add a basic AArch64 port
>  hurd: Add a basic AArch64 port
>  hurd: Implement TLS on AArch64
>  hurd: Implement longjmp for AArch64
>  Add FPE_FLTIDO
>  hurd: Add an AArch64 signal implementation
>  htl: Implement some support for TLS_DTV_AT_TP
>  htl: Add an AArch64 implementation
>  hurd: Add expected aarch64-gnu abistlists

Hi Sergey,

Would you please update and re-post your patch series, so that reviewers can 
check that it doesn't break existing targets?  We (Linaro) had our pre-commit 
CI down in late December / early January, so most of your patches weren't 
tested, see [1].

[1] https://patchwork.sourceware.org/project/glibc/list/?series=29086

Thank you,

--
Maxim Kuvyrkov
https://www.linaro.org