On Thu, Jan 12, 2023 at 06:46:17PM -0500, Siddhesh Poyarekar wrote:
> On Thu, Jan 12, 2023 at 6:38 PM Jakub Jelinek wrote:
> > But at least you don't need both -U_FORTIFY_SOURCE and
> > -Wp,-U_FORTIFY_SOURCE, one of them is enough. And the latter I think
> > better gets through libtool and other
On Thu, Jan 12, 2023 at 6:38 PM Jakub Jelinek wrote:
> But at least you don't need both -U_FORTIFY_SOURCE and
> -Wp,-U_FORTIFY_SOURCE, one of them is enough. And the latter I think
> better gets through libtool and other tools; especially if you put it
> into a single -Wp, option together with
On Thu, Jan 12, 2023 at 06:29:10PM -0500, Siddhesh Poyarekar wrote:
> On Thu, Jan 12, 2023 at 12:41 PM Jakub Jelinek wrote:
> > > I've filed a ccache bug. It looks like ccache is moving the compiler
> > > arguments around, causing one of the -U_FORTIFY_SOURCE to the end.
> > >
> > >
On Thu, Jan 12, 2023 at 12:41 PM Jakub Jelinek wrote:
> > I've filed a ccache bug. It looks like ccache is moving the compiler
> > arguments around, causing one of the -U_FORTIFY_SOURCE to the end.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2160275
>
> Why we do have those
On Wed, Jan 11, 2023 at 06:44:22PM -0500, Siddhesh Poyarekar wrote:
> On Wed, Jan 11, 2023 at 4:43 PM Siddhesh Poyarekar
> wrote:
> > On Wed, Jan 11, 2023 at 4:37 PM Siddhesh Poyarekar
> > wrote:
> > >
> > > On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim
> > > wrote:
> > > > Just
On Wed, Jan 11, 2023 at 4:43 PM Siddhesh Poyarekar wrote:
> On Wed, Jan 11, 2023 at 4:37 PM Siddhesh Poyarekar
> wrote:
> >
> > On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim
> > wrote:
> > > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm`
> > >
> > > I have these additional knobs in
On Wed, Jan 11, 2023 at 4:37 PM Siddhesh Poyarekar wrote:
>
> On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim
> wrote:
> > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm`
> >
> > I have these additional knobs in ~/.config/mock.cfg:
> >
> >
> > config_opts['plugin_conf']['ccache_enable']
On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim
wrote:
> Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm`
>
> I have these additional knobs in ~/.config/mock.cfg:
>
>
> config_opts['plugin_conf']['ccache_enable'] = True
> config_opts['plugin_conf']['ccache_opts']['max_cache_size'] = '10G'
On Wed, 2023-01-11 at 14:29 -0500, Siddhesh Poyarekar wrote:
> On Wed, Jan 11, 2023 at 1:15 PM Michel Alexandre Salim
> wrote:
> > The warning seems to happen only in mock, the Koji build is clean:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=96015653
> >
> > Let me paste the root.log
On Wed, Jan 11, 2023 at 1:15 PM Michel Alexandre Salim
wrote:
> The warning seems to happen only in mock, the Koji build is clean:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=96015653
>
> Let me paste the root.log and build.log from the local build (I'm now
> working on upgrading a
On Wed, Jan 11, 2023 at 01:04:45PM -0500, Siddhesh Poyarekar wrote:
> On Wed, Jan 11, 2023 at 12:45 PM Michel Alexandre Salim
> wrote:
> > Is this supported yet? I'm doing a build of rubberband for Rawhide, and
> > every file generates this warning:
> >
> > ../src/test/TestStretcher.cpp: warning:
On Wed, Jan 11, 2023 at 12:45 PM Michel Alexandre Salim
wrote:
> Is this supported yet? I'm doing a build of rubberband for Rawhide, and
> every file generates this warning:
>
> ../src/test/TestStretcher.cpp: warning: -D_FORTIFY_SOURCE defined but
> value is too low
Yes the change is in, it even
On Mon, 2022-12-05 at 14:58 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community
On 14/12/2022 00:53, Michael Catanzaro via devel wrote:
Thank you _very much_ Neal, Fabio, and Zbigniew for your efforts to revisit
that decision.
This proposal was rejected and you don't like it. So please please stop
attacking other people.
--
Sincerely,
Vitaly Zaitsev
> Anyway, the effort that
> went into that change proposal has established new expectations for any
> change that will
> impact system performance: the new flags should be benchmarked in an
> environment where all
> Fedora packages have been rebuilt with the new flags, so we can critique the
>
On Tue, Dec 6, 2022 at 10:41 AM Siddhesh Poyarekar wrote:
>
> On Tue, Dec 6, 2022 at 10:26 AM Gary Buhrmaster
> wrote:
> >
> > On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar
> > wrote:
> >
> > > My full comment in that blog post is:
> > >
> > > "We need a proper study of performance and
On Wed, Dec 07, 2022 at 04:41:09PM -0500, Siddhesh Poyarekar wrote:
> On Wed, Dec 7, 2022 at 3:15 PM Andrii Nakryiko
> wrote:
> >
> > > On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko
> > > > >
> > > I don't think the two are comparable at all, neither in terms of
> > > potential performance
[Responding from alias that's actually registered to devel@]
On Thu, Dec 8, 2022 at 8:25 AM Siddhesh Poyarekar wrote:
>
> On Mon, Dec 5, 2022 at 3:04 PM Ben Cotton wrote:
> >
> > On Mon, Dec 5, 2022 at 2:58 PM Ben Cotton wrote:
> > >
> > > * Release engineering: Mass rebuild required
> >
> >
On 12/6/22 14:02, Richard W.M. Jones wrote:
> On Tue, Dec 06, 2022 at 05:52:16PM -, Andrii Nakryiko wrote:
>>> On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote:
>>>
>>> Note that is not a fully equivalent scenario. The no-omit-frame-pointer
>>> proposal was only offering a
On Wed, Dec 7, 2022 at 3:15 PM Andrii Nakryiko
wrote:
>
> > On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko
> > >
> > I don't think the two are comparable at all, neither in terms of
> > potential performance impact (register pressure across an entire
> > program vs at specific API call points
> On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko
>
> I don't think the two are comparable at all, neither in terms of
> potential performance impact (register pressure across an entire
> program vs at specific API call points in some unique cases) nor in
> terms of the benefits it provides.
> Andrii,
>
> copilot to pilot, you are responding to Jakub Jelinek's points, not
Copilot? Pilot? I don't understand this euphemism. And yes, I'm well aware who
I'm replying to, thank you.
> Neal's. Jakub is a compiler/toolchain engineer with considerable
And not sure why you are implying
> On Tue, Dec 06, 2022 at 05:46:11PM -, Andrii Nakryiko wrote:
>
> Depends on how large functions are. If you have lots of small functions,
> it can be more than 50% of instructions you get the frame pointer wrong.
You might be technically correct, but if some application is spending 50% of
On Wed, Dec 07, 2022 at 09:02:36AM +0100, Vitaly Zaitsev via devel wrote:
> On 06/12/2022 23:20, Michael Catanzaro via devel wrote:
> > Even if extra bounds checking makes code 10% slower, which seems very
> > unlikely, the benefit of the extra hardening would still be worth it.
> >
On 06/12/2022 23:20, Michael Catanzaro via devel wrote:
Even if extra bounds checking makes code 10% slower, which seems very unlikely,
the benefit of the extra hardening would still be worth it. _FORTIFY_SOURCE=3
is going to make it harder to hack Fedora users, converting code execution
No. He probably doesn't even know about this proposal yet, since it was just
published yesterday. This is not the sort of thing that matters for desktop
performance, where we care about orders of magnitude rather than a few percent
improvement here or there. Even if extra bounds checking makes
On Tue, Dec 6, 2022 at 7:04 PM Michael Catanzaro via devel
wrote:
> Red Hat's desktop performance engineer
Since you bring up RH's performance engineer,
have they done performance evaluation on
_FORTIFY_SOURCE=3? And while I understand
that until the eval is reviewed and reproduced no
Red Hat's desktop performance engineer has repeatedly rejected use of DWARF as
impractical and outlandish, including on this mailing list [1] and most
recently at [2].
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UV65DSMPINEE6KWNI5MBH3MBQ26JHNNJ/
[2]
On Tue, Dec 06, 2022 at 05:52:16PM -, Andrii Nakryiko wrote:
> > On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote:
> >
> > Note that is not a fully equivalent scenario. The no-omit-frame-pointer
> > proposal was only offering a functional debugging benefit to a fairly
> > small
On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko
wrote:
> > On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
> > >
> > My full comment in that blog post is:
> >
> > "We need a proper study of performance and code size to understand the
> > magnitude of the impact created by _FORTIFY_SOURCE=3
Andrii,
copilot to pilot, you are responding to Jakub Jelinek's points, not
Neal's. Jakub is a compiler/toolchain engineer with considerable
experience, so when he talks about compiler technology involved in
tracing execution flow, I am inclined to believe him.
I understand that your
On Tue, Dec 06, 2022 at 05:46:11PM -, Andrii Nakryiko wrote:
> Now, about prologues/epilogues. What percentage of useful workload is spent
> in those? Tiny fraction of a percent at best? Even if we don't get accurate
> stack trace in such cases it doesn't matter in the grand scheme of
> On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
>
> My full comment in that blog post is:
>
> "We need a proper study of performance and code size to understand the
> magnitude of the impact created by _FORTIFY_SOURCE=3 additional
> runtime code generation. However the performance and code
> On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote:
>
> Note that is not a fully equivalent scenario. The no-omit-frame-pointer
> proposal was only offering a functional debugging benefit to a fairly
> small number of users who are also developers, while adding a likely
>
> On Tue, Dec 06, 2022 at 08:13:51AM -0500, Neal Gompa wrote:
>
> That is nonsense. Even with -fno-omit-frame-pointers, you can't rely
> on frame pointers, they are not accurate in function prologues and epilogues
> and they are total garbage e.g. in a lot of functions written in assembly.
Hi,
first off, sorry if my write-up seemed a bit harsh, this was the last
time I am trying to respond to a change proposal late at night :).
On 12/6/22 14:14, Siddhesh Poyarekar wrote:
On Mon, Dec 5, 2022 at 7:35 PM Jaroslav Prokop wrote:
Default C and C++ compiler flags to build packages
On Tue, Dec 6, 2022 at 3:42 PM Siddhesh Poyarekar wrote:
> I have added a performance note[1] in the proposal.
Thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On Tue, Dec 6, 2022 at 10:26 AM Gary Buhrmaster
wrote:
>
> On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar wrote:
>
> > My full comment in that blog post is:
> >
> > "We need a proper study of performance and code size to understand the
> > magnitude of the impact created by _FORTIFY_SOURCE=3
On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar wrote:
> My full comment in that blog post is:
>
> "We need a proper study of performance and code size to understand the
> magnitude of the impact created by _FORTIFY_SOURCE=3 additional
> runtime code generation. However the performance and
On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
wrote:
>
> On Tue, Dec 6, 2022 at 12:47 PM Siddhesh Poyarekar
> wrote:
>
> > Overall even if there is a miniscule performance overhead, I
> > reckon the reward is much higher.
>
> I am curious how you can claim there is only a
> minuscule
On Tue, Dec 6, 2022 at 12:47 PM Siddhesh Poyarekar wrote:
> Overall even if there is a miniscule performance overhead, I
> reckon the reward is much higher.
I am curious how you can claim there is only a
minuscule performance overhead without doing
any benchmarks?
I am not claiming the
On Tue, Dec 6, 2022 at 9:55 AM Siddhesh Poyarekar wrote:
>
> On Tue, Dec 6, 2022 at 8:14 AM Siddhesh Poyarekar wrote:
> > > Please provide a proper "how to test" section, I cannot fix what I cannot
> > > test or compare results when I have no idea what I am seeing.
> > >
> > > Actually, last
On Tue, Dec 6, 2022 at 8:14 AM Siddhesh Poyarekar wrote:
> > Please provide a proper "how to test" section, I cannot fix what I cannot
> > test or compare results when I have no idea what I am seeing.
> >
> > Actually, last time I heard about number of packages, it was around 50k
> > (not
On Tue, Dec 6, 2022 at 5:45 AM Jakub Jelinek wrote:
>
> On Tue, Dec 06, 2022 at 11:13:38AM +0100, Vitaly Zaitsev via devel wrote:
> > On 05/12/2022 20:58, Ben Cotton wrote:
> > > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
> > > improve mitigation of security issues
On Tue, Dec 06, 2022 at 08:13:51AM -0500, Neal Gompa wrote:
> "may improve" is proven to be "does improve significantly". We had
That is nonsense. Even with -fno-omit-frame-pointers, you can't rely
on frame pointers, they are not accurate in function prologues and epilogues
and they are total
On Tue, Dec 6, 2022 at 4:05 AM Richard W.M. Jones wrote:
>
> On Tue, Dec 06, 2022 at 01:35:04AM +0100, Jaroslav Prokop wrote:
> > On 12/5/22 20:58, Ben Cotton wrote:
> >
> > The core change to bring in this mitigation is to change the default
> > build flags in `redhat-rpm-config` so that
On Mon, Dec 5, 2022 at 10:20 PM Gary Buhrmaster
wrote:
>
> On Mon, Dec 5, 2022 at 10:53 PM Neal Gompa wrote:
>
> > It has a similar impact that turning back on frame pointers would.
> >
> > Cf.
> >
On Mon, Dec 5, 2022 at 7:35 PM Jaroslav Prokop wrote:
> Default C and C++ compiler flags to build packages in Fedora currently
> includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of
> some functions in glibc, thus providing some mitigation against buffer
> overflows. Since glibc
On Tue, Dec 6, 2022 at 7:50 AM Siddhesh Poyarekar wrote:
>
> On Mon, Dec 5, 2022 at 5:53 PM Neal Gompa wrote:
> >
> > On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
> > wrote:
> > >
> > > On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote:
> > > >
> > > >
On Mon, Dec 5, 2022 at 5:53 PM Neal Gompa wrote:
>
> On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
> wrote:
> >
> > On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> > >
> >
> > It is my
On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
wrote:
>
> On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> >
>
> It is my vague recollection (I could easily be wrong, so
> correct me as
On Tue, Dec 06, 2022 at 11:13:38AM +0100, Vitaly Zaitsev via devel wrote:
> On 05/12/2022 20:58, Ben Cotton wrote:
> > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
> > improve mitigation of security issues arising from buffer overflows in
> > packages in Fedora.
>
> AFAIK,
On 05/12/2022 20:58, Ben Cotton wrote:
Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
improve mitigation of security issues arising from buffer overflows in
packages in Fedora.
AFAIK, _FORTIFY_SOURCE=3 enables runtime checks for every mem*()
function call. This should
On 12/6/22 10:08, Richard W.M. Jones wrote:
On Tue, Dec 06, 2022 at 08:59:03AM +, Richard W.M. Jones wrote:
I don't believe the proposal is that everyone *has* to use this (or at
least, I hope not). Even existing _FORTIFY_SOURCE=2 is optional. I'd
like to know what the problems are that
On Tue, Dec 06, 2022 at 08:59:03AM +, Richard W.M. Jones wrote:
> I don't believe the proposal is that everyone *has* to use this (or at
> least, I hope not). Even existing _FORTIFY_SOURCE=2 is optional. I'd
> like to know what the problems are that affect systemd however.
It's mentioned in
On Tue, Dec 06, 2022 at 01:35:04AM +0100, Jaroslav Prokop wrote:
> On 12/5/22 20:58, Ben Cotton wrote:
>
> The core change to bring in this mitigation is to change the default
> build flags in `redhat-rpm-config` so that packages build by default
> with `-Wp,-D_FORTIFY_SOURCE=3`.
On Tue, Dec 06, 2022 at 08:19:22AM +, Daniel P. Berrangé wrote:
> On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote:
> > On Mon, Dec 5, 2022 at 10:53 PM Neal Gompa wrote:
> >
> > > It has a similar impact that turning back on frame pointers would.
> > >
> > > Cf.
> > >
On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote:
> On Mon, Dec 5, 2022 at 10:53 PM Neal Gompa wrote:
>
> > It has a similar impact that turning back on frame pointers would.
> >
> > Cf.
> >
On Mon, Dec 5, 2022 at 10:53 PM Neal Gompa wrote:
> It has a similar impact that turning back on frame pointers would.
>
> Cf.
> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improved_security_coverage_outweigh_the_cost
>
That article explicitly
Hi,
This is underwhelming and I have several questions inline
On 12/5/22 20:58, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
This document represents a proposed Change. As part of the Changes
process, proposals are publicly
On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
wrote:
>
> On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> >
>
> It is my vague recollection (I could easily be wrong, so
> correct me as
On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
>
It is my vague recollection (I could easily be wrong, so
correct me as appropriate) that _FORTIFY_SOURCE=3
adds some runtime overhead that did not
On Mon, Dec 5, 2022 at 2:58 PM Ben Cotton wrote:
>
> * Release engineering: Mass rebuild required
Please file a ticket with Release Engineering if you haven't already.
> == Contingency Plan ==
> * Contingency mechanism: (What to do? Who will do it?) If too many
> packages are found to be
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the
65 matches
Mail list logo
