[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMw0sz+ONDY=44tyE+wosEzgtjGc-z0nK3RcymRN8yCUn73GRg@mail.gmail.com>
Date: Wed, 29 Jan 2020 23:08:46 +0300
From: Андрей Аладьев <aladjev.andrew@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Static linking is broken after creation of DT_TEXTREL segment
> Ooh boy, why would you do this? When there's a perfectly good -lgmp just
waiting for you.
Usage of "/usr/lib/libgmp.a" directly is not forbidden by any toolchain or
build system. Moreover it is recommended by cmake. You can google for
"target_link_libraries( site:github.com" and found millions of software
that uses something like:
find_library(EXTERNAL_LIB)
target_link_libraries(something ${EXTERNAL_LIB_FOUND})
> The warning is justified, you usually do not want to do this. With a
TEXTREL, the code has to be mapped as writable, so now programming errors
and exploits can change the executable code.
This is warning from ld, not from musl. Segfault is not an acceptable
message from libc. Libc should not try to write into readonly pointer.
> Well, the remedy is obvious: Get rid of the TEXTREL.
Yes, I've found a workaround: "USE='-asm' emerge -v1 gmp", assembly is
broken, will report it to gmp upstream. But this is not a fix for the issue.
> Iterate over the apps PHDRs and remove write protection from all RO
segments?
So libc knows that file is mapped as readonly and should not try to write
into readonly pointers. Libc can do the following:
1. Ignore impossible relocations.
2. Add a warning to stderr and still ignore impossible relocations.
3. do abort, user will receive SIGABRT and understand that he uses libc in
a wrong way.
Segfault is not an acceptable answer.
Thank you.
ср, 29 янв. 2020 г. в 22:20, Markus Wichmann <nullplan@....net>:
> On Wed, Jan 29, 2020 at 09:41:46PM +0300, Андрей Аладьев wrote:
> > gcc main.c /usr/lib/libgmp.a -o main && ./main
>
> Ooh boy, why would you do this? When there's a perfectly good -lgmp just
> waiting for you.
>
> > warning: creating a DT_TEXTREL in object
>
> The warning is justified, you usually do not want to do this. With a
> TEXTREL, the code has to be mapped as writable, so now programming
> errors and exploits can change the executable code.
>
> > We can see that "laddr" provided pointer to "dso->base + rel[0]", than
> > switch tried to override it's value and segfault appeared. Pointer is
> > wrong, most likely readonly.
> >
>
> Pointer is correct, but memory should have been mapped writable. More on
> this in a bit.
>
> > You can replace "gcc" with "clang" and everything will be the same.
> Updated
> > binutils to most recent version 2.33.1 and rebuilt toolchain - nothing
> > changed. Pointer is still invalid and SEGV_ACCERR appears.
> >
>
> Of course. The issue is a relocation inside a read-only segment.
> Binutils and compiler are not malfunctioning.
>
> > So I think that bug is inside musl itself. Glibc container is the same
> > situation works fine. I see no way to create a workaround for this issue.
>
> Well, the remedy is obvious: Get rid of the TEXTREL. It is usually
> caused by bad assembly source code, and fixable with only minor
> knowledge of the details. Consult the search engine of your least
> distrust for more information on this.
>
> Regarding the actual problem though, the problem here is that DT_TEXTREL
> is handled only in map_library(), so it is not handled for kernel mapped
> DSOs. Which isn't a problem for libc or the VDSO, but the app itself
> might be TEXTREL (and is, in this case), and that isn't handled. How,
> though? Iterate over the apps PHDRs and remove write protection from all
> RO segments?
>
> And one more question: Since musl resolves all relocations immediately,
> couldn't we write-protect TEXTREL modules after relocating them?
> Provided no unresolved relocations remain, of course.
>
> Ciao,
> Markus
>
Content of type "text/html" skipped
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.
