|
|
| Line 1: |
Line 1: |
| <!-- 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 isolated/leaf package without the impact on other
| |
| packages/rest of the distribution
| |
| * limited scope changes without the impact on other packages/rest of
| |
| the distribution
| |
| * coordinated effort within SIG with limited impact outside SIG
| |
| functional area, accepted by the SIG
| |
|
| |
| System Wide Changes are:
| |
| * changes that does not fit Self Contained Changes category touching
| |
| * changes that require coordination within the distribution (for
| |
| example mass rebuilds, release engineering or other teams effort etc.)
| |
| * changing system defaults
| |
|
| |
| 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 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
| |
| the change proposal pages are uniform.
| |
| -->
| |
|
| |
| <!-- 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 -->
| |
|
| |
| = Changes/Annotated Binaries
| |
|
| |
| == Summary ==
| |
| <!-- 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. -->
| |
|
| |
| 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 ==
| |
| <!-- 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.
| |
|
| |
| This should link to your home wiki page so we know who you are.
| |
| -->
| |
|
| |
| * 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. -->
| |
|
| |
| * Email: nickc@redhat.com
| |
|
| |
| * 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)
| |
| * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
| |
| -->
| |
|
| |
| <!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
| |
| * Product:
| |
| * Responsible WG:
| |
| -->
| |
|
| |
| == Current status ==
| |
| * Targeted release: [[Releases/28 | Fedora 28 ]]
| |
| * 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. Bugzilla states meaning
| |
| as usual:
| |
| NEW -> change proposal is submitted and announced
| |
| ASSIGNED -> accepted by FESCo with on going development
| |
| MODIFIED -> change is substantially done and testable
| |
| 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>
| |
|
| |
| == Detailed Description ==
| |
|
| |
| <!-- Expand on the summary, if appropriate. A couple sentences
| |
| suffices to explain the goal, but the more details you can provide the
| |
| better. -->
| |
|
| |
| 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
| |
| 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 ==
| |
|
| |
| <!-- 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?-->
| |
|
| |
| 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 ==
| |
| * Proposal owners:
| |
| <!-- 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:
| |
|
| |
| <!-- What work do other developers 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?-->
| |
|
| |
| An update is needed to the redhat-rpm-config package in order for the
| |
| 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)
| |
| <!-- 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. -->
| |
|
| |
| == Upgrade/compatibility impact ==
| |
| <!-- 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? -->
| |
|
| |
| <!-- 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 ==
| |
| <!-- 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.
| |
|
| |
| 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.
| |
|
| |
| A good "how to test" should answer these four questions:
| |
|
| |
| 0. What special hardware / data / etc. is needed (if any)?
| |
| 1. How do I prepare my system to test this change? What packages
| |
| need to be installed, config files edited, etc.?
| |
| 2. What specific actions do I perform to check that the change is
| |
| working like it's supposed to?
| |
| 3. What are the expected results of those actions?
| |
| -->
| |
|
| |
| Special hardware is not needed, but the plugin used to record the
| |
| information is architecture specific. Thus it would be a good idea to
| |
| run the tests on as many different architectures as are available.
| |
|
| |
| 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 ==
| |
| <!-- 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. -->
| |
| <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| N/A (This is a system wide change, but it should have no user visible
| |
| impact apart from slightly larger rpms).
| |
|
| |
| == Dependencies ==
| |
| <!-- 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)? -->
| |
|
| |
| <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| annobin, gcc, gcc-plugin-devel, pkgconfig, redhat-rpm-config
| |
|
| |
| == Contingency Plan ==
| |
|
| |
| <!-- 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. -->
| |
|
| |
| * Contingency mechanism: Revert change to redhat-rpm-macros <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
|
| |
| <!-- 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 ==
| |
| <!-- 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. -->
| |
|
| |
| <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| The annotation scheme is documented here:
| |
|
| |
| https://fedoraproject.org/wiki/Toolchain/Watermark
| |
|
| |
| == Release Notes ==
| |
| <!-- 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 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.
| |
|
| |
| 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
| |
| change.
| |
|
| |
| [[Category:ChangeReadyForWrangler]]
| |
| <!-- When your change proposal page is completed and ready for review and announcement -->
| |
| <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
| |
| <!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
| |
| <!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
| |
|
| |
| <!-- Select proper category, default is Self Contained Change -->
| |
| <!-- [[Category:SelfContainedChange]] -->
| |
| [[Category:SystemWideChange]]
| |
