[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 25 Sep 2020 16:13:19 -0400
From: Dominic Chen <d.c.ddcc@...il.com>
To: musl@...ts.openwall.com
Subject: Re: SIGSEGV with TEXTREL
On 9/25/2020 2:58 PM, Rich Felker wrote:
> On the other hand, there's no compelling reason to support textrels in
> the main program since the main program can just be linked as non-PIE
> if you have object files (e.g. due to asm source files or static
> libraries you don't have source to) that are not PIC-compatible.
I'm actually comparing the overheads of various security mechanisms, so
I need to build with PIC and RELRO/BIND_NOW for ASLR.
On 9/25/2020 5:37 AM, Szabolcs Nagy wrote:
> there are no existing libcs that fully support textrels
> (since for that not just dynamic relocs but static relocs
> need to be supported too).
I only need TEXTREL support for dynamic relocations, so static
relocations aren't an issue.
> glibc only supports a small set of textrels and of course
> it has to mark the code executable+writable which means
> (1) the code cannot be shared across processes, it will
> actually use physical memory where the modified code is
> stored per process which is not ideal when you work with
> large code model, (2) all security policies have to be
> turned off that prevent exec+write mappings for this to
> work at all which is not acceptable in many environments.
I don't see how (2) applies. Both glibc and the previous patch only
remap text segments writable during relocation processing, and then
remap them back read-only immediately afterwards. If you're referring to
W^X, text segments don't need to be executable during relocation
processing either, so that can be avoided.
> for these reasons it is considered to be a bug to create
> binaries with textrels. i think large code model should
> not need textrel on x86_64: there should be a way to
> create >4G pc relative offset in code that does not need
> any relocs. (or do you have some example where that fails?)
Before D47211 (Clang/LLVM 7.0.0), PIC with the medium or large code
models is unsupported, and the compiler will silently ignore the PIC flag.
> dynamic linker failure diagnostic is something musl could
> improve i think.
How about something along the lines of the following?
>
>> diff --git a/ldso/dynlink.c b/ldso/dynlink.c
>> index d7726118..c7449df2 100644
>> --- a/ldso/dynlink.c
>> +++ b/ldso/dynlink.c
>> @@ -1326,10 +1326,32 @@ static void do_mips_relocs(struct dso *p, size_t *got)
>>
>> static void reloc_all(struct dso *p)
>> {
>> size_t dyn[DYN_CNT];
>> for (; p; p=p->next) {
>> if (p->relocated) continue;
>> decode_vec(p->dynv, dyn, DYN_CNT);
>> +
>> + if ((dyn[0] & 1<<DT_TEXTREL) || (dyn[DT_FLAGS] & DF_TEXTREL)) {
>> + error("Warning: TEXTREL not supported!",
>> +
>> if (NEED_MIPS_GOT_RELOCS)
>> do_mips_relocs(p, laddr(p, dyn[DT_PLTGOT]));
>> do_relocs(p, laddr(p, dyn[DT_JMPREL]), dyn[DT_PLTRELSZ],
>>
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.
