On 01/19/2015 02:22 PM, Jakub Jelinek wrote:
On Mon, Jan 19, 2015 at 01:59:32PM +0100, Florian Weimer wrote:
It
is an ABI change. IMHO very much undesirable. Just complain to people that
build their packages without it where it matters.
Some core libraries use off_t or struct stat in
On 01/19/2015 04:17 PM, Peter Robinson wrote:
As far as I can tell, OLPC does not ship newer Fedora releases through
their
updater, so what we do in Fedora does not make any difference at all to
OLPC
users.
That's not entirely correct, they don't yet have F-21 but they do have
recent
On 01/19/2015 01:21 PM, Florian Weimer wrote:
On 01/19/2015 01:17 PM, Alexander Ploumistos wrote:
On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com
mailto:fwei...@redhat.com wrote:
I wrote a slightly broader proposal, also covering SSE2 (for i386),
and (since today)
On 01/09/2015 12:16 AM, Dennis Gilmore wrote:
at least i doubt there is a noticeable userbase with i686 running
Fedora at all *and* would notice the drop noticeable
all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that
userbase is in the millions, but would they notice the
On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com wrote:
I wrote a slightly broader proposal, also covering SSE2 (for i386), and
(since today) off_t and ino_t:
https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags
Would that make it impossible to run fedora on
On 19/01/15 12:21, Florian Weimer wrote:
On 01/19/2015 01:17 PM, Alexander Ploumistos wrote:
On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com
mailto:fwei...@redhat.com wrote:
I wrote a slightly broader proposal, also covering SSE2 (for i386),
and (since today) off_t
On 01/07/2015 02:30 PM, Josh Boyer wrote:
We just went over something very much like this for x86_64 packages
with FESCo ticket 1113:
https://fedorahosted.org/fesco/ticket/1113
Could you perhaps review that and elaborate on the differences between
that proposal and this one if there are any?
On Mon, Jan 19, 2015 at 1:19 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 19.01.2015 um 13:17 schrieb Alexander Ploumistos:
On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com
mailto:fwei...@redhat.com wrote:
I wrote a slightly broader proposal, also covering SSE2
Am 19.01.2015 um 13:23 schrieb Alexander Ploumistos:
On Mon, Jan 19, 2015 at 2:21 PM, Florian Weimer wrote:
Yes, but test coverage for those CPUs is already rather poor, so I
don't expect them to work anymore.
OK, thanks. Guess I'll have to switch my PIII and Athlon MP relics to
at least i doubt there is a noticeable userbase with i686 running
Fedora at all *and* would notice the drop noticeable
all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that
userbase is in the millions, but would they notice the performance
drop I do not know.
As far as I
On 01/19/2015 01:41 PM, Jakub Jelinek wrote:
On Mon, Jan 19, 2015 at 01:37:29PM +0100, Florian Weimer wrote:
On 01/19/2015 01:15 PM, Jakub Jelinek wrote:
No, because you need GCC 5 for that (ok, have scratch rpms now for that),
and very recent binutils (2.25 we have in F22 is not enough).
Hi,
Would that make it impossible to run fedora on sse-only i686 CPUs?
Yes, but test coverage for those CPUs is already rather poor, so I don't
expect them to work anymore.
See other replies, people are running such machines.
Given x86_64 exists for many years and even embedded (see
On Mon, Jan 19, 2015 at 2:32 PM, Reindl Harald h.rei...@thelounge.net
wrote:
to be honest - the energy these old machines have wasted the last years
could have payed recent hardware and the combination of a bleeding edge
distribution and more than a decade old hardware is questionable
That
On Mon, Jan 19, 2015 at 01:37:29PM +0100, Florian Weimer wrote:
On 01/19/2015 01:15 PM, Jakub Jelinek wrote:
No, because you need GCC 5 for that (ok, have scratch rpms now for that),
and very recent binutils (2.25 we have in F22 is not enough).
Ugh, this seems to suggests to defer the PIE
On Mon, Jan 19, 2015 at 01:59:32PM +0100, Florian Weimer wrote:
It
is an ABI change. IMHO very much undesirable. Just complain to people that
build their packages without it where it matters.
Some core libraries use off_t or struct stat in public header files, so we
already have the ABI
On Mon, Jan 19, 2015 at 3:03 PM, Florian Weimer fwei...@redhat.com wrote:
On 01/19/2015 03:08 PM, Peter Robinson wrote:
at least i doubt there is a noticeable userbase with i686 running
Fedora at all *and* would notice the drop noticeable
all of the OLPC XO 1.0 and 1.5 devices are running
On 01/19/2015 03:08 PM, Peter Robinson wrote:
at least i doubt there is a noticeable userbase with i686 running
Fedora at all *and* would notice the drop noticeable
all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that
userbase is in the millions, but would they notice the
Am 19.01.2015 um 15:28 schrieb Gerd Hoffmann:
Would that make it impossible to run fedora on sse-only i686 CPUs?
Yes, but test coverage for those CPUs is already rather poor, so I don't
expect them to work anymore.
See other replies, people are running such machines.
Given x86_64 exists
On 01/09/2015 12:54 PM, Jakub Jelinek wrote:
Also, the number of relocations and
memory consumption got up.
Non-PIE cc1plus:
Relocation section '.rela.dyn' at offset 0x187d30 contains 190 entries:
Relocation section '.rela.plt' at offset 0x188f00 contains 284 entries:
GNU_RELRO 0x1d14730
On 01/19/2015 01:17 PM, Alexander Ploumistos wrote:
On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com
mailto:fwei...@redhat.com wrote:
I wrote a slightly broader proposal, also covering SSE2 (for i386),
and (since today) off_t and ino_t:
On Mon, Jan 19, 2015 at 01:11:19PM +0100, Florian Weimer wrote:
On 01/09/2015 12:54 PM, Jakub Jelinek wrote:
Also, the number of relocations and
memory consumption got up.
Non-PIE cc1plus:
Relocation section '.rela.dyn' at offset 0x187d30 contains 190 entries:
Relocation section
Am 19.01.2015 um 13:17 schrieb Alexander Ploumistos:
On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com
mailto:fwei...@redhat.com wrote:
I wrote a slightly broader proposal, also covering SSE2 (for i386),
and (since today) off_t and ino_t:
On 01/19/2015 01:15 PM, Jakub Jelinek wrote:
No, because you need GCC 5 for that (ok, have scratch rpms now for that),
and very recent binutils (2.25 we have in F22 is not enough).
Ugh, this seems to suggests to defer the PIE change to Fedora 23. :-(
Would it still make sense to proceed with
On Mon, Jan 19, 2015 at 2:21 PM, Florian Weimer fwei...@redhat.com wrote:
Yes, but test coverage for those CPUs is already rather poor, so I don't
expect them to work anymore.
OK, thanks. Guess I'll have to switch my PIII and Athlon MP relics to
something like Gentoo or Arch.
--
devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 19 Jan 2015 12:58:06 +0100
Florian Weimer fwei...@redhat.com wrote:
On 01/07/2015 02:30 PM, Josh Boyer wrote:
We just went over something very much like this for x86_64 packages
with FESCo ticket 1113:
On 19.01.2015 13:21, Florian Weimer wrote:
On 01/19/2015 01:17 PM, Alexander Ploumistos wrote:
On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com
mailto:fwei...@redhat.com wrote:
I wrote a slightly broader proposal, also covering SSE2 (for i386),
and (since today)
On Mon, Jan 19, 2015 at 3:42 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 19.01.2015 um 15:28 schrieb Gerd Hoffmann:
Would that make it impossible to run fedora on sse-only i686 CPUs?
Yes, but test coverage for those CPUs is already rather poor, so I don't
expect them to work
Am 19.01.2015 um 21:34 schrieb drago01:
On Mon, Jan 19, 2015 at 3:42 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 19.01.2015 um 15:28 schrieb Gerd Hoffmann:
Would that make it impossible to run fedora on sse-only i686 CPUs?
Yes, but test coverage for those CPUs is already rather
On Mon, Jan 19, 2015 at 9:41 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 19.01.2015 um 21:34 schrieb drago01:
On Mon, Jan 19, 2015 at 3:42 PM, Reindl Harald h.rei...@thelounge.net
wrote:
Am 19.01.2015 um 15:28 schrieb Gerd Hoffmann:
Would that make it impossible to run fedora on
On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones rjo...@redhat.com wrote:
Does this proposal apply to native non-C/C++ programs?
Rich.
I would like to see this proposal apply to native non-C/C++ programs,
but I am not sure on how that would be done?
Do the other compilers understand what
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As written, it seems to intend so. In practice, it would probably apply or not
depending on whether the non-C/C++ programs’ builds are affected by
_hardened_build.
Ideally, I think this should apply to all
That said, even on x86_64 it isn't anything close to no overhead.
Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then
rebuild stage3 of GCC with make -j1 separately with the original stage3
cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN). The build (which
included still time
On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As written, it seems to intend so. In practice, it would probably
apply or not depending on whether the non-C/C++ programs’ builds are
On Mon, Jan 12, 2015 at 10:57:50AM -0800, Moez Roy wrote:
On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones rjo...@redhat.com wrote:
Does this proposal apply to native non-C/C++ programs?
Rich.
I would like to see this proposal apply to native non-C/C++ programs,
but I am not sure
On Tue, Jan 13, 2015 at 7:31 AM, Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Jan 12, 2015 at 10:50:07PM +0100, Till Maas wrote:
On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As
On Mon, Jan 12, 2015 at 10:50:07PM +0100, Till Maas wrote:
On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As written, it seems to intend so. In practice, it would probably
apply or
Hi,
I've been testing in advance to make mass rebuilds changing macros and the
results are pretty good (I mean x86_64 f20, f21 + grsecurity custom
kernels). It is clear that we will find regressions, we just have to start
and test it.. It is an important and necessary change.
If anyone is
On Thu, 2015-01-08 at 08:47 -0500, Paul Wouters wrote:
On Thu, 8 Jan 2015, Dhiru Kholia wrote:
| Your package accepts/processes untrusted input.
This seems to be about every package that I use, because I most if not
all tools process untrusted data from the Internet.
+1. This
On Sat, Jan 10, 2015 at 03:19:28PM +, Peter Robinson wrote:
On Thu, 2015-01-08 at 08:47 -0500, Paul Wouters wrote:
On Thu, 8 Jan 2015, Dhiru Kholia wrote:
| Your package accepts/processes untrusted input.
This seems to be about every package that I use, because I most if not
Does this proposal apply to native non-C/C++ programs?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings
On 01/09/2015 04:05 AM, Reindl Harald wrote:
*but* since *mobile phones* and other operating systems in the meantime are
full PIE and it improves security how can someone justify the reason
performance on a desktop/server distribution with much more powerful hardware?
Often the usage
On Fri, Jan 09, 2015 at 06:01:14PM +0100, Reindl Harald wrote:
I don't want to go the road where press articles say a specific bug
in software XYZ available for Linux, BSD and OSX would have only on
Fedora not been mitigated because we still discuss over performance
impacts while others
Am 09.01.2015 um 16:56 schrieb John Reiser:
On 01/09/2015 04:05 AM, Reindl Harald wrote:
*but* since *mobile phones* and other operating systems in the
meantime are full PIE and it improves security how can someone justify
the reason performance on a desktop/server distribution with much more
On Fri, 9 Jan 2015, Zbigniew Jędrzejewski-Szmek wrote:
...
Microbenchmarks get us only so far, we need to know the impact the
change makes for the whole system. We won't know that until enough
packages have been rebuilt.
https://www.alpinelinux.org/about/
The kernel is patched with
On Fri, Jan 09, 2015 at 06:45:47PM +0100, Dhiru Kholia wrote:
On Fri, 9 Jan 2015, Zbigniew Jędrzejewski-Szmek wrote:
...
Microbenchmarks get us only so far, we need to know the impact the
change makes for the whole system. We won't know that until enough
packages have been rebuilt.
Am 09.01.2015 um 12:54 schrieb Jakub Jelinek:
On i?86 it isn't around 10%, but more like 10%-30%.
i doubt that it's always 30% - real workloads matter not worst cases and
what are the 100% - if 100% is below a second 30% don't matter - there
are millions of tasks where even 50% would not
On Thu, Jan 08, 2015 at 01:45:20PM -0500, Miloslav Trmač wrote:
Hello,
= Proposed System Wide Change: Harden all packages with position-independent
code =
Harden all packages with position-independent code to limit the damage from
certain security vulnerabilities.
So this proposal is
On Fri, Jan 9, 2015 at 12:16 AM, Dennis Gilmore den...@ausil.us wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 08 Jan 2015 20:25:36 +0100
Reindl Harald h.rei...@thelounge.net wrote:
Am 08.01.2015 um 19:45 schrieb Miloslav Trmač:
= Proposed System Wide Change: Harden all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 08 Jan 2015 20:25:36 +0100
Reindl Harald h.rei...@thelounge.net wrote:
Am 08.01.2015 um 19:45 schrieb Miloslav Trmač:
= Proposed System Wide Change: Harden all packages with
position-independent code =
Harden all packages with
On Fri, Jan 9, 2015 at 12:44 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 09.01.2015 um 00:35 schrieb drago01:
On Fri, Jan 9, 2015 at 12:16 AM, Dennis Gilmore den...@ausil.us wrote:
On Thu, 08 Jan 2015 20:25:36 +0100
Reindl Harald h.rei...@thelounge.net wrote:
Am 08.01.2015 um
Am 09.01.2015 um 00:16 schrieb Dennis Gilmore:
On Thu, 08 Jan 2015 20:25:36 +0100
Reindl Harald h.rei...@thelounge.net wrote:
Am 08.01.2015 um 19:45 schrieb Miloslav Trmač:
= Proposed System Wide Change: Harden all packages with
position-independent code =
Harden all packages with
Am 09.01.2015 um 00:35 schrieb drago01:
On Fri, Jan 9, 2015 at 12:16 AM, Dennis Gilmore den...@ausil.us wrote:
On Thu, 08 Jan 2015 20:25:36 +0100
Reindl Harald h.rei...@thelounge.net wrote:
Am 08.01.2015 um 19:45 schrieb Miloslav Trmač:
= Proposed System Wide Change: Harden all packages
On Wed, 7 Jan 2015, Till Maas wrote:
On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote:
We just went over something very much like this for x86_64 packages
with FESCo ticket 1113:
https://fedorahosted.org/fesco/ticket/1113
Could you perhaps review that and elaborate on the
On Thu, 8 Jan 2015, Dhiru Kholia wrote:
| Your package accepts/processes untrusted input.
This seems to be about every package that I use, because I most if not
all tools process untrusted data from the Internet.
+1. This view is rapidly gaining traction and visibility in recent times.
On Thu, 2015-01-08 at 08:47 -0500, Paul Wouters wrote:
On Thu, 8 Jan 2015, Dhiru Kholia wrote:
| Your package accepts/processes untrusted input.
This seems to be about every package that I use, because I most if not
all tools process untrusted data from the Internet.
+1. This
On Thu, 8 Jan 2015, Stephen Gallagher wrote:
Can we throw prelink out as well when we do this?
Prelink is already gone. We haven't been running it since F19, IIRC.
Oh. Spending too much time on RHEL, and not enough time to upgrade my
desktop to a non-EOL fedora :)
Thanks,
Paul
--
devel
Hello,
= Proposed System Wide Change: Harden all packages with position-independent
code =
Harden all packages with position-independent code to limit the damage from
certain security vulnerabilities.
So this proposal is for _all_ architectures, including the register-starved
32-bit i?86
Am 08.01.2015 um 19:45 schrieb Miloslav Trmač:
= Proposed System Wide Change: Harden all packages with position-independent
code =
Harden all packages with position-independent code to limit the damage from
certain security vulnerabilities.
So this proposal is for _all_ architectures,
= Proposed System Wide Change: Harden all packages with position-independent
code =
https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code
Change owner(s): Till Maas opensou...@till.name, Moez Roy
moez@gmail.com
Harden all packages with
On Wed, Jan 7, 2015 at 5:30 AM, Josh Boyer jwbo...@fedoraproject.org
wrote:
We just went over something very much like this for x86_64 packages
with FESCo ticket 1113:
https://fedorahosted.org/fesco/ticket/1113
Could you perhaps review that and elaborate on the differences between
that
I originally made a request to rel-eng here:
https://fedorahosted.org/rel-eng/ticket/6049 -
Long running packages in F21 that 'MUST enable the PIE compiler flags'
Here https://fedoraproject.org/wiki/Packaging:Guidelines#PIE it says
If your package meets any of the following criteria you MUST
Am 07.01.2015 um 23:04 schrieb Till Maas:
On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote:
We just went over something very much like this for x86_64 packages
with FESCo ticket 1113:
https://fedorahosted.org/fesco/ticket/1113
Could you perhaps review that and elaborate on the
On Wed, 7 Jan 2015 13:17:36 -0800
Moez Roy moez@gmail.com wrote:
I originally made a request to rel-eng here:
https://fedorahosted.org/rel-eng/ticket/6049 -
Long running packages in F21 that 'MUST enable the PIE compiler flags'
...snip...
The above packages don't seem to have PIE
On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote:
We just went over something very much like this for x86_64 packages
with FESCo ticket 1113:
https://fedorahosted.org/fesco/ticket/1113
Could you perhaps review that and elaborate on the differences between
that proposal and this
On Wed, Jan 7, 2015 at 6:41 AM, Jaroslav Reznik jrez...@redhat.com wrote:
= Proposed System Wide Change: Harden all packages with position-independent
code =
https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code
Change owner(s): Till Maas
65 matches
Mail list logo
