[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241009101420.GF2724612@port70.net>
Date: Wed, 9 Oct 2024 12:14:20 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Markus Mayer <mmayer@...adcom.com>
Cc: Musl Mailing List <musl@...ts.openwall.com>,
Colin Cross <ccross@...roid.com>, Colin Cross <ccross@...gle.com>
Subject: Re: [PATCH 1/1] Ignore incorrect elf architecture libraries
* Markus Mayer <mmayer@...adcom.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
