From: Szabolcs Nagy <nsz@port70.net>
To: Markus Mayer <mmayer@broadcom.com>
Cc: Musl Mailing List <musl@lists.openwall.com>,
Colin Cross <ccross@android.com>, Colin Cross <ccross@google.com>
Subject: Re: [musl] [PATCH 1/1] Ignore incorrect elf architecture libraries
Date: Wed, 9 Oct 2024 12:14:20 +0200 [thread overview]
Message-ID: <20241009101420.GF2724612@port70.net> (raw)
In-Reply-To: <CAGt4E5tVSDAUvwribZftBsePeCkAxV_apJ+n-WR-HgQuvcfVTQ@mail.gmail.com>
* Markus Mayer <mmayer@broadcom.com> [2024-09-26 12:35:52 -0700]:
> Checking the e_flags also sounds very sensible, especially in the
> context of ARM. However, I am not sure if it is feasible. The
> specification says that e_flags are architecture-specific, so
> interpreting and checking the flags would become a per-architecture
> endeavour. That would mean the loader has to know a lot about the
> different architectures and then decide at runtime which check to run.
> Ideally, we would probably need conditional compilation to only build
> in the checks for the architecture in question. Otherwise the code
> gets bloated with routines that will never be called. It sounds rather
> involved and a little messy. Also, there doesn't seem to be a
> precedent for architecture-specific code in the loader.
>
> To get an idea, see [2] for what readelf is getting up to in order to
> parse the ELF flags for ARM. (Spoiler alert, it's over 200 lines of
> code.)
>
> That being said, if there is a non-messy way to implement checks for
> ARM soft- and hard-float, I am all for it.
i don't have a clean solution.
ideally it would be if (mod->e_flags != ldso->e_flags) skip_mod;
on arm we can assume v4 or v5 abi when checking for sf vs hf
specifically, but historically there were flags that don't mean
incompatible dynamic linking abis, and if that happens in the
future then rejecting new binaries based on e_flags would be
more annoying than useful.
only checking the e_flags that we know is abi relevant works
but needs maintenance when new abis are introduced. i guess
this is what the patch should do (likely there aren't too
many targets with flags to check), but it's not ideal.
> [2] https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=binutils/readelf.c;h=0f8dc1b9716ed5c0ba13ececfc012ed59f8ba270;hb=HEAD#l3511
prev parent reply other threads:[~2024-10-09 10:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-05 21:12 [musl] [PATCH 0/1] " Markus Mayer
2024-07-05 21:12 ` [musl] [PATCH 1/1] " Markus Mayer
2024-07-23 21:08 ` Szabolcs Nagy
2024-07-23 22:53 ` Rich Felker
2024-09-26 19:35 ` Markus Mayer
2024-10-09 10:14 ` Szabolcs Nagy [this message]
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=20241009101420.GF2724612@port70.net \
--to=nsz@port70.net \
--cc=ccross@android.com \
--cc=ccross@google.com \
--cc=mmayer@broadcom.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).