mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] SIGSEGV with TEXTREL
@ 2020-09-25  3:50 Dominic Chen
  2020-09-25  9:37 ` Szabolcs Nagy
  0 siblings, 1 reply; 9+ messages in thread
From: Dominic Chen @ 2020-09-25  3:50 UTC (permalink / raw)
  To: musl

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

Please CC me on replies.

I recently discovered that musl doesn't support DT/DF_TEXTREL in the
main executable, which can result in the dynamic loader crashing with
SIGSEGV and SEGV_ACCERR while processing relocations. I spent a few days
trying to fix this in the toolchain, but because it is a prototype based
on Clang/LLVM 4.0.0 that adds runtime instrumentation built using the
x64 large code model, so it's not easy to fix. Also, glibc does support
this behavior.

I ended up implementing support for this in musl itself (patch
attached), but given the discussion in the previous thread, "Static
linking is broken after creation of DT_TEXTREL," it seems like this
isn't acceptable due to overhead? I don't quite understand the concern,
because the loader needs to iterate again over the program headers only
if the program contains TEXTRELs, which is strictly an improvement, even
if the iteration itself is suboptimal. Alternatively, I'd suggest that
musl at least warns about unsupported TEXTRELs if present, because
asking application developers to debug a crashing ELF loader is quite a
high bar.

Thanks,

Dominic


[-- Attachment #2: musl-textrel.patch --]
[-- Type: text/plain, Size: 2064 bytes --]

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)
 {
+	unsigned char textrel = 0;
 	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)) {
+			size_t cnt = p->phnum;
+			Phdr *ph = p->phdr;
+			for (; cnt--; ph = (void *)((char *)ph + p->phentsize)) {
+				if (ph->p_type == PT_LOAD && !(ph->p_flags & PF_W)) {
+					unsigned prot = (((ph->p_flags&PF_R) ? PROT_READ : 0) |
+									((ph->p_flags&PF_X) ? PROT_EXEC : 0));
+					size_t start = ph->p_vaddr & -PAGE_SIZE,
+					       end = (ph->p_vaddr + ph->p_memsz + PAGE_SIZE-1) & -PAGE_SIZE;
+					if (mprotect(laddr(p, start), end - start, prot|PROT_WRITE)
+						&& errno != ENOSYS) {
+						error("Error relocating %s: TEXTREL unprotect failed: %m",
+						p->name);
+						if (runtime) longjmp(*rtld_fail, 1);
+					}
+					textrel = 1;
+				}
+			}
+		}
+
 		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],
@@ -1345,6 +1367,25 @@ static void reloc_all(struct dso *p)
 			if (runtime) longjmp(*rtld_fail, 1);
 		}
 
+		if (textrel) {
+			size_t cnt = p->phnum;
+			Phdr *ph = p->phdr;
+			for (; cnt--; ph = (void *)((char *)ph + p->phentsize)) {
+				if (ph->p_type == PT_LOAD && !(ph->p_flags & PF_W)) {
+					unsigned prot = (((ph->p_flags&PF_R) ? PROT_READ : 0) |
+									((ph->p_flags&PF_X) ? PROT_EXEC : 0));
+					size_t start = ph->p_vaddr & -PAGE_SIZE,
+					       end = (ph->p_vaddr + ph->p_memsz + PAGE_SIZE-1) & -PAGE_SIZE;
+					if (mprotect(laddr(p, start), end - start, prot)
+						&& errno != ENOSYS) {
+						error("Error relocating %s: TEXTREL protect failed: %m",
+						p->name);
+						if (runtime) longjmp(*rtld_fail, 1);
+					}
+				}
+			}
+		}
+
 		p->relocated = 1;
 	}
 }

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [musl] SIGSEGV with TEXTREL
  2020-09-25  3:50 [musl] SIGSEGV with TEXTREL Dominic Chen
@ 2020-09-25  9:37 ` Szabolcs Nagy
  2020-09-25 18:58   ` Rich Felker
  2020-09-25 20:13   ` Dominic Chen
  0 siblings, 2 replies; 9+ messages in thread
From: Szabolcs Nagy @ 2020-09-25  9:37 UTC (permalink / raw)
  To: Dominic Chen; +Cc: musl

* Dominic Chen <d.c.ddcc@gmail.com> [2020-09-24 23:50:19 -0400]:
> Please CC me on replies.
> 
> I recently discovered that musl doesn't support DT/DF_TEXTREL in the
> main executable, which can result in the dynamic loader crashing with
> SIGSEGV and SEGV_ACCERR while processing relocations. I spent a few days
> trying to fix this in the toolchain, but because it is a prototype based
> on Clang/LLVM 4.0.0 that adds runtime instrumentation built using the
> x64 large code model, so it's not easy to fix. Also, glibc does support
> this behavior.

