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=2.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no 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 5B2451F44D for ; Mon, 11 Mar 2024 14:15:28 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=gQirmoX3; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8D4B4385841E for ; Mon, 11 Mar 2024 14:15:27 +0000 (GMT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id ACE603858D20 for ; Mon, 11 Mar 2024 14:15:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ACE603858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ACE603858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::629 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710166507; cv=none; b=sBOCBJoPakcG2+FKYY6oxwWmNG5oo1AjDubFlGu6czDwaXQOOrm/jzd614F9T6xG6WWXKlpOVGRxAEla5NGO7Wmo53A6EZfHGCZGHkeZ1AIqRm1YxvUo3KLgIp8JQh4CvNVuqUkZuc3wFf3/Ip1XUbnvWF8GcV9fIBeaSATBm6Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710166507; c=relaxed/simple; bh=oJoH1bvd+C8/e92UMSmIJTsSUrMVylaGzPxfpuk7+IM=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=X6qv+AsTpHYD4SvvtpB5Y3IAcmRBpLr7EjKAPo9nbQulq8MjnJxyQhimTDR4/7ywc5eITjALoZPZnJ7kx7ZxpdcTJe9ESMthcpG/iZw1bEMYJUr/WVyHsRRMwJ8pRmlbT6sDZ4BiJ0a0z9mp/ny1xZ2obgT0irJ+umetH4y9UG8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a28cfca3c45so167738566b.1 for ; Mon, 11 Mar 2024 07:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710166503; x=1710771303; darn=sourceware.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fiVBY7y2cI+0SsJcwnGti3EDOePGIk9pHPw0tMOmXhI=; b=gQirmoX3kN/eyCfiOYDaxG/ZDT1OVP8H4Dc1C7JoHUD03JHqcCfUOoBwonJrI6yRja x9qgW+xkW0c1J14uM65fXPSegI5OJ9mRRBy593iGEewnbyE9BKkVpN0sXH/HVKeeguXT O7udOuoiQJKr/IpjwQaFZKTc3N7CMzz3UxvbmYLKSzyoYtPFc42Ry+RKpZZnjl3t2Bwr 1QoISgpsyt0DKLETL4d3TeCw8ErKZKKVmBRGlw2fqco7Qh0gr8Jnq7Vgh6uuDYixSSAR AcXXhEZcVQxyz2tNPVyCtuD0vYoJTipEJP/JldnXTiT0czV+WpCHxDphtA170+jC6O/c aoKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710166503; x=1710771303; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fiVBY7y2cI+0SsJcwnGti3EDOePGIk9pHPw0tMOmXhI=; b=gxtO5HBDQv5E7J8qNpEZAnGgn3aJrA/wAY7LDIxksh0oUmwzI2fzTM4FPtb38pz183 HOdUku/3M83sQE7H6o1i4D1v6J5yNvQCNG7TNhtwRnSwvIPfLvXXMkn2m82+uNvO8U0w 83IR95KSHmfz2Zs2o9WUPpkkdq0KsfKp5PXTDA09o0f5VvkwIIbPEEzrkHqRR1p+3m9n Ay4Ie+G2BtlTtU4ggu5w9EebyoioSpCt58tfOvE9rniE6kUbgm5xSO/FH8TpBQVXhwKc xF2fk7icYeq1+xyw4SZ6xdaqaMfdEGSMdPXEHNlqEADEDZrocTtvca156ZwPBNHDClkF Nvfw== X-Gm-Message-State: AOJu0YwBGb8kOfNDAitMAzpXI9Dy8k/Fep2Im59sy1VlDQ1fFjfHWBgl LuK4QdlIZw0CkB2n4kDIKXJ/4wQYhkG2zXvHtz/jRA+aYEoGxeXXCsdx3m+r7OE0CuW9lxbVtbG m6A== X-Google-Smtp-Source: AGHT+IFfuCre7asHNKvTCu/G2a/vdAkakg/gvagg45E7GiLJWlfeJxQy8XCoU3R1wkxXW9anHqZiAg== X-Received: by 2002:a17:907:7894:b0:a45:b930:b3ed with SMTP id ku20-20020a170907789400b00a45b930b3edmr4266776ejc.3.1710166503263; Mon, 11 Mar 2024 07:15:03 -0700 (PDT) Received: from smtpclient.apple ([37.252.94.180]) by smtp.gmail.com with ESMTPSA id qt28-20020a170906ecfc00b00a45bb14b1a5sm2892183ejb.89.2024.03.11.07.15.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2024 07:15:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: [RFC PATCH 00/23] aarch64-gnu port From: Maxim Kuvyrkov In-Reply-To: <20240103171502.1358371-1-bugaevc@gmail.com> Date: Mon, 11 Mar 2024 18:14:51 +0400 Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org, Adhemerval Zanella Netto , Helmut Grohne Content-Transfer-Encoding: quoted-printable Message-Id: <41F1EBC2-5556-4704-85F5-58B068C8CE59@linaro.org> References: <20240103171502.1358371-1-bugaevc@gmail.com> To: Sergey Bugaev X-Mailer: Apple Mail (2.3774.300.61.1.2) 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 > On Jan 3, 2024, at 21:14, Sergey Bugaev wrote: >=20 > Hello! >=20 > This is my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM. >=20 > 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. >=20 > 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. >=20 > 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 > , (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. >=20 > 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. >=20 > 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. >=20 > 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! >=20 > 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. >=20 > 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) =E2=80=94 how would we do that without crashing on e.g. = ret > pointers that have not been encrypted? >=20 > 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 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. should not define PAGE_SIZE on = AArch64), > this is just something I haven't figured out a nice way to fix yet. >=20 > Sergey >=20 > 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. >=20 > 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=3D29086 Thank you, -- Maxim Kuvyrkov https://www.linaro.org