From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 3D97E23F18 for ; Thu, 29 Feb 2024 17:25:37 +0100 (CET) Received: (qmail 5972 invoked by uid 550); 29 Feb 2024 16:21:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5937 invoked from network); 29 Feb 2024 16:21:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709223924; x=1709828724; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=r0+7qsJMePVw5v9UllhSIe9COUUzGaMVl1neF/rQk6M=; b=N56f7bnbf3kbkBpnQxYVz+Luj70X4l0qNj30ZAhHOQad5rB90QrE8m9/sN0hqGZEim qKOMqRcB0FIsYWn+X8QhAiE4Qk2e1Xq13KX41BZab6+5xMZh6HURqVDWKNvtFh/zlFjb l3RFw+nZ5bEDIZrQHPf1GEAE+qwZVOUntz7JxVIaPep4CBezIV0PMJRSSSwTMBXr4/4N aiOivfNkq8KklsRBx2w941QsNWAJfbQ1o3DBqbS/ji/xzxojpjwn7yUI9KjHmiDEvAfa E9MnVmgdd617LUck9iyVJ5+wDaYNilop22Qm73UwxDgd6d/Xtt95GtqBxnMyel4t+jiS kPfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709223924; x=1709828724; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=r0+7qsJMePVw5v9UllhSIe9COUUzGaMVl1neF/rQk6M=; b=PAUx1MI8d8DTZNSuwpwcF4HiNh5joSvzzmZOAtj7o/ZCwkvqZzkQS4j6ZQA95M4gcS z2MEUQ3WetiJUxgYGcnyLM5TcvW8caul5K8IjvrtqRzhM6SqJk1z/cqngXBOvLRG7+NY rHK+5r4NTlYJwxulHD9yZJKy4spECQT7gYDsFy3KiZ6S4MrHMKa7UwN4AEiQwdbEb3zC tUMbVEy3wlHN7TYlJFp3WIfAKf3bxf5aCCRhyqmGAPxPORGA97+j80iyL5kk/QwkP9Rr 2htWgWKOFybgglMynNC09Ytsemkm59uC+nGm6Xnjt8+YQK7HhxD8OgSCpX3SMIysKDtQ KXiA== X-Gm-Message-State: AOJu0Yw51f4xUivLN1M/GOI+Ea1y9hso/f+kwkaCz0NZbJ9KYWjbl0zK Omcd8Xsl6bqhYZQ9chQ5JDxwsSt7AcAOzXJNOgAa+s0+XJDAX5tWPGARLBxXh0VdmOlTaNNH34u 6ZHa8UA+puEyXwU88psQe2CSFAU4= X-Google-Smtp-Source: AGHT+IHDlbButaX0c1yIQ8X3/GKS2yqzyCyjoglFkOtjPi7kwDftEBUmL9PoIMgsFVdSiek49T1hq9FD9Kkm4iJ1xUc= X-Received: by 2002:a17:90b:883:b0:29a:da46:8d27 with SMTP id bj3-20020a17090b088300b0029ada468d27mr3058371pjb.0.1709223923549; Thu, 29 Feb 2024 08:25:23 -0800 (PST) MIME-Version: 1.0 References: <20240227232430.GM4163@brightrain.aerifal.cx> <20240228001303.GN4163@brightrain.aerifal.cx> <20240228183032.GO4163@brightrain.aerifal.cx> In-Reply-To: <20240228183032.GO4163@brightrain.aerifal.cx> From: Max Filippov Date: Thu, 29 Feb 2024 08:25:12 -0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Initial xtensa/fdpic port review On Wed, Feb 28, 2024 at 10:30=E2=80=AFAM Rich Felker wrot= e: > On Wed, Feb 28, 2024 at 09:20:33AM -0800, Max Filippov wrote: > > > > diff --git a/ldso/dynlink.c b/ldso/dynlink.c > > > > index ceca3c98..25563af3 100644 > > > > --- a/ldso/dynlink.c > > > > +++ b/ldso/dynlink.c > > > > @@ -1420,6 +1420,7 @@ static void reloc_all(struct dso *p) > > > > if (!DL_FDPIC) > > > > do_relr_relocs(p, laddr(p, dyn[DT_RELR]), dyn= [DT_RELRSZ]); > > > > > > > > +#if 0 > > > > if (head !=3D &ldso && p->relro_start !=3D p->relro_e= nd) { > > > > long ret =3D __syscall(SYS_mprotect, laddr(p,= p->relro_start), > > > > p->relro_end-p->relro_start, PROT_REA= D); > > > > @@ -1429,6 +1430,7 @@ static void reloc_all(struct dso *p) > > > > if (runtime) longjmp(*rtld_fail, 1); > > > > } > > > > } > > > > +#endif > > > > > > Was this breaking something? Relro linking probably should have been > > > disabled on fdpic, and we ignore ENOSYS anyway for nommu. > > > > Yeah, I do some of the testing in linux-user QEMU, it has MMU > > and mprotect calls actually succeed. Failures were coming from the > > relocation code, but my impression was that relro should be applied > > after the relocation completion and it should just work, hence the > > WIP pile. > > Yes, relro is only supposed to be applied after all relocations were > done. So I've found two issues with this. First is that loadmap entries generated by the QEMU (and by the linux kernel AFAICS) are not page-aligned, but the relro segment addresses fetched by the loader are. Since the laddr() doesn't check that a translation for the address it was given was actually found the results are not always correct, mprotect fails and it all terminates early. With a workaround for that part in place I see that relro protection is applied to the executable image before its __fdpic_fixup had a chance to run, there are rofixups for the .init_array and .fini_array, but they bo= th are a part of the relro segment. --=20 Thanks. -- Max