From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id EE4601F44D for ; Sat, 23 Mar 2024 17:35:33 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=TrvjCD04; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 23B0B3858430 for ; Sat, 23 Mar 2024 17:35:32 +0000 (GMT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id 037293858D33 for ; Sat, 23 Mar 2024 17:35:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 037293858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 037293858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711215308; cv=none; b=ObiUXeYbRWMgTcXNrfdAr9bW6hMzF7exnwsVmRSzNxOwZYzvr7Nqaw35gaeWgXDhhLzCwcXgmLmr2JzW6C1FpbeBGSt5PaGsdJ6uOTMRxGNhFF6L1HqCo15aN3cylAS5HMppQ8M2dIZLoUzwFd8Wo/LAMCxpnu0Jun/IaGYFZlE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711215308; c=relaxed/simple; bh=Xqdv7C8p/Bm7WOh7piQMMEZBsij93RtjELCHvoIF0yc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=lc+g10f9mEGkvyitRB/LIllbAzi78A+KhtbKJXUjBeoTRAU0T7YOHX2z7Tk6jYvvWuJgqBstDDbt29fjal+AVCuvlx1Lb0btWzpM9wGLbo5gmIRt9WaDw6MjjJ3toO/vgKtjbSwxqsLiyBeGHIVaCQ25nzLij24B7eCxljnjsYA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-514ba4e5640so3849625e87.1 for ; Sat, 23 Mar 2024 10:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711215304; x=1711820104; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=SY5L6xCV6AU/ajVHcWVdjP4W3dP5MuLdmsKI2e3dli8=; b=TrvjCD04HPqZz0x17e32MpR6t9YwgqbHaYejFCQDtPUtgUnWTJ2i3JeECc1iV5U9VT 2rezkRMOk0ab6o8IivkN8QyKbx7wgUaWfwFsXGZzetor3oywVM1Oxb/Qaw0IaU9gvckh XIgx4skzEWZnVvhA3jKK+6fKn1/95zVAGirP98kXscJ4bT0OT0V3Y90HkIP3dUz2nzPw fleK4bCgbEPB6g0yj1KtEfyH3kRz+7Gfux6/hKiroFGhTBPRqfg84dQV1VwEMPHU2/QS 2KiPB+mJacdKKf7RsZ8br2ZHyYi5aDtD+oc0OAd9hjtIXkjCdu9d81cMCCl0bZkEfT39 RlwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711215304; x=1711820104; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SY5L6xCV6AU/ajVHcWVdjP4W3dP5MuLdmsKI2e3dli8=; b=uHtkbobka+o1rddr9MCSwEsR07FsuTPyoTPD9p+80OCMwcyksrBeSucGTLIc7zZm3+ TooD38zCUecqxn4N2TdlV4fDgxt/TKLaDEki9kK9+StI+U5BuW03mHfL1dnwYTq407co zqPhqDUPVwh5xFBiw+7meye76RFzP1pYky114CrMVepqSe1ubft/rBGIgLqmk5FLUmVu 0zPRUzN4xUdAJriD+5L46hVS02DwL7SlzslBC7dN55Bcw6BZx1b9U8HpD+o1l03rLnfz OzYj3Lj1I0EZDBZMwJ3WLL7dlH2GuZrjZJKk9bKKsXQM2b/ybKfdibPmz+qWpvv8/HHx CNuA== X-Gm-Message-State: AOJu0Yw7yRgyaBYfT+CGYx4a4a4Oa72Jv2d6VtEr9ol9T2QrT8SEhYc+ wj+W4auOP3orI+hU/9hvj0xzyjOuZFGXGKclbVOLKFkS4Bg5NZbAGbGS+oaD X-Google-Smtp-Source: AGHT+IG+ywNY3YXwcNKxYUpjintQqr8voJMnhKEBMfZjiCJHq+ydhS6PU/+jd2uIr7C6YaburuRJMw== X-Received: by 2002:ac2:5b11:0:b0:515:9f68:bff7 with SMTP id v17-20020ac25b11000000b005159f68bff7mr709374lfn.0.1711215303805; Sat, 23 Mar 2024 10:35:03 -0700 (PDT) Received: from surface-pro-6.. (79-139-171-253.dynamic.spd-mgts.ru. [79.139.171.253]) by smtp.gmail.com with ESMTPSA id g20-20020ac25394000000b00513973dee6fsm361290lfh.150.2024.03.23.10.35.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Mar 2024 10:35:03 -0700 (PDT) From: Sergey Bugaev To: libc-alpha@sourceware.org, bug-hurd@gnu.org Cc: Maxim Kuvyrkov , Luca Subject: [PATCH v2 00/20] aarch64-gnu port & GNU/Hurd on AArch64 progress Date: Sat, 23 Mar 2024 20:32:41 +0300 Message-ID: <20240323173301.151066-1-bugaevc@gmail.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Hello! This is v2 of my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM. v1 is here [0]. [0]: https://sourceware.org/pipermail/libc-alpha/2024-January/153675.html Last time, Joseph Myers has pointed out that the aarch64-gnu port can not be merged into glibc until aarch64-gnu support is upstream in all of glibc's build-time dependencies. That is still not the case, so this patchset can not be merged yet; but otherwise it should be in a fairly mergeable state. It does not yet anything to NEWS or build-many-glibcs.py, though. I'm porting this, again, to gather some feedback (hopefully more than last time...), and at Maxim's request, so Linaro can test this on their CI and ensure this doesn't break existing ports. The upstreaming status of various aarch64-gnu components is, specifically: * Binutils patch to add the aarch64-gnu target is upstream and in the 2.42 release; * GCC patches to add aarch64-gnu target (& libgcc host) have been reviewed by ARM and Hurd port maintainers and should land upstream very soon; * initial Hurd patches are upstream; * glibc patches (this patchset) are not yet upstream; * GNU Mach changes are not upstream, and upstreaming story is unclear; * GNU MIG needs no changes, it just works. Last time, there was no AArch64 port of GNU Mach, and so the only testing I have done was running a simple statically-linked executable on Linux under GDB -- which, nevertheless, helped me identify and fix a number of issues. Since then, however, I have been (some may say, relentlessly) working on filling in the missing piece, namely porting gnumach (with important help & contributions by Luca D.). I am happy to report that we now have an experimental port of gnumach that builds and works on AArch64! While that may sound impressive, note that various things about it are in an extremely basic, proof-of-concept state rather than being seriously production-ready; and also that Mach is a small kernel (indeed, a microkernel), and it was designed from the start (back in the 80s) to be portable, so most of the "buisness logic" functionality (virtual memory, IPC, tasks/threads/scheduler) is explicitly arch-independent. Despite the scary "WIP proof-of-concept" status, there is enough functionality in Mach to run userland code, handle exceptions and syscalls, interact with the MMU to implement all the expected virtual memory semantics, schedule/switch tasks and threads, and so on. Moreover, all of gnumach's userspace self-tests pass! This meant there was enough things in place for me to try running glibc on it, and the amazing thing is my simple test executable, the same one I previously tested on Linux w/ GDB, just worked on real Mach without me having to make any additional changes to the glibc side, or even recompile it. But I did not stop there, and got several of the core Hurd servers working! Namely, these are ext2fs, exec, startup, auth, and proc servers. All of them but ext2fs are dynamically linked; ld-aarch64.so.1 sucessfully locates and maps the programs themselves and their required dependencies, and Mach pages in code and data pages from ext2fs as they are accessed, transparently to the program, just as one would expect it to. It turned out that Mach on i386 and x86_64 did not enforce the (lack of) execute permission on pages, i.e. even pages mapped without VM_PROT_EXECUTE were executable in practice. This caused a number of bugs related to mapping executable stacks to go unnoticed, there were issues in all of Mach, glibc, and the Hurd's exec server related to not creating executable stacks as actually executable. As I implemented the execute permission properly in Mach on AArch64 (indeed, I even support execute-only pages when the hardware implements FEAT_EPAN), I have encountered all of those oversights one by one when trying to run progressively more code, and have hopefully fixed them all. Hopefully we'll stop requiring executable stacks for glibc and Hurd libraries some time, and then we'll get working non-executable stacks on AArch64. As expected, I have done some tweaks to the AArch64-specific Mach APIs (primarily thread state and exception code definitions) compared to the "preliminary sketches" of them that I posted in January, but they were actually rather small. I've got some more confidence in the APIs now after having implemented support for them from both sides now, and having tested that it works in practice. No more backwards-incompatible changes to AArch64-specific Mach APIs are expected (by me anyway); we'll definetely want to add more things later (aarch64_debug_state for GDB, PAC RPCs, and more), but those should be purely additive. I have added a new Mach syscall (trap), thread_set_self_state (), to implement sigreturn () on top of. I have originally hoped that it would be possible to use the regular thread_set_state (mach_thread_self ()) call for it (special-casing it on AArch64 to allow setting the calling thread's state), and indeed have initially implemented that on the Mach side. I have then realized that this would cause a number of annoying issues (there are good reasons why Mach doesn't allow one to call thread_set_state () on the calling thread) that can be elegantly avoided by making it into a dedicated syscall that is explicitly not an RPC. Please see the explanation in the gnumach patch adding the syscall for a more detailed explanation -- once I write that explanation and post that patch, that is. The new syscall (same as the potential RPC version of it), however, is a security concern, much like sigreturn is in general: it makes it feasible for attackers to use sigreturn-oriented programming (SROP) tricks. Linux has, allegedly, mitigated SROP by placing a magic cookie on the user stack next to (or inside) sigcontext, and later verifying it in sigreturn () -- although I failed to find the code responsible for implementing that in the Linux source tree, at least not in AArch64- specific signal implementation. In any case, this approach is not feasible for Mach, since Mach is not involved in placing the sigcontext (nor the thread state structure) on user's stack. Suggestions on what to do about this (including convincing me that this is OK and we don't have to do anything about it, given that we have executable stacks...) are very welcome. But security concerns notwithstanding, I managed to test the signal handling code path in practice, and it does work! (Indeed, it just worked on the first try; somehow I got everything right.) The signal- raising RPC gets received by the signal thread, the target thread aborted inside _hurd_intr_rpc_mach_msg (), its state fetched and modified to jump to the signal trampoline, then resumed; from the trampoline, it calls the user's handler as expected, and then calls sigreturn (), which uses thread_set_self_state (), resetting itself to continue right from where it got interrupted, and continues from there; it all works! Besides core Hurd servers, I have tested a simple Unix program running as PID 1 on the resulting system (with a proc port and a singal thread, as described above, and all the other state). Among the things I tested is fork () + wait (), and (with the latest fixes on the gnumach side) this now totally works as well. Sergey