From Fedora Project Wiki
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...")
 
(Mention that -z defs was reverted)
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<!-- Self Contained or System Wide Change Proposal?
<!-- Self Contained or System Wide Change Proposal?
Use this guide to determine to which category your proposed change
Use this guide to determine to which category your proposed change belongs to.
belongs to.


Self Contained Changes are:
Self Contained Changes are:
* changes to isolated/leaf package without the impact on other
* changes to isolated/leaf package without the impact on other packages/rest of the distribution
  packages/rest of the distribution  
* limited scope changes without the impact on other packages/rest of the distribution
* limited scope changes without the impact on other packages/rest of
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG
  the distribution  
* coordinated effort within SIG with limited impact outside SIG
  functional area, accepted by the SIG  


System Wide Changes are:
System Wide Changes are:
* changes that does not fit Self Contained Changes category touching
* changes that does not fit Self Contained Changes category touching  
* changes that require coordination within the distribution (for
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)
  example mass rebuilds, release engineering or other teams effort etc.)  
* changing system defaults
* changing system defaults


For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is  
WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies).  
(especially in case the change proposal category is improper or
updated to System Wide category). For System Wide Changes all fields
on this form are required for FESCo acceptance (when applies).


We request that you maintain the same order of sections so that all of
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.
the change proposal pages are uniform.
-->
-->


<!-- The actual name of your proposed change page should look
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
something like: Changes/Your_Change_Proposal_Name.  This keeps all
= Binutils version 2.29.1 <!-- The name of your change proposal --> =
change proposals in the same namespace -->
 
= Changes/Annotated Binaries


== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this change is and what it
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
    will do. This information is used for the overall changeset summary
Rebase the binutils package from version 2.29 to version 2.29.1.   
    page for each release. -->  
This will bring in the bug-fixes from the 2.29.1 point release, but not add any new features.
 
This change causes extra information to be stored in binary files
compiled by gcc.  This information can be used by scripts to check on
various features of the file, such as the hardening options used of
potential ABI conflicts.


== Owner ==
== Owner ==
<!-- For change proposals to qualify as self-contained, owners of all
<!--  
affected packages need to be included here. Alternatively, a SIG can
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.  
be listed as an owner if it owns all affected packages.
 
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
 
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Name: [[User:nickc| Nick Clifton]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
 
<!-- Include you email address that you can be reached should people
want to contact you about helping with your change, status is
requested, or technical issues need to be resolved. If the change
proposal is owned by a SIG, please also add a primary contact
person. -->
 
* Email: nickc@redhat.com
* Email: nickc@redhat.com
 
* Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/101 #101]
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
 
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
-->
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
* Product:
* Product:
Line 73: Line 44:


== Current status ==
== Current status ==
* Targeted release: [[Releases/28 | Fedora 28 ]]
* Targeted release: Fedora 28
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
 
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is
Bugzilla states meaning as usual:
created in Bugzilla and linked to this page.  Bugzilla states meaning
NEW -> change proposal is submitted and announced
as usual:
ASSIGNED -> accepted by FESCo with on going development
  NEW -> change proposal is submitted and announced
MODIFIED -> change is substantially done and testable
  ASSIGNED -> accepted by FESCo with on going development
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)
  MODIFIED -> change is substantially done and testable
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
  ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)
  CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1537263 #1537263]


== Detailed Description ==
== Detailed Description ==


<!-- Expand on the summary, if appropriate.  A couple sentences
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
suffices to explain the goal, but the more details you can provide the
Switch the binutils package from being based on the 2.29 release of the FSF binutils to
better. -->
being based on the 2.29.1 release.  This release was a collection of important bug fixes
 
over the 2.29 release, but no new features were introduced.
The plan is to use a plugin to gcc to record extra information in the
object files it creates.  This information can then be examined by
static analysis tools.  The information is recorded in a compact,
extensible format, described here:
 
  https://fedoraproject.org/wiki/Toolchain/Watermark


The Fedora annobin package is an implementation of the plugin for
In addition, the default build flags will be changed to include <code>-z defs</code>, so that undefined symbols result in errors. The benefit is that this prevents shipping DSOs which are not correctly linked because refer to versioned symbols as plain undefined symbols, without specifying a symbol version.
gcc.  It also includes some example scripts that demonstrate how the
recorded information can be used to, for example, check that an
executable has been compiled with the correct hardening options, or
detect if any conflicting ABI options have been used when compiling
various parts of the executable.
 
To enable this change it is proposed that the redhat-rpm-config
package should be extended to add the "-fplugin=annobin" option to the
__global_compiler-flags macro.  In theory such a change will be
completely invisible to Fedora users but should prove to be very
helpful to Fedora Release Management, assuming that they like the idea
of these annotated binaries.


== Benefit to Fedora ==
== Benefit to Fedora ==


<!-- What is the benefit to the platform?  If this is a major
Fewer bugs in the linker and assembler.
capability update, what has changed?  If this is a new functionality,
what capabilities does it bring? Why will Fedora become a better
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
distribution or project because of this proposal?-->
 