there are no existing libcs that fully support textrels
(since for that not just dynamic relocs but static relocs
need to be supported too).

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.

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?)

> 
> I ended up implementing support for this in musl itself (patch
> attached), but given the discussion in the previous thread, "Static
> linking is broken after creation of DT_TEXTREL," it seems like this
> isn't acceptable due to overhead? I don't quite understand the concern,
> because the loader needs to iterate again over the program headers only

dynamic linking overhead is not the issue.

> if the program contains TEXTRELs, which is strictly an improvement, even
> if the iteration itself is suboptimal. Alternatively, I'd suggest that
> musl at least warns about unsupported TEXTRELs if present, because
> asking application developers to debug a crashing ELF loader is quite a
> high bar.

dynamic linker failure diagnostic is something musl could
improve i think.

> 
> Thanks,
> 
> Dominic
> 

> 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)
>  {
> +	unsigned char textrel = 0;
>  	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)) {
> +			size_t cnt = p->phnum;
> +			Phdr *ph = p->phdr;
> +			for (; cnt--; ph = (void *)((char *)ph + p->phentsize)) {
> +				if (ph->p_type == PT_LOAD && !(ph->p_flags & PF_W)) {
> +					unsigned prot = (((ph->p_flags&PF_R) ? PROT_READ : 0) |
> +									((ph->p_flags&PF_X) ? PROT_EXEC : 0));
> +					size_t start = ph->p_vaddr & -PAGE_SIZE,
> +					       end = (ph->p_vaddr + ph->p_memsz + PAGE_SIZE-1) & -PAGE_SIZE;
> +					if (mprotect(laddr(p, start), end - start, prot|PROT_WRITE)
> +						&& errno != ENOSYS) {
> +						error("Error relocating %s: TEXTREL unprotect failed: %m",
> +						p->name);
> +						if (runtime) longjmp(*rtld_fail, 1);
> +					}
> +					textrel = 1;
> +				}
> +			}
> +		}
> +
>  		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],
> @@ -1345,6 +1367,25 @@ static void reloc_all(struct dso *p)
>  			if (runtime) longjmp(*rtld_fail, 1);
>  		}
>  
> +		if (textrel) {
> +			size_t cnt = p->phnum;
> +			Phdr *ph = p->phdr;
> +			for (; cnt--; ph = (void *)((char *)ph + p->phentsize)) {
> +				if (ph->p_type == PT_LOAD && !(ph->p_flags & PF_W)) {
> +					unsigned prot = (((ph->p_flags&PF_R) ? PROT_READ : 0) |
> +									((ph->p_flags&PF_X) ? PROT_EXEC : 0));
> +					size_t start = ph->p_vaddr & -PAGE_SIZE,
> +					       end = (ph->p_vaddr + ph->p_memsz + PAGE_SIZE-1) & -PAGE_SIZE;
> +					if (mprotect(laddr(p, start), end - start, prot)
> +						&& errno != ENOSYS) {
> +						error("Error relocating %s: TEXTREL protect failed: %m",
> +						p->name);
> +						if (runtime) longjmp(*rtld_fail, 1);
> +					}
> +				}
> +			}
> +		}
> +
>  		p->relocated = 1;
>  	}
>  }


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [musl] SIGSEGV with TEXTREL
  2020-09-25  9:37 ` Szabolcs Nagy
@ 2020-09-25 18:58   ` Rich Felker
  2020-09-25 20:13   ` Dominic Chen
  1 sibling, 0 replies; 9+ messages in thread
From: Rich Felker @ 2020-09-25 18:58 UTC (permalink / raw)
  To: musl; +Cc: Dominic Chen

On Fri, Sep 25, 2020 at 11:37:33AM +0200, Szabolcs Nagy wrote:
> * Dominic Chen <d.c.ddcc@gmail.com> [2020-09-24 23:50:19 -0400]:
> > Please CC me on replies.
> > 
> > I recently discovered that musl doesn't support DT/DF_TEXTREL in the
> > main executable, which can result in the dynamic loader crashing with
> > SIGSEGV and SEGV_ACCERR while processing relocations. I spent a few days
> > trying to fix this in the toolchain, but because it is a prototype based
> > on Clang/LLVM 4.0.0 that adds runtime instrumentation built using the
> > x64 large code model, so it's not easy to fix. Also, glibc does support
> > this behavior.
> 
> there are no existing libcs that fully support textrels
> (since for that not just dynamic relocs but static relocs
> need to be supported too).
> 
> glibc only supports a small set of textrels and of course
> [...]

Indeed, textrels are intentionally not supported as part of the
philosophy of having a dynamic linker that's universal rather than
arch-specific for each arch. Dynamic relocations are pretty much the
same on all archs but each arch has its own (often giant) set of
possible textrels based on the encoding of addresses in its
instruction set.

For legacy reasons, a limited number of textrel types are supported,
only on some archs (basically just i386 and x86_64), in shared library
code. At least at one point, there was still a decent amount of x86
asm that was not PIC-ready, especially in graphics code. I think that
time is actually past now, but it doesn't make sense to remove
something that didn't need any special support to begin with.

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.

Rich

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [musl] SIGSEGV with TEXTREL
  2020-09-25  9:37 ` Szabolcs Nagy
  2020-09-25 18:58   ` Rich Felker
@ 2020-09-25 20:13   ` Dominic Chen
  2020-09-25 20:49     ` Markus Wichmann
  2020-09-25 22:46     ` Rich Felker
  1 sibling, 2 replies; 9+ messages in thread
