Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: mintsuki at protonmail dot com
Target Milestone: ---
When linking a static-pie kernel with ld.lld (from LLVM) or ld.gold, the output
ELF file type is always ET_DYN (as I believe
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
mintsuki changed:
What|Removed |Added
Summary|ld.bfd makes elf type |ld.bfd makes ELFs of type
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #2 from mintsuki ---
(In reply to H.J. Lu from comment #1)
> It is done to ensure that PIE is loaded at the specific address which may
> be required for functional, performance or security purposes.
This does not match what all th
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #3 from mintsuki ---
Also, when generating a shared object with -shared, without -pie, having a
non-0 base address does not affect the ELF file type, which is always ET_DYN.
If what you just said is true, then why is this the behav
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #6 from mintsuki ---
(In reply to H.J. Lu from comment #4)
> (In reply to mintsuki from comment #2)
> > (In reply to H.J. Lu from comment #1)
> > > It is done to ensure that PIE is loaded at the specific address which may
> > > be
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #7 from mintsuki ---
(In reply to H.J. Lu from comment #5)
> (In reply to mintsuki from comment #3)
> > Also, when generating a shared object with -shared, without -pie, having a
> > non-0 base address does not affect the ELF file
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #10 from mintsuki ---
(In reply to H.J. Lu from comment #8)
> (In reply to mintsuki from comment #7)
> > (In reply to H.J. Lu from comment #5)
> > > (In reply to mintsuki from comment #3)
> > > > Also, when generating a shared obje
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #12 from mintsuki ---
(In reply to H.J. Lu from comment #11)
> (In reply to mintsuki from comment #10)
>
> > If this is policy, then I believe it should be properly documented
>
> Updating document won't solve your debugging issu
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #14 from mintsuki ---
(In reply to H.J. Lu from comment #13)
> Does PIE with zero load address cause any real problems for you?
Why not just answer the question? Whether it causes real problems for me or not
should be irrelevant t
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #16 from mintsuki ---
(In reply to H.J. Lu from comment #15)
> Here is the original discussion:
>
> https://lore.kernel.org/all/CAMe9rOoJvfJ-
> r3zbwpecpiulfcdrxprpayzcammxf3k7014...@mail.gmail.com/T/
> #m2cfa035c82e32ca865ec0f1c3
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #18 from mintsuki ---
(In reply to H.J. Lu from comment #17)
> Fixed in 2.43 by:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;
> h=0daa17bf187cebd5b200f4fd5405cc55e75c391f
Thank you very much! I'll just finish off
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
mintsuki changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #21 from mintsuki ---
(In reply to H.J. Lu from comment #20)
> It turns out that static PIE with non-zero load address must have ET_EXEC:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=31799
>
> Otherwise, there is no way fo
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #22 from mintsuki ---
As far as I can tell, the linked issue seems to indicate more so that this is
indeed a problem rather than some glibc bug.
Does glibc crash without any patch if you patch ld.bfd to create an ET_DYN
instead?
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #25 from mintsuki ---
(In reply to H.J. Lu from comment #23)
> (In reply to mintsuki from comment #21)
> > (In reply to H.J. Lu from comment #20)
> > > It turns out that static PIE with non-zero load address must have ET_EXEC:
> >
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #26 from mintsuki ---
(In reply to H.J. Lu from comment #24)
> (In reply to mintsuki from comment #22)
> > As far as I can tell, the linked issue seems to indicate more so that this
> > is indeed a problem rather than some glibc bu
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #27 from mintsuki ---
This is the aforementioned other kernel's readelf -d output:
Dynamic section at offset 0x46b70 contains 13 entries:
TagType Name/Value
0x0004 (HASH)
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #30 from mintsuki ---
(In reply to H.J. Lu from comment #29)
> (In reply to mintsuki from comment #27)
> > This is the aforementioned other kernel's readelf -d output:
> >
> >
> > Dynamic section at offset 0x46b70 contains 13 ent
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #32 from mintsuki ---
(In reply to H.J. Lu from comment #31)
> (In reply to mintsuki from comment #30)
> > Basically, it tries to find a PHDR which contains the RELA section, and if
> > it find it, it subtracts the PHDR's virtual a
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #34 from mintsuki ---
(In reply to H.J. Lu from comment #33)
> (In reply to mintsuki from comment #32)
> > (In reply to H.J. Lu from comment #31)
> > > (In reply to mintsuki from comment #30)
> > > > Basically, it tries to find a P
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #36 from mintsuki ---
(In reply to H.J. Lu from comment #35)
> (In reply to mintsuki from comment #34)
>
> > > The static PIE generated by ldd with non-zero load address won't work with
> > > glibc before and after my glibc fix.
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #38 from mintsuki ---
(In reply to Fangrui Song from comment #37)
> I agree with mintsuki . The "-pie -Ttext-segment=non-zero => ET_EXEC" hack
> should not be needed.
>
> From https://sourceware.org/pipermail/binutils/2013-Decembe
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #41 from mintsuki ---
(In reply to Adhemerval Zanella from comment #39)
> (In reply to Fangrui Song from comment #37)
> > I agree with mintsuki . The "-pie -Ttext-segment=non-zero => ET_EXEC" hack
> > should not be needed.
> >
> >
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #42 from mintsuki ---
(In reply to H.J. Lu from comment #40)
> -Ttext-segment=0x6000 should create a binary which is guaranteed to
> be
> loaded at 0x6000.
...as long as it's not a PIE.
--
You are receiving this
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #44 from mintsuki ---
(In reply to H.J. Lu from comment #43)
> (In reply to mintsuki from comment #42)
> > (In reply to H.J. Lu from comment #40)
> > > -Ttext-segment=0x6000 should create a binary which is guaranteed
> > >
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #46 from mintsuki ---
(In reply to H.J. Lu from comment #45)
> (In reply to mintsuki from comment #44)
> > (In reply to H.J. Lu from comment #43)
> > > (In reply to mintsuki from comment #42)
> > > > (In reply to H.J. Lu from comme
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #48 from mintsuki ---
(In reply to H.J. Lu from comment #47)
> (In reply to mintsuki from comment #46)
> g.
> > >
> > > Opt-in to ET_EXEC will be wrong.
> >
> > Why will it be wrong? What if someone (me) wants to make a PIE that
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #50 from mintsuki ---
(In reply to H.J. Lu from comment #49)
> (In reply to mintsuki from comment #48)
> > (In reply to H.J. Lu from comment #47)
> > > (In reply to mintsuki from comment #46)
> > > g.
> > > > >
> > > > > Opt-in to
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #53 from mintsuki ---
(In reply to H.J. Lu from comment #51)
> (In reply to mintsuki from comment #50)
>
> > > Why can't you check DF_1_PIE for PIE?
> >
> > That is what I do now, but to check for *relocatability*. PIE in and of
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #54 from mintsuki ---
(In reply to H.J. Lu from comment #52)
> (In reply to H.J. Lu from comment #51)
> > (In reply to mintsuki from comment #50)
> >
> > > > Why can't you check DF_1_PIE for PIE?
> > >
> > > That is what I do now
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #56 from mintsuki ---
(In reply to mintsuki from comment #54)
> (In reply to H.J. Lu from comment #52)
> > (In reply to H.J. Lu from comment #51)
> > > (In reply to mintsuki from comment #50)
> > >
> > > > > Why can't you check DF
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #57 from mintsuki ---
(In reply to H.J. Lu from comment #55)
> (In reply to mintsuki from comment #54)
> > (In reply to H.J. Lu from comment #52)
> > > (In reply to H.J. Lu from comment #51)
> > > > (In reply to mintsuki from comme
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #59 from mintsuki ---
(In reply to Adhemerval Zanella from comment #58)
> (In reply to mintsuki from comment #41)
> > (In reply to Adhemerval Zanella from comment #39)
> > > (In reply to Fangrui Song from comment #37)
> > > > I agr
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #61 from mintsuki ---
(In reply to mintsuki from comment #59)
> (In reply to Adhemerval Zanella from comment #58)
> > (In reply to mintsuki from comment #41)
> > > (In reply to Adhemerval Zanella from comment #39)
> > > > (In reply
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #62 from mintsuki ---
(In reply to Adhemerval Zanella from comment #60)
> (In reply to mintsuki from comment #59)
> > (In reply to Adhemerval Zanella from comment #58)
> > > (In reply to mintsuki from comment #41)
>
> > > So maybe
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #64 from mintsuki ---
(In reply to Adhemerval Zanella from comment #63)
> (In reply to mintsuki from comment #61)
> >
> > Actually I don't think that may be possible, at least not by checking the
> > OS/ABI field alone, given on m
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #66 from mintsuki ---
(In reply to Fangrui Song from comment #65)
> > > Changing ET_DYN to ET_EXEC fulfills the address requirement but disables
> > > ASLR.
> > > Is it intentional?
> >
> > That's my understanding of reading the -
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
mintsuki changed:
What|Removed |Added
Summary|ld.bfd makes ELFs of type |ld.bfd makes ELFs of type
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #67 from mintsuki ---
I'd like to give a summary of the issue, as the whole thread is pretty long and
may get confusing:
ld.bfd, *regardless of target*, be it GNU/Linux or even *freestanding
environments* (for example using an x86
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
mintsuki changed:
What|Removed |Added
Version|2.42|2.43
--
You are receiving this mail becau
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #68 from mintsuki ---
Bug is still present in 2.43...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
mintsuki changed:
What|Removed |Added
Version|2.43|2.43.1
--
You are receiving this mail bec
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
mintsuki changed:
What|Removed |Added
Severity|normal |critical
--
You are receiving this mail b
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #70 from mintsuki ---
The bug is still present in 2.43.1. I also elevated the importance to
"critical" since I was allowed to do so.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #71 from mintsuki ---
Could, in principle, this issue be addressed now that glibc bug #31799 has been
fixed?
--
You are receiving this mail because:
You are on the CC list for the bug.
45 matches
Mail list logo
