Bug 1548700 - kernel: Guidance needed for “scripts” tools
Summary: kernel: Guidance needed for “scripts” tools
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: Fedora28BuildFlags
TreeView+ depends on / blocked
 
Reported: 2018-02-24 12:33 UTC by Florian Weimer
Modified: 2018-07-12 23:33 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-12 23:32:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Florian Weimer 2018-02-24 12:33:39 UTC
kernel-debug-devel and kernel-devel install executable ELF files in this directory:

/usr/src/kernels/*/scripts

These programs are not built with the standard Fedora build flags coming from redhat-rpm-config.  For example, /usr/src/kernels/4.16.0-0.rc2.git0.1.fc28.x86_64/scripts/unifdef lacks full ASLR (PIE), the stack protector has not been enabled, and annobin annotations are missing.

Is it possible to change that?  I would appreciate if I wouldn't have to track an exception for these programs.

See https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md for information on RPM macros and environment variables provided by the build environment.

Comment 1 Laura Abbott 2018-02-27 00:33:22 UTC
There doesn't seem to be a nice way to do so without kernel modifications. I want to just set HOST_EXTRACFLAGS on the command line to build but these executables are compiled across the kernel and most instances of HOST_EXTRACFLAGS are not set with override.

Comment 2 Laura Abbott 2018-03-27 16:16:08 UTC
I played around with adding another environment variable to pick up the flags https://koji.fedoraproject.org/koji/taskinfo?taskID=25993641 does this look like it picked up everything appropriately?

Comment 3 Laura Abbott 2018-03-27 21:15:33 UTC
Sigh, I realized looking at this more that it's still incomplete. Most the host files do not use the host flags consistently. There needs to be more clean up to actually make them pick up the flags.

Comment 4 Laura Abbott 2018-03-29 00:22:41 UTC
So I think I hit everything in -devel:

./scripts/pnmtologo:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: yes
./scripts/kconfig/conf:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/kallsyms:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/selinux/mdp/mdp:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: yes
./scripts/selinux/genheaders/genheaders:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: yes
./scripts/asn1_compiler:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/conmakehash:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/unifdef:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/mod/mk_elfconfig:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes
./scripts/mod/modpost:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/recordmcount:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/sortextable:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/extract-cert:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: yes
./scripts/basic/fixdep:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./scripts/basic/bin2c:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: yes
./scripts/sign-file:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
./tools/objtool/objtool:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

The one exception right now seems to be the fixdep binary as part of objtool:

./tools/objtool/fixdep:
 Position Independent Executable: no, normal executable!
 Stack protected: no, not found!
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: no, not found!
                                         

I ran into some issues there because the fixdep object is linked directly with the linker with -r and I couldn't find a good way to make it pick up the correct flags. That can go on the TODO list.

Comment 5 Laura Abbott 2018-07-12 23:32:38 UTC
The patches have been accepted by the kbuild maintainer upstream to allow setting of the flags on the command line so I applied them for rawhide and fixed up the spec file to build. Future rawhide builds should now be correctly hardened. I'm going to close this bug since the core functionality should be present. If you find other binaries that are missing, please reopen.


Note You need to log in before you can comment on or make changes to this bug.