From: Dominic Chen @ 2020-09-25 20:13 UTC (permalink / raw)
  To: musl

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],
>>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [musl] SIGSEGV with TEXTREL
  2020-09-25 20:13   ` Dominic Chen
@ 2020-09-25 20:49     ` Markus Wichmann
  2020-09-25 22:46     ` Rich Felker
  1 sibling, 0 replies; 9+ messages in thread
From: Markus Wichmann @ 2020-09-25 20:49 UTC (permalink / raw)
  To: musl

On Fri, Sep 25, 2020 at 04:13:19PM -0400, Dominic Chen wrote:
> On 9/25/2020 2:58 PM, Rich Felker wrote:
> > 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.
>

Some security mechanisms prevent mapping anything executable that has
ever been writable. I believe SELinux can be set up this way, but I am
not sure. Of course, this interferes with some interpreters, since it
essentially prevents dynamic recompilation, but that is a specific use
case users of SELinux might be willing to sacrifice.

Ciao,
Markus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [musl] SIGSEGV with TEXTREL
  2020-09-25 20:13   ` Dominic Chen
  2020-09-25 20:49     ` Markus Wichmann
@ 2020-09-25 22:46     ` Rich Felker
  2020-09-26  0:32       ` Dominic Chen
  1 sibling, 1 reply; 9+ messages in thread
From: Rich Felker @ 2020-09-25 22:46 UTC (permalink / raw)
  To: Dominic Chen; +Cc: musl

On Fri, Sep 25, 2020 at 04:13:19PM -0400, Dominic Chen wrote:
> 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.

If you build with PIC then you don't have textrels.

> 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.

Technically that's true for a main executable loaded by the dynamic
linker, but it's not true for static-PIE or for (future plan; PoC
patch exists but needs polishing before it goes upstream) musl's new
dynamic linking mode with no PT_INTERP where the program itself does
the work of finding and loading the dynamic linker from its startup
code (allows shipping dynamic linker alongside executable with an
executable-relative rather than absolute pathname). It's also not true
for the dynamic linker itself.

> > 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.

Then this is a configuration that's not supported. You could still
make non-PIE (pass -no-pie at link time) executables just fine.

> > 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],
> >>

This breaks existing support for textrels in shared libraries, which
isn't a feature most of us really want anymore, but it would be a
regression to remove it.

The right way to make this more friendly, I think, would be tracking
the writable mapping range for each DSO (technically this is
incomplete since it could be multiple ranges, but in that case we'd
just take the convex hull of them and accept false negatives because
anything else is almost surely too big a performance hit), and
erroring out before processing a relocation at an address that's not
writable for its DSO. This would also go part of the way towards
making it possible for ldd to process untrusted files.

I'm not 100% opposed to allowing textrel for the main application with
the existing textrel restrictions that exist for shared libraries (on
the types of relocations supported and the archs it works on), but I
do lean against it, and somewhat worry that it would lead to requests
for further textrel support when it's something we're trying to phase
out rather than embrace.

Rich

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [musl] SIGSEGV with TEXTREL
  2020-09-25 22:46     ` Rich Felker
@ 2020-09-26  0:32       ` Dominic Chen
  2020-09-26  4:14         ` Fangrui Song
  0 siblings, 1 reply; 9+ messages in thread
From: Dominic Chen @ 2020-09-26  0:32 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

On 9/25/2020 6:46 PM, Rich Felker wrote:
>
> The right way to make this more friendly, I think, would be tracking
> the writable mapping range for each DSO (technically this is
> incomplete since it could be multiple ranges, but in that case we'd
> just take the convex hull of them and accept false negatives because
> anything else is almost surely too big a performance hit), and
> erroring out before processing a relocation at an address that's not
> writable for its DSO. This would also go part of the way towards
> making it possible for ldd to process untrusted files.

