On Fri, Feb 20, 2015 at 07:28:50PM +, Peter Robinson wrote:
On Fri, Feb 20, 2015 at 6:55 PM, Till Maas opensou...@till.name wrote:
On Fri, Feb 20, 2015 at 05:21:59PM +, Peter Robinson wrote:
I've never argumented against the goal that web browser or all network
aware
services
On Fri, Feb 20, 2015 at 07:28:50PM +, Peter Robinson wrote:
On Fri, Feb 20, 2015 at 6:55 PM, Till Maas opensou...@till.name wrote:
On Fri, Feb 20, 2015 at 05:21:59PM +, Peter Robinson wrote:
How is a PDF with a binary payload any different? Sounds like we need
to be running pdf
I've never argumented against the goal that web browser or all network aware
services should be PIEs, after all, why would we (Ulrich Drepper and myself)
add the PIE support into the toolchain otherwise?
I'm just not convinced most of the unpriviledged programs should be PIEs.
Thanks to e.g.
Am 20.02.2015 um 18:21 schrieb Peter Robinson:
I've never argumented against the goal that web browser or all network aware
services should be PIEs, after all, why would we (Ulrich Drepper and myself)
add the PIE support into the toolchain otherwise?
I'm just not convinced most of the
On 02/20/2015 07:55 PM, Till Maas wrote:
than the technical change to implement it, there's no mention that it
will have an impact on performance, with numbers to back it up, across
the three primary architectures.
So how much performance impact is acceptable?
None - Seriously, people will
On Fri, Feb 20, 2015 at 12:21 PM, Peter Robinson pbrobin...@gmail.com wrote:
Also I've seen no performance analysis across all three architectures
to see the impact. I'll happily send you an XO-1 to test on (our
lowest supported device on i686 and also one of our most widely
deployed Fedora
On Fri, Feb 20, 2015 at 05:21:59PM +, Peter Robinson wrote:
I've never argumented against the goal that web browser or all network
aware
services should be PIEs, after all, why would we (Ulrich Drepper and
myself)
add the PIE support into the toolchain otherwise?
I'm just not
On Fri, Feb 20, 2015 at 01:40:30PM -0500, Josh Boyer wrote:
(XO-4). There's the whole Android angle now to, which frankly makes a
lot of sense for them. Even the latest OLPC OS development release is
based on Fedora 20 and is targeted at the XO-4 hardware.
Android already uses ASLR, see eg
On Fri, Feb 20, 2015 at 6:40 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
On Fri, Feb 20, 2015 at 12:21 PM, Peter Robinson pbrobin...@gmail.com wrote:
Also I've seen no performance analysis across all three architectures
to see the impact. I'll happily send you an XO-1 to test on (our
On Fri, Feb 20, 2015 at 6:55 PM, Till Maas opensou...@till.name wrote:
On Fri, Feb 20, 2015 at 05:21:59PM +, Peter Robinson wrote:
I've never argumented against the goal that web browser or all network
aware
services should be PIEs, after all, why would we (Ulrich Drepper and
Am 20.02.2015 um 20:28 schrieb Peter Robinson:
On Fri, Feb 20, 2015 at 6:55 PM, Till Maas opensou...@till.name wrote:
So how much performance impact is acceptable?
Well you've not documented any of the impact so how can we discuss
that? We have no idea if the impact is going to be 0.1% 1% or
On Thu, Feb 19, 2015 at 09:14:32AM +, Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1194167
Basically everything in Rawhide which uses the normal RPM
opt flags will now have to be compiled with -fPIC, otherwise
you get errors like:
/usr/bin/ld:
https://bugzilla.redhat.com/show_bug.cgi?id=1194167
Basically everything in Rawhide which uses the normal RPM
opt flags will now have to be compiled with -fPIC, otherwise
you get errors like:
/usr/bin/ld: /tmp/ccqyK5ia.o: relocation R_X86_64_32S against `virConnectOpen'
can not be used when
On Thu, Feb 19, 2015 at 07:58:10PM +0100, Reindl Harald wrote:
Am 19.02.2015 um 19:48 schrieb Till Maas:
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
it, now in F22+ we might have smaller
Am 19.02.2015 um 20:15 schrieb Jakub Jelinek:
On Thu, Feb 19, 2015 at 07:58:10PM +0100, Reindl Harald wrote:
Am 19.02.2015 um 19:48 schrieb Till Maas:
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
On Thu, Feb 19, 2015 at 12:34 PM, Till Maas opensou...@till.name wrote:
On Thu, Feb 19, 2015 at 08:15:19PM +0100, Jakub Jelinek wrote:
I've never argumented against the goal that web browser or all network
aware
services should be PIEs, after all, why would we (Ulrich Drepper and
myself)
On Thu, Feb 19, 2015 at 08:15:19PM +0100, Jakub Jelinek wrote:
I've never argumented against the goal that web browser or all network aware
services should be PIEs, after all, why would we (Ulrich Drepper and myself)
add the PIE support into the toolchain otherwise?
I'm just not convinced
On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
info gcc, of course yes. -DPIC is not documented at all, and the
various pie/pic options are obscure to say the least.
Why should -DPIC be documented? -D is
On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
info gcc, of course yes. -DPIC is not documented at all, and the
various pie/pic options
On Thu, Feb 19, 2015 at 10:22:03AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 09:14:32AM +, Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1194167
Basically everything in Rawhide which uses the normal RPM
opt flags will now have to be compiled with
I'm still no closer to being able to fix the problem.
I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
executable? Upstream? Will that break on some platforms/architectures?
And indeed what is the difference between -fPIE / -pie / -fpie /
-fPIC / -fpic / -DPIC / etc? Where is
On Thu, Feb 19, 2015 at 11:23:18AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 10:11:07AM +, Richard W.M. Jones wrote:
I'm still no closer to being able to fix the problem.
I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
executable? Upstream? Will that
And in another case I had (qemu), it's not predictable. If you just
compile part of qemu twice, the first time it gives the error and the
second time not.
I had to add this hack to qemu.spec:
http://pkgs.fedoraproject.org/cgit/qemu.git/commit/?id=6c3741c2769a21542a34716fa9188e520887a803
Rich.
On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
explicitly in the real program. It's being added to everything by
something in RPM.
On Thu, Feb 19, 2015 at 09:51:33AM +, Richard W.M. Jones wrote:
There is definitely new/different behaviour in Rawhide, and recently.
Also I was only able to see the new behaviour by updating from gcc 4.x
- gcc 5. ie. Updating redhat-rpm-config isn't what causes the
problem.
Well, gcc
On Thu, Feb 19, 2015 at 10:11:07AM +, Richard W.M. Jones wrote:
I'm still no closer to being able to fix the problem.
I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
executable? Upstream? Will that break on some platforms/architectures?
It really should be just about
On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
info gcc, of course yes. -DPIC is not documented at all, and the
various pie/pic options are obscure to say the least.
Why should -DPIC be documented? -D is documented. -DPIC means define
macro PIC to 1. There is no magic
On Thu, Feb 19, 2015 at 11:45:01AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
info gcc, of course yes.
On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
explicitly in the real program. It's being added to everything by
something in RPM. I'm not exactly sure what, maybe %{configure}?
So I don't know
On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
info gcc, of course yes. -DPIC is not documented at all, and the
various pie/pic options
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for
Which packages are there that do not process untrusted data and are
slowed
Am 19.02.2015 um 19:48 schrieb Till Maas:
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for
Which packages are there that do
On Thu, Feb 19, 2015 at 07:48:30PM +0100, Till Maas wrote:
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for
Which
I'd like to know the performance loss estimated/examined by FESCO, or
I think it's a bad idea on i686 systems, it's already slow enough.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
explicitly in the real program. It's being added to everything by
something in RPM.
On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
explicitly in the real
On Thu, 2015-02-19 at 18:05 +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
I plan to change this to 1 now in Rawhide for the upcoming Fedora 23
feature:
https://bugzilla.redhat.com/show_bug.cgi?id=1192183
Since I did not get any feedback from the
On Thu, Feb 19, 2015 at 01:02:29PM -0500, Adam Jackson wrote:
On Thu, 2015-02-19 at 18:05 +0100, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
I plan to change this to 1 now in Rawhide for the upcoming Fedora 23
feature:
38 matches
Mail list logo