https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Sam James changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Gleb Fotengauer-Malinovskiy changed:
What|Removed |Added
CC||glebfm at altlinux dot
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Sam James changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #24 from Dominique Martinet ---
Hi all -- it's been a while and this bz tracks the original patch, not the
problem I reported, in hindsight I should have opened a new bz sorry.
I've done that just now:
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
alice changed:
What|Removed |Added
CC||alice at ayaya dot dev
--
You are receiving
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Sam James changed:
What|Removed |Added
CC||sam at gentoo dot org
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #23 from Alan Modra ---
(In reply to Rui Ueyama from comment #21)
> How about splitting the .got section into two
The .got.plt actually (which on x86_64 GNU ld is the section having 3 reserved
entries then the R_X86_64_JUMP_SLOT
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #22 from Fangrui Song ---
> [...] (psykose/alice confirmed lld does not have the problem on alpine, but I
> am not sure if they do the correct thing™ here security-wise -- it's good to
> have a concrete idea here)
lld does the
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #21 from Rui Ueyama ---
How about splitting the .got section into two, one is for the first three words
and the other for the rest of .got and then place the first one in a relro
segment? It would be much easier to do than
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #20 from Alan Modra ---
(In reply to Alan Modra from comment #19)
> It might be even better to put the SHT_NOBITS padding on the header before the
> relro segment.
No, that can't work. Since the end of the relro segment must end
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #19 from Alan Modra ---
The extra PT_LOAD header makes a lot of sense, as it allows another break in
the layout where padding can be hidden (as far as disk is concerned). It might
be even better to put the SHT_NOBITS padding on
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #18 from Rui Ueyama ---
> > IOW, an additional LOAD program-header. I too have thought of that.
>
> It doesn’t need an additional program header. Relro sections are just at the
> end of the RW segment as you can see in my
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #17 from Rui Ueyama ---
> IOW, an additional LOAD program-header. I too have thought of that.
It doesn’t need an additional program header. Relro sections are just at the
end of the RW segment as you can see in my example.
--
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #16 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #15)
> that may be the most pragmatic solution for aarch64.
Correction: for *all* architectures that need to support large-enough
page-sizes.
Perhaps a
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #15 from Hans-Peter Nilsson ---
(In reply to Rui Ueyama from comment #12)
> In the mold linker, we are dealing with the issue by mapping the page that
> is at the boundary of relro and non-relro twice as the last relro page and
>
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #14 from Rui Ueyama ---
> I like this, thanks! (psykose/alice confirmed lld does not have the problem
> on alpine, but I am not sure if they do the correct thing™ here security-wise
> -- it's good to have a concrete idea here)
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #13 from Dominique Martinet ---
> See commit 1a26a53a0dee
That commit is about arm32, which apparently had the same problem, but aarch64
is in a similar place except that larger page sizes are actually used (I use
4K, but asahi
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #12 from Rui Ueyama ---
In the mold linker, we are dealing with the issue by mapping the page that is
at the boundary of relro and non-relro twice as the last relro page and the
first non-relro page. Here is an example of the
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #11 from Alan Modra ---
See commit 1a26a53a0dee
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Dominique Martinet changed:
What|Removed |Added
CC||rfhn.fhbrrjnzeneqpf@noclue.
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Rui Ueyama changed:
What|Removed |Added
CC||rui314 at gmail dot com
--- Comment #9
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #8
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #7 from Alan Modra ---
No, the purpose of COMMONPAGESIZE is as I described in comment #3, adjusting
the linker layout strategy for non-relro binaries.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #6
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #4 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Alan Modra :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=31b4d3a16f200bf04db8439a63b72bba7af4e1be
commit
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #3 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Alan Modra :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9833b7757d246f22db4eb24b8e5db7eb5e05b6d9
commit
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #2 from Alan Modra ---
Actually, the problem is on architectures other than ppc64. On ppc64 I hacked
around the relro alignment problem with ELF_RELROPAGESIZE.
--
You are receiving this mail because:
You are on the CC list for
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Peter Bergner changed:
What|Removed |Added
CC||bergner at linux dot ibm.com
--
You
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Alan Modra changed:
What|Removed |Added
Status|NEW |ASSIGNED
--
You are receiving this
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Alan Modra changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
--
You
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #1 from Alan Modra ---
I'll note that this issue has been raised before, and at that time I decided
that fixing it was difficult.
--
You are receiving this mail because:
You are on the CC list for the bug.
32 matches
Mail list logo