I agree that that seems to be a better solution, and it was also
discussed in the previous mailing list thread. But my point is just that
given how this issue has been reoccurring, I think it'd be useful to do
something now (e.g. emit a non-fail warning if TEXTRELs are present),
rather than deferring any changes.

Thanks,

Dominic


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [musl] SIGSEGV with TEXTREL
  2020-09-26  0:32       ` Dominic Chen
@ 2020-09-26  4:14         ` Fangrui Song
  2020-09-26  9:09           ` Szabolcs Nagy
  0 siblings, 1 reply; 9+ messages in thread
From: Fangrui Song @ 2020-09-26  4:14 UTC (permalink / raw)
  To: musl; +Cc: Rich Felker

On Fri, Sep 25, 2020 at 7:53 PM Dominic Chen <d.c.ddcc@gmail.com> wrote:
>
> On 9/25/2020 6:46 PM, Rich Felker wrote:
> >
> > The right way to make this more friendly, I think, would be tracking
> > the writable mapping range for each DSO (technically this is
> > incomplete since it could be multiple ranges, but in that case we'd
> > just take the convex hull of them and accept false negatives because
> > anything else is almost surely too big a performance hit), and
> > erroring out before processing a relocation at an address that's not
> > writable for its DSO. This would also go part of the way towards
> > making it possible for ldd to process untrusted files.
>
> I agree that that seems to be a better solution, and it was also
> discussed in the previous mailing list thread. But my point is just that
> given how this issue has been reoccurring, I think it'd be useful to do
> something now (e.g. emit a non-fail warning if TEXTRELs are present),
> rather than deferring any changes.
>
> Thanks,
>
> Dominic

binutils 2.35 can be configured with --enable-textrel-check=yes, and
Linux/x86 defaults to 'yes'. ld emits a warning upon a text
relocation:

warning: creating DT_TEXTREL in a PIE

(LLD always disallows text relocations by default (-z text). You need
-z notext to enable DF_TEXTREL and text relocations.)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [musl] SIGSEGV with TEXTREL
  2020-09-26  4:14         ` Fangrui Song
@ 2020-09-26  9:09           ` Szabolcs Nagy
  0 siblings, 0 replies; 9+ messages in thread
From: Szabolcs Nagy @ 2020-09-26  9:09 UTC (permalink / raw)
  To: Fangrui Song; +Cc: musl, Rich Felker

* Fangrui Song <i@maskray.me> [2020-09-25 21:14:18 -0700]:
> On Fri, Sep 25, 2020 at 7:53 PM Dominic Chen <d.c.ddcc@gmail.com> wrote:
> >
> > On 9/25/2020 6:46 PM, Rich Felker wrote:
> > >
> > > The right way to make this more friendly, I think, would be tracking
> > > the writable mapping range for each DSO (technically this is
> > > incomplete since it could be multiple ranges, but in that case we'd
> > > just take the convex hull of them and accept false negatives because
> > > anything else is almost surely too big a performance hit), and
> > > erroring out before processing a relocation at an address that's not
> > > writable for its DSO. This would also go part of the way towards
> > > making it possible for ldd to process untrusted files.
> >
> > I agree that that seems to be a better solution, and it was also
> > discussed in the previous mailing list thread. But my point is just that
> > given how this issue has been reoccurring, I think it'd be useful to do
> > something now (e.g. emit a non-fail warning if TEXTRELs are present),
> > rather than deferring any changes.
> >
> > Thanks,
> >
> > Dominic
> 
> binutils 2.35 can be configured with --enable-textrel-check=yes, and
> Linux/x86 defaults to 'yes'. ld emits a warning upon a text
> relocation:
> 
> warning: creating DT_TEXTREL in a PIE
> 
> (LLD always disallows text relocations by default (-z text). You need
> -z notext to enable DF_TEXTREL and text relocations.)

nice

and gcc passes -z text for static pie code so that case should
not end up with text rels.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-09-26  9:10 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-25  3:50 [musl] SIGSEGV with TEXTREL Dominic Chen
2020-09-25  9:37 ` Szabolcs Nagy
2020-09-25 18:58   ` Rich Felker
2020-09-25 20:13   ` Dominic Chen
2020-09-25 20:49     ` Markus Wichmann
2020-09-25 22:46     ` Rich Felker
2020-09-26  0:32       ` Dominic Chen
2020-09-26  4:14         ` Fangrui Song
2020-09-26  9:09           ` Szabolcs Nagy

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

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

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git