* [GIT PULL] gcc-plugins updates for v4.11-rc1 @ 2017-02-21 20:16 Kees Cook 2017-02-22 2:34 ` Linus Torvalds 0 siblings, 1 reply; 4+ messages in thread From: Kees Cook @ 2017-02-21 20:16 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel, Emese Revfy Hi, Please pull these gcc-plugins changes for v4.11-rc1. This includes two new plugins for the upstream kernel: structleak and initify. The structleak plugin performs forced initialization of certain structures to avoid possible information exposures to userspace. The initify plugin performs analysis to find functions and strings that can be marked as __init or __exit to reduce the runtime size of the kernel. Thanks! -Kees The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08 14:18:17 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.11-rc1 for you to fetch changes up to 5988b5db7be58878cbbf1f8251968c8b89327d21: Merge commit 'v4.10-rc3^{}' into for-next/gcc-plugins (2017-02-16 16:32:34 -0800) ---------------------------------------------------------------- Updates to the gcc-plugins: - infrastructure updates (gcc-common.h) - introduce structleak plugin for forced initialization of some structures - introduce initify plugin for optimized __init and __exit markings ---------------------------------------------------------------- Emese Revfy (4): gcc-plugins: Add the initify gcc plugin util: Move type casts into is_kernel_rodata initify: Mark functions with the __nocapture attribute initify: Mark functions with the __unverified_nocapture attribute Kees Cook (5): gcc-plugins: add PASS_INFO and build_const_char_string() gcc-plugins: consolidate on PASS_INFO macro gcc-plugins: Add structleak for more stack initialization Merge branch 'for-next/gcc-plugin/structleak' into for-next/gcc-plugins Merge commit 'v4.10-rc3^{}' into for-next/gcc-plugins arch/Kconfig | 62 + arch/arm/include/asm/string.h | 10 +- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/string.h | 25 +- arch/powerpc/include/asm/string.h | 19 +- arch/x86/Kconfig | 1 + arch/x86/include/asm/string_32.h | 25 +- arch/x86/include/asm/string_64.h | 23 +- arch/x86/kernel/hpet.c | 2 +- arch/x86/lib/Makefile | 4 + drivers/acpi/acpica/acutils.h | 2 +- fs/char_dev.c | 2 +- fs/ntfs/debug.h | 6 +- fs/ocfs2/cluster/masklog.h | 2 +- include/acpi/acpixf.h | 2 +- include/asm-generic/asm-prototypes.h | 8 +- include/asm-generic/bug.h | 7 +- include/asm-generic/vmlinux.lds.h | 2 + include/drm/drm_drv.h | 2 +- include/linux/audit.h | 5 +- include/linux/compiler-gcc.h | 22 + include/linux/compiler.h | 14 +- include/linux/fs.h | 8 +- include/linux/printk.h | 2 +- include/linux/ratelimit.h | 3 +- include/linux/string.h | 75 +- lib/string.c | 3 +- lib/vsprintf.c | 6 +- mm/kasan/kasan.c | 2 + mm/util.c | 10 +- scripts/Makefile.gcc-plugins | 18 + scripts/gcc-plugins/cyc_complexity_plugin.c | 6 +- scripts/gcc-plugins/gcc-common.h | 55 +- scripts/gcc-plugins/initify_plugin.c | 1865 +++++++++++++++++++++++++++ scripts/gcc-plugins/latent_entropy_plugin.c | 8 +- scripts/gcc-plugins/sancov_plugin.c | 8 +- scripts/gcc-plugins/structleak_plugin.c | 246 ++++ security/integrity/integrity.h | 2 +- 38 files changed, 2416 insertions(+), 147 deletions(-) create mode 100644 scripts/gcc-plugins/initify_plugin.c create mode 100644 scripts/gcc-plugins/structleak_plugin.c -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [GIT PULL] gcc-plugins updates for v4.11-rc1 2017-02-21 20:16 [GIT PULL] gcc-plugins updates for v4.11-rc1 Kees Cook @ 2017-02-22 2:34 ` Linus Torvalds 2017-02-22 5:07 ` Kees Cook 0 siblings, 1 reply; 4+ messages in thread From: Linus Torvalds @ 2017-02-22 2:34 UTC (permalink / raw) To: Kees Cook; +Cc: Linux Kernel Mailing List, Emese Revfy On Tue, Feb 21, 2017 at 12:16 PM, Kees Cook <keescook@chromium.org> wrote: > > Please pull these gcc-plugins changes for v4.11-rc1. This includes two new > plugins for the upstream kernel: structleak and initify. The structleak > plugin performs forced initialization of certain structures to avoid > possible information exposures to userspace. The initify plugin performs > analysis to find functions and strings that can be marked as __init or > __exit to reduce the runtime size of the kernel. I pulled this, but then looked at the patch, and decided to unpull it. The crazy "__nocapture()" annotations are too ugly to live, and make no sense. They are basically random noise to some very core header files. And the "__unverified_nocapture()" ones are worse. I'm not sure how to fix this issue. Linus ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [GIT PULL] gcc-plugins updates for v4.11-rc1 2017-02-22 2:34 ` Linus Torvalds @ 2017-02-22 5:07 ` Kees Cook 2017-02-23 1:25 ` Linus Torvalds 0 siblings, 1 reply; 4+ messages in thread From: Kees Cook @ 2017-02-22 5:07 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Emese Revfy On Tue, Feb 21, 2017 at 6:34 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Feb 21, 2017 at 12:16 PM, Kees Cook <keescook@chromium.org> wrote: >> >> Please pull these gcc-plugins changes for v4.11-rc1. This includes two new >> plugins for the upstream kernel: structleak and initify. The structleak >> plugin performs forced initialization of certain structures to avoid >> possible information exposures to userspace. The initify plugin performs >> analysis to find functions and strings that can be marked as __init or >> __exit to reduce the runtime size of the kernel. > > I pulled this, but then looked at the patch, and decided to unpull it. Hrm, I will send a pull for just the infrastructure and structleak changes, since those are independent from the initify changes. > The crazy "__nocapture()" annotations are too ugly to live, and make > no sense. They are basically random noise to some very core header > files. And the "__unverified_nocapture()" ones are worse. Is it the naming, or something else? I tried to document them as clearly as I could... the initify plugin needs to figure out if a string is being retained by a function to decide if it can safely be moved into the .init section. > I'm not sure how to fix this issue. I'm open to ideas. :) Initify certainly has more annotations than most of the pending plugins, but there needs to be a way to mark things for plugin consumption. -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [GIT PULL] gcc-plugins updates for v4.11-rc1 2017-02-22 5:07 ` Kees Cook @ 2017-02-23 1:25 ` Linus Torvalds 0 siblings, 0 replies; 4+ messages in thread From: Linus Torvalds @ 2017-02-23 1:25 UTC (permalink / raw) To: Kees Cook; +Cc: Linux Kernel Mailing List, Emese Revfy On Tue, Feb 21, 2017 at 9:07 PM, Kees Cook <keescook@chromium.org> wrote: > On Tue, Feb 21, 2017 at 6:34 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > >> The crazy "__nocapture()" annotations are too ugly to live, and make >> no sense. They are basically random noise to some very core header >> files. And the "__unverified_nocapture()" ones are worse. > > Is it the naming, or something else? No, it's just that it attaches to a (lot of) really core functions, and makes those prototypes look odd and incomprehensible, and all for a very odd and very limited and specific feature. The plugin simply isn't important enough to warrant that kind of very invasive marking of core functionality. If the syntax was more pleasant, maybe it would be ok. For example, marking the arguments individually in the argument declaration might make it more palatable, ie the difference between (a) standard declaration: void *memcpy(void *dest, const void *src, size_t n); (b) nasty incomprehensible one: void *memcpy(void *dest, const void *src, size_t n) __nocapture(2); (c) possibly more legible one void *memcpy(void *dest, __nocapture const void *src, size_t n); where I'm just randomly throwing out a syntax that I think _might_ be more palatable. Basically, those "numbered argument attributes" are ugly crap, but in the case of things like the printf strings they are ugly shit with very wide applicability and known very meaningful warnings that have saved our arses several times. So for printf, I see those "__attribute__ ((format...))" things, and I think they are a particularly ugly marker, but it's a marker that I think it is worth it, so the ugliness is an acceptable trade-off. For something like "hint if something could be marked __init", the ugliness is stronger (nonstandard fiormat, on even more core functions), and the upside is less. So in the __nocapture case, they are just really ugly (that "negative index means return value" just takes the cake), and they don't even have the major meaning and history that the printf ugliness has had. Linus ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-02-23 1:26 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-21 20:16 [GIT PULL] gcc-plugins updates for v4.11-rc1 Kees Cook 2017-02-22 2:34 ` Linus Torvalds 2017-02-22 5:07 ` Kees Cook 2017-02-23 1:25 ` Linus Torvalds
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).