This issue concerns <=sys-kernel/gentoo-sources-5.10.67, with >=5.13 being unaffected. Owing to a faulty detection method, if gcc:11 is installed and selected as the active compiler, it becomes impossible to locate GCC_PLUGINS in menuconfig and to enable any of its sub-options. Not only that, but if an existing .config with an enabled plugin is imported, said options will be silently disabled in the course of building the kernel. Levente Polyak, an Arch maintainer, has produced a patch to rectify this issue, which I shall attach here. Please incorporate it as part of genpatches-base. I checked some of the older kernels - 5.4, in particular - and found that the patch does not apply cleanly. Nevertheless, the patch is trivial and can be easily backported.
Created attachment 740556 [details, diff] gcc-plugins-modern-gcc-plugin-infrastructure-requres.patch
What is the upstream status of this patch?
(In reply to Mike Gilbert from comment #2) > What is the upstream status of this patch? As can be seen, the patch contains two hunks. The first touches "scripts/gcc-plugin.sh" and the second touches "scripts/gcc-plugins/Makefile". As concerns the first hunk, its changes have not been incorporated by mainline. There is a simple reason for this, which is that gcc-plugin.sh was removed. Instead, there is a new compiler-version.h header, which is used in such a way as to render the script redundant. One could go as far as to backport all of this. Indeed, I did so for 5.10 before discovering Levente's patch. To do so is more intrusive, though. As concerns the second hunk, its changes have been incorporated by mainline. In short, Levente's patch does as little as is necessary to rectify the issue for 5.10. Whether anyone is looking at submitting it to the stable queue, I don't know.
What about this ? You will need to apply this by hand but it's one delete and one line change. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=1e860048c53ee77ee9870dcce94847a28544b753 Tested with 5.4 w/gcc 11 and nothing else
(In reply to Mike Pagano from comment #4) > What about this ? You will need to apply this by hand but it's one delete > and one line change. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/ > ?id=1e860048c53ee77ee9870dcce94847a28544b753 > > Tested with 5.4 w/gcc 11 and nothing else Yes, that's one of several changes that were ultimately made. In and as of itself, it's a good one. Only, I'm not sure that it should be applied in isolation. I'll look into it and get back to you, assuming you don't reach a conclusion in the intervening period.
Created attachment 740934 [details, diff] Somewhat simpler patch, tested on 5.4
(In reply to Mike Pagano from comment #6) > Created attachment 740934 [details, diff] [details, diff] > Somewhat simpler patch, tested on 5.4 Does this patch work for you as expected?
(In reply to Mike Pagano from comment #7) > Does this patch work for you as expected? Hello, Mike. Sorry, I didn't have any time to look into it during the week. I'll test it out shortly.
Maybe nobody has noticed or cares, but this bug has more security implications than it may seem: * A run of make oldconfig will not show the change in the plugin state * Many KSP features (for example randstruct) depend on plugins and get silently disabled when using gcc-11 While per se this does not introduce a security vulnerability it may result on exploitation if users think they are more secure than what they really are.
(In reply to Francisco Blas Izquierdo Riera from comment #9) > Maybe nobody has noticed or cares, but this bug has more security > implications than it may seem: > * A run of make oldconfig will not show the change in the plugin state > * Many KSP features (for example randstruct) depend on plugins and get > silently disabled when using gcc-11 Yes, indeed. That's why I reported it immediately. Users either need to be paying very close attention to their .config files or to be attentive in the course of executing dispatch-conf in the USE="savedconfig" case. Either way, it's not a good situation. Personally, I would have considered it blocking for gcc-11. Once again, I apologise for taking this long to return to the matter at hand. In summary, I think that Mike's patch in comment #6 is good, and I can find no particular fault with it. I had wondered whether it would also be sensible to backport the change that touches scripts/gcc-plugins/Makefile. That is, the one that adds -std=gnu++11 while dropping -Wno-c++11-compat. I contacted both Levente and Kees (Cook) in the hope of getting a concrete answer to that question but haven't been able to, as of yet. I think that the patch should be applied in its present form. Mike's, that is, not mine. I don't see how it could possibly make the situation any worse. If I receive any further information from upstream, I shall convey it here.
(In reply to Mike Pagano from comment #7) > (In reply to Mike Pagano from comment #6) > > Created attachment 740934 [details, diff] [details, diff] [details, diff] > > Somewhat simpler patch, tested on 5.4 > > Does this patch work for you as expected? All hunks of your patch are rejected on gentoo-sources-5.10.75[experimental]. Attachment 740556 [details, diff] applies cleanly to gentoo-sources-5.10.75[experimental], subsequent make oldconfig works as expected (i.e. leaving GCC plugins enabled).
(In reply to Frank Limpert from comment #11) > (In reply to Mike Pagano from comment #7) > > (In reply to Mike Pagano from comment #6) > > > Created attachment 740934 [details, diff] [details, diff] [details, diff] [details, diff] > > > Somewhat simpler patch, tested on 5.4 > > > > Does this patch work for you as expected? > > All hunks of your patch are rejected on gentoo-sources-5.10.75[experimental]. > > Attachment 740556 [details, diff] [details, diff] applies cleanly to > gentoo-sources-5.10.75[experimental], subsequent make oldconfig works as > expected (i.e. leaving GCC plugins enabled). Mike's patch reflects the mainline changes but targets 5.4. I'll look into creating a 5.10 variant now.
Created attachment 746715 [details, diff] Somewhat simpler patch, targeting 5.10.75 Similar to attachment 740934 [details, diff], only targeting 5.10.75 rather than 5.4. The solution is taken verbatim from Levente Polyak's latest linux-hardened patch and all of the changes are reflected upstream. The only notable difference here is that I've included the -std=gnu++11 change, per comment 10.
I suppose I should point out where the hardened patch is for the benefit of those that don't know. https://github.com/anthraxx/linux-hardened/releases/ https://github.com/anthraxx/linux-hardened/releases/download/5.10.75-hardened1/linux-hardened-5.10.75-hardened1.patch
"This issue concerns <=sys-kernel/gentoo-sources-5.10.67, with >=5.13 being unaffected." What kernel versions should this go on?
(In reply to Mike Pagano from comment #15) > "This issue concerns <=sys-kernel/gentoo-sources-5.10.67, with >=5.13 being > unaffected." > > What kernel versions should this go on? Emerged all the versions (5.10.66..74) and tried gcc-plugin.sh with x86_64-pc-linux-gnu-gcc-11.2.0. None returned with exit code 0 -> all affected. Using x86_64-pc-linux-gnu-gcc-10.3.0 instead all invocations yield exit code 0. I also applied the patch from comment 13 on 5.10.61 and succeeded. GCC_PLUGINS re-appear with clean sources and make menuconfig as well as stay with zcat /proc/config.gz >.config and make syncconfig. (As far as I remember make oldconfig is deprecated and make syncconfig is the replacement – both succeeded and kept GCC_PLUGINS selected.) I'll tweak this a bit and let emerge apply the patch to all 5.10.*. Does this answer your question if this succeeds?
(In reply to Mike Pagano from comment #15) > "This issue concerns <=sys-kernel/gentoo-sources-5.10.67, with >=5.13 being > unaffected." > > What kernel versions should this go on? Here is my assessment of all of the longterm series, along with the current stable series, as of the time of writing. 5.14 : unaffected 5.10 : affected 5.4 : affected 4.19 : broken 4.14 : broken 4.9 : broken 4.4 : not applicable Affected means that they are subject to the issue described by this bug. Broken means that any attempt to build the available plugins with gcc-11 as the active compiler results in a build failure. 4.4 is immaterial because no plugins are implemented. My view is that it's not worth trying to account for the apparent lack of upstream QA in the case of 4.9, 4.14 and 4.19. Users that encounter a build failure with these versions can either upgrade, disable the plugins or pursue the matter of their own accord. 5.4 and 5.10 are another matter, because its users stand to be affected in the way that Francisco and I describe. No build failure occurs, nor is there any other overt indication of something having gone wrong. Besides which, 5.10 has a lot of users and there are probably still a fair number holding out on 5.4. As the upstream maintainers appear to be in no hurry to rectify this issue, I would recommend that it be addressed by your 5.4 and 5.10 patchsets. I have supplied a patch that applies cleanly to 5.10.75. Yours continues to apply cleanly to 5.4.155, though I still believe that it would be better to incorporate the changes to scripts/gcc-plugins/Makefile as I did.
(In reply to onkobu from comment #16) > I'll tweak this a bit and let emerge apply the patch to all 5.10.*. Does > this answer your question if this succeeds? Thanks for the effort, but there is no need. It's apparent that all of the official 5.10.* releases are affected. Future releases will remain affected until such time as a fix lands in the stable-queue (which hasn't happened yet). https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=31d87d68ad9f5dc0179039bd3adc6f4e9916d7b6 commit 31d87d68ad9f5dc0179039bd3adc6f4e9916d7b6 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2021-10-28 12:27:26 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2021-10-28 12:27:26 +0000 sys-kernel/gentoo-sources: Fix gcc detection Bug: https://bugs.gentoo.org/814200 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Mike Pagano <mpagano@gentoo.org> sys-kernel/gentoo-sources/Manifest | 3 +++ .../gentoo-sources-5.10.76-r1.ebuild | 28 ++++++++++++++++++++++ 2 files changed, 31 insertions(+)
The patch that landed in the 5.4 branch of linux-patches has a quality issue. Though it removes scripts/gcc-plugin.sh, the build system still attempts to execute it, so as to establish a value for PLUGIN_HOSTCC (something that no longer exists in 5.10). The result is that errors such as the one below can be seen. sh: 1: ./scripts/gcc-plugin.sh: not found The good news is that, with the exit status value being ignored, the consequences end up being cosmetic in nature. Given the intent of the patch, gcc already becomes a hard requirement for building the plugins, with no claim being made to support any version older than 4.8. Therefore, support for PLUGIN_HOSTCC can be removed altogether. I shall attach an updated patch momentarily.
Created attachment 748560 [details, diff] Somewhat simpler patch, tested on 5.4 (corrected)
commit 806549f8ef327ca616f38eaa6549eac8e20c16fb (HEAD -> 5.4, origin/5.4) Author: Mike Pagano <mpagano@gentoo.org> Date: Thu Nov 4 07:22:06 2021 -0400 Upd gcc ver detect patch.Make visible GCC_PLUGINS. Thanks to Kerin Millar. Signed-off-by: Mike Pagano <mpagano@gentoo.org>
> commit 806549f8ef327ca616f38eaa6549eac8e20c16fb (HEAD -> 5.4, origin/5.4) > Author: Mike Pagano <mpagano@gentoo.org> > Date: Thu Nov 4 07:22:06 2021 -0400 > > Upd gcc ver detect patch.Make visible GCC_PLUGINS. Thanks to Kerin Millar. Something still seems wrong/incomplete here. Using gcc-10 (so not even the gcc-11 that this bug is about), and 5.4.157 (the latest 5.4 as of now), doing 'make oldconfig' ends with: /usr/src/linux # make oldconfig scripts/kconfig/conf --oldconfig Kconfig sh: line 1: ./scripts/gcc-plugin.sh: No such file or directory # # No change to .config # I confirmed that 5.4.157 upstream still has scripts/gcc-plugin.sh, so it seems we are removing it but not removing references to it.
(In reply to Hank Leininger from comment #23) > > commit 806549f8ef327ca616f38eaa6549eac8e20c16fb (HEAD -> 5.4, origin/5.4) > > Author: Mike Pagano <mpagano@gentoo.org> > > Date: Thu Nov 4 07:22:06 2021 -0400 > > > > Upd gcc ver detect patch.Make visible GCC_PLUGINS. Thanks to Kerin Millar. > > Something still seems wrong/incomplete here. There is a difference between committing something to linux-patches and signing off on a new gentoo-sources release. As such, the revised patch is not part of gentoo-sources-5.4.157. It will be in either gentoo-sources-5.4.158 or 5.4.157-r1 in the case that Mike goes for a revision bump.
(In reply to Kerin Millar from comment #24) > (In reply to Hank Leininger from comment #23) > > > commit 806549f8ef327ca616f38eaa6549eac8e20c16fb (HEAD -> 5.4, origin/5.4) > > > Author: Mike Pagano <mpagano@gentoo.org> > > > Date: Thu Nov 4 07:22:06 2021 -0400 > > > > > > Upd gcc ver detect patch.Make visible GCC_PLUGINS. Thanks to Kerin Millar. > > > > Something still seems wrong/incomplete here. > > There is a difference between committing something to linux-patches and > signing off on a new gentoo-sources release. As such, the revised patch is > not part of gentoo-sources-5.4.157. It will be in either > gentoo-sources-5.4.158 or 5.4.157-r1 in the case that Mike goes for a > revision bump. Maybe we are saying the same thing, but just to be clear: our gentoo-sources-5.4.157.ebuild is currently broken because we already remove gcc-plugin.sh, but do not remove the references to it.
(In reply to Hank Leininger from comment #25) > Maybe we are saying the same thing, but just to be clear: our > gentoo-sources-5.4.157.ebuild is currently broken because we already remove > gcc-plugin.sh, but do not remove the references to it. Yes, we know. I didn't write the initial 5.4 patch but noted this issue in comment #20 before submitting a more 'complete' patch. As I stated there, the consequences are only cosmetic in nature. There should be nothing to stop you from configuring, building and using 5.4.157 normally. Beyond that, you'll need to wait for the next gentoo-sources release to benefit from the revised patch. See, also, the Whiteboard field at the top of this bug.
To be clear, by benefit, I mean that you won't see the annoying/startling "No such file or directory" error anymore.
We should be good now in 5.4. Thanks, Kerin commit f697da8bd73a2ec669bc43eef85a9dec8ffa239d (HEAD -> master, origin/master, origin/HEAD) Author: Mike Pagano <mpagano@gentoo.org> Date: Sat Nov 6 10:06:27 2021 -0400 sys-kernel/gentoo-sources: Linux bumps and genpatches 5.15.1 and BMQ schedular patch and change to gentoo Kconfig patch for systemd, which will select CONFIG_KCMP as systemd uses the kcmp() call 5.14.17 5.10.78 5.4.158 and GCC Detection patch thanks to Kerin Millar. 4.19.216 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Mike Pagano <mpagano@gentoo.org>