The main improvement is the ability to record extra information in a
binary file, beyond the actual code and data needed to make it work.
 
Whilst this proposal focuses on enhancement that help release
engineering, the scheme is not limited to this area.  Internally the
project has already been used to record gcc unit test results in a
binary, so that it is possible to determine which parts of the
compiler ran when the binary was created.


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners: Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed.
<!-- What work do the feature owners have to accomplish to complete
the feature in time for release?  Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
 
The annobin plugin is ready.


* Other developers:
* Other developers:
** For the rebase: In theory none - the change should be completely transparent.  In practice since the binutils are part of the C/C++ compiler toolchain there is the possibility that the change introduces a new bug which affects other packages.
** For the <code>-z defs</code> flags change (which will be implemented in <code>redhat-rpm-config</code>):
*** Add missing DSOs or avoid using compatibility symbols.
*** Use <code>-z undefs</code> if the DSO links against a main program at run time, where undefined symbols are expected.
*** See [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md Using RPM build flags] for details.


<!-- What work do other developers have to accomplish to complete the
* Release engineering: https://pagure.io/releng/issue/7251
feature in time for release?  Is it a large change affecting many
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
parts of the distribution or is it a very isolated change? What are
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
those changes?-->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Just the binutils packages.


An update is needed to the redhat-rpm-config package in order for the
* Policies and guidelines: No updates needed.
plugin to be invoked when gcc is used to compile programs, and to add
a dependency upon the annobin package.
 
* Release engineering: [https://pagure.io/releng/issues/7069] <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
 
<!-- Does this feature require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery)?  Is a mass rebuild required?  Include a link to the releng
issue.
 
The issue is required to be filed prior to feature submission, to
ensure that someone is on board to do any process development work and
testing, and that all changes make it into the pipeline; a bullet
point in a change is not sufficient communication -->
 
Coordination with release engineering is needed.
 
A mass rebuild will be required.
 
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{next}}|List of deliverables]]: All! <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Please check the list of Fedora release deliverables and list all
the differences the feature brings -->
 
* Policies and guidelines: No updates needed <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated
for this feature?  If so, does it need to happen before or after the
implementation is done?  If a FPC ticket exists, add a link here. -->


* Trademark approval: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
is a new Spin), file a ticket ( https://fedorahosted.org/council/ )
requesting trademark approval from the Fedora Council. This approval
will be done via the Council's consensus-based process. -->


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
Fedora installed and are updated to the version containing this
The binutils are backwards compatible with previous releases, so no changes should be necessary.
change? Will anything require manual configuration or data migration?
Will any existing functionality be no longer supported? -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
On systems where the redhat-rpm-config package is installed the
annobin package will now be a requirement.
 
There should be no other migration issues, apart from the possible
issue of the size of rpms increasing, due to the extra information
being recorded.


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
dimensions of tests that this change implementation is expected to
pass when it is done.  If it needs to be tested with different
hardware or software configurations, indicate them.  The more specific
you can be, the better the community testing can be.


Remember that you are writing this how to for interested testers to
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
use to check out your change implementation - documenting what you do
for testing is OK, but it's much better to document what *I* can do to
test your change.


A good "how to test" should answer these four questions:
A good "how to test" should answer these four questions:
Line 217: Line 110:
-->
-->


Special hardware is not needed, but the plugin used to record the
The binutils package does include its own set of testsuites which check basic functionality.
information is architecture specific.  Thus it would be a good idea to
The real test however is by rebuilding other packages which depend upon the binutils, or
run the tests on as many different architectures as are available.
more likely, upon gcc.  If these packages continue to work then the binutils update has not
 
broken anything.
In order to run tests the annobin package will need to be installed.
You will also need to be able to compile files, so the gcc package
will also be needed.  There should be no need to edit any config
files.
 
To check that the feature is working, compile the file(s) (or build
the packages) that form the basis of your test.  Make sure that the
-fplugin=annobin gcc command line option is being used when the files
are compiled.  Then check the compiled files to see what information
has been recorded.  The command line:
 
  readelf --notes --wide <name-of-file>
 
should achieve this aim.
 
The annobin package does include some tests of its own, and these can
be used as examples of how to create more tests.


== User Experience ==
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
will their experiences change as a result?  Describe what they will
see or notice. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (This is a system wide change, but it should have no user visible
The change should not be noticeable to the user.
impact apart from slightly larger rpms).


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
changes outside the developers' control on which completion of this
This update has no hard dependencies on any other package.
change depends?  In other words, completion of another change owned by
There are other packages that do depend upon the binutils however.  Most notably gcc.
someone else and might cause you to not be able to finish on time or
that you would need to coordinate?  Other upstream projects like the
kernel (if this is not a kernel change)? -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
annobin, gcc, gcc-plugin-devel, pkgconfig, redhat-rpm-config


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
freeze, what is the backup plan?  This might be as simple as "Revert
* Contingency mechanism: Revert to the 2.29 binutils as used in Fedora 27. This work can be done by me, should it prove necessary.
the shipped configuration".  Or it might not (e.g. rebuilding a number
** The contingency mechanism was invoked for the <code>-z defs</code> change, which was reverted.
of dependent packages).  If you feature is not completed in time we
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
want to assure others that other parts of Fedora will not be in
* Contingency deadline: Beta Freeze.
jeopardy.  -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
 
