On Wed, 6 Nov 2013, Torbjorn Granlund wrote:
Exact decision for the change? I'm not sure what you mean by 'decision'
there. If you're wondering about the _reason_ for the change (why we did
it), the answer is so that ASLR is applied not just to the code in shared
libraries but
On Wed, 6 Nov 2013, Torbjorn Granlund wrote:
...
The change makes be quite worried, since it *seems* to be done without
proper understanding of the issues involved.
Appearances can be deceiving.
Furthermore, the ABI change has not been properly announced,
I guess the release announcement
On 2013/11/07 10:43, Richard Biener wrote:
I understand that on
OpenBSD -fpie is now simply the default (for SUSE we build
selected security relevant apps with -fpie, not all apps due
to the fear of runtime overhead).
That is correct, -fpie is the
Exact decision for the change? I'm not sure what you mean by 'decision'
there. If you're wondering about the _reason_ for the change (why we did
it), the answer is so that ASLR is applied not just to the code in shared
libraries but also the code in executables. If you're wondering
Philip Guenther guent...@gmail.com writes:
Ah, but you are, sorta. In OpenBSD 5.3, platforms where the compiler and
toolchain support were for robust for it were switched to build PIE
objects and executables by default. So yes, that object _is_ expected to
be position independent.
Torbjorn Granlund t...@gmplib.org writes:
Now we have (at least) two OpenBSD ABIs for AMD64, pre 5.3 and now 5.3,
5.4. To make sense of things, I would not be surprised to see
R_X86_64_64 banned from 5.5 and on, creating a 3rd OpenBSD AMD64 ABI.
I don't understand the fine details of which
On Tue, 5 Nov 2013, Torbjorn Granlund wrote:
Philip Guenther guent...@gmail.com writes:
Ah, but you are, sorta. In OpenBSD 5.3, platforms where the compiler and
toolchain support were for robust for it were switched to build PIE
objects and executables by default. So yes, that
Torbjorn Granlund t...@gmplib.org writes:
If one tries to assemble and link the former code on a 5.3/5.4 system,
one gets again the error relocation R_X86_64_32S can not be used when
making a shared object; recompile with -fPIC.
What other objects were involved in the link? I guess something
Philip Guenther guent...@gmail.com writes:
That's bad. But then why not allow R_X86_64_32S too?
Because there's no guarantee that the target is within 2GB, as the
reference may resolve to the symbol in a different shared object which is
too far away.
Can you use ELF visibility to provide
I am working on getting the GMP bignum library to work better on
OpenBSD.
With current GMP sources (GMP 5.0.x, 5.1.x, and development head) a
'fat' build will not work on amd64 under OpenBSD 5.3 and 5.4. With
older version of OpenBSD (I've tested 4.9, 5.0, 5.2) things work as
expected.
The
10 matches
Mail list logo
