[GIT PULL] gcc-plugins updates for v4.11-rc1

[GIT PULL] gcc-plugins updates for v4.11-rc1

[Kees Cook]

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

Re: [GIT PULL] gcc-plugins updates for v4.11-rc1

[Linus Torvalds]

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

Re: [GIT PULL] gcc-plugins updates for v4.11-rc1

[Kees Cook]

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

Re: [GIT PULL] gcc-plugins updates for v4.11-rc1

[Linus Torvalds]

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