* Blocks release? No
* Contingency mechanism: Revert change to redhat-rpm-macros <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? None
 
<!-- When is the last time the contingency mechanism can be put in
place?  This will typically be the beta freeze. -->
 
* Contingency deadline: beta Freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- Does finishing this feature block the release, or can we ship
with the feature in incomplete state? -->
 
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
written yourself?  Link to that material here so other interested
developers can get involved. -->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
The 2.29.1 release was announced here:
The annotation scheme is documented here:
https://www.sourceware.org/ml/binutils/2017-09/msg00311.html
 
Unfortunately there is no list of the bugs that have been fixed in this release.
  https://fedoraproject.org/wiki/Toolchain/Watermark
A scan of the sources however indicates that the following FSF binutils bugzilla PRs were fixed:
20125
21433
21441
21782
21813
21820
21849
21861
21884
21909
21923
21924
21939
21961
21964
21990
21994
21995
22061
22064


== Release Notes ==
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
the release.  Examples of past release notes are here:
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.
http://docs.fedoraproject.org/release-notes/ -->


<!-- The release notes also help users know how to deal with platform
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
changes such as ABIs/APIs, configuration or data file formats, or
upgrade concerns.  If there are any such changes involved in this
change, indicate them here.  A link to upstream documentation will
often satisfy this need.  This information forms the basis of the
release notes edited by the documentation team and shipped with the
release.
 
Release Notes are not required for initial draft of the Change
Proposal but has to be completed by the Change Freeze.
-->
-->


In theory no release notes are needed as this is not a user visible
[[Category:ChangeAcceptedF28]]
change.
 
[[Category:ChangeReadyForWrangler]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 318: Line 178:


<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
<!-- [[Category:SelfContainedChange]] -->
[[Category:SystemWideChange]]
[[Category:SystemWideChange]]

Latest revision as of 16:23, 9 March 2018


Binutils version 2.29.1

Summary

Rebase the binutils package from version 2.29 to version 2.29.1. This will bring in the bug-fixes from the 2.29.1 point release, but not add any new features.

Owner

  • Name: Nick Clifton [1]
  • Email: nickc@redhat.com
  • Release notes ticket: #101

Current status

  • Targeted release: Fedora 28
  • Last updated: 2018-03-09
  • Tracker bug: #1537263

Detailed Description

Switch the binutils package from being based on the 2.29 release of the FSF binutils to being based on the 2.29.1 release. This release was a collection of important bug fixes over the 2.29 release, but no new features were introduced.

In addition, the default build flags will be changed to include -z defs, so that undefined symbols result in errors. The benefit is that this prevents shipping DSOs which are not correctly linked because refer to versioned symbols as plain undefined symbols, without specifying a symbol version.

Benefit to Fedora

Fewer bugs in the linker and assembler.


Scope

  • Proposal owners: Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed.
  • Other developers:
    • For the rebase: In theory none - the change should be completely transparent. In practice since the binutils are part of the C/C++ compiler toolchain there is the possibility that the change introduces a new bug which affects other packages.
    • For the -z defs flags change (which will be implemented in redhat-rpm-config):
      • Add missing DSOs or avoid using compatibility symbols.
      • Use -z undefs if the DSO links against a main program at run time, where undefined symbols are expected.
      • See Using RPM build flags for details.
  • Policies and guidelines: No updates needed.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The binutils are backwards compatible with previous releases, so no changes should be necessary.

How To Test

The binutils package does include its own set of testsuites which check basic functionality. The real test however is by rebuilding other packages which depend upon the binutils, or more likely, upon gcc. If these packages continue to work then the binutils update has not broken anything.

User Experience

The change should not be noticeable to the user.

Dependencies

This update has no hard dependencies on any other package. There are other packages that do depend upon the binutils however. Most notably gcc.

Contingency Plan

  • Contingency mechanism: Revert to the 2.29 binutils as used in Fedora 27. This work can be done by me, should it prove necessary.
    • The contingency mechanism was invoked for the -z defs change, which was reverted.
  • Contingency deadline: Beta Freeze.
  • Blocks release? No
  • Blocks product? None

Documentation

The 2.29.1 release was announced here: https://www.sourceware.org/ml/binutils/2017-09/msg00311.html Unfortunately there is no list of the bugs that have been fixed in this release. A scan of the sources however indicates that the following FSF binutils bugzilla PRs were fixed: 20125 21433 21441 21782 21813 21820 21849 21861 21884 21909 21923 21924 21939 21961 21964 21990 21994 21995 22061 22064

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/BINUTILS2291&oldid=512439"