mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: "A. Wilcox" <AWilcox@Wilcox-Tech.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Invalid page size reference in __dls2
Date: Wed, 30 Nov 2022 19:09:42 -0500	[thread overview]
Message-ID: <20221201000941.GS29905@brightrain.aerifal.cx> (raw)
In-Reply-To: <FEE937EF-2C2C-4100-BD6C-06A8CCE31878@Wilcox-Tech.com>

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Wed, Nov 30, 2022 at 05:28:38PM -0600, A. Wilcox wrote:
> 
> On Nov 30, 2022, at 9:12 AM, Rich Felker <dalias@libc.org> wrote:
> > 
> > Nice catch. The references to libc are not valid in __dls2. If they
> > were, I would just re-run kernel_mapped_dso() from __dls2b or
> > something to get the right relro map, but I think instead we should do
> > something like the attached.
> > 
> > Rich
> > <ldso_page_size.diff>
> 
> LGTM but needs a # before the ‘define’.
> 
> This explains a weird error I was seeing with gcompat on aarch64.

Does this look better (message included)?


[-- Attachment #2: 0001-ldso-fix-invalid-early-references-to-extern-linkage-.patch --]
[-- Type: text/plain, Size: 2218 bytes --]

From f47a8cdd250d9163fcfb39bf4e9d813957c0b187 Mon Sep 17 00:00:00 2001
From: Rich Felker <dalias@aerifal.cx>
Date: Wed, 30 Nov 2022 18:59:08 -0500
Subject: [PATCH] ldso: fix invalid early references to extern-linkage
 libc.page_size

when PAGE_SIZE is not constant, internal/libc.h defines it to expand
to libc.page_size. however, kernel_mapped_dso, reachable from stage 2
of the dynamic linker bootstrap (__dls2), needs PAGE_SIZE to interpret
the relro range. at this point the libc object is both uninitialized
and invalid to access according to our model for bootstrapping, which
does not assume any external-linkage objects are accessible until
stages 2b/3. in practice it likely worked because hidden visibility
tends to behave like internal linkage, but this is not a property that
the dynamic linker was designed to rely upon.

this bug likely manifested as relro malfunction on archs with variable
page size, due to incorrect mask when aligning the relro bounds to
page boundaries.

while there are certainly more direct ways to fix the known problem
point here, a maximally future-proof way is to just bypass the libc.h
PAGE_SIZE definition in the dynamic linker and instead have dynlink.c
define its own internal-linkage object for variable page size. then,
if anything else in stage 2 ever ends up referencing PAGE_SIZE, it
will just automatically work right.
---
 ldso/dynlink.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/ldso/dynlink.c b/ldso/dynlink.c
index 8068fb37..09f3b0a8 100644
--- a/ldso/dynlink.c
+++ b/ldso/dynlink.c
@@ -21,9 +21,15 @@
 #include <sys/membarrier.h>
 #include "pthread_impl.h"
 #include "fork_impl.h"
-#include "libc.h"
 #include "dynlink.h"
 
+static size_t ldso_page_size;
+#ifndef PAGE_SIZE
+#define PAGE_SIZE ldso_page_size
+#endif
+
+#include "libc.h"
+
 #define malloc __libc_malloc
 #define calloc __libc_calloc
 #define realloc __libc_realloc
@@ -1723,6 +1729,7 @@ hidden void __dls2(unsigned char *base, size_t *sp)
 	ldso.phnum = ehdr->e_phnum;
 	ldso.phdr = laddr(&ldso, ehdr->e_phoff);
 	ldso.phentsize = ehdr->e_phentsize;
+	search_vec(auxv, &ldso_page_size, AT_PAGESZ);
 	kernel_mapped_dso(&ldso);
 	decode_dyn(&ldso);
 
-- 
2.21.0


  reply	other threads:[~2022-12-01  0:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 19:47 Markus Wichmann
2022-11-30 15:12 ` Rich Felker
2022-11-30 23:28   ` A. Wilcox
2022-12-01  0:09     ` Rich Felker [this message]
2022-12-01  0:19       ` A. Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221201000941.GS29905@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=AWilcox@Wilcox-Tech.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).