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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, Jul 5, 2017 at 1:40 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> So while I think it may be useful for robustness, to avoid erratic
> behavior or exploitable interactions between different parts of the
> code, my estimation is that it wouldn't make a great deal of
> difference, given that the logic that allows the compiler to 'see the
> real initialization' is the same logic that warns us if it is lacking,
> and so in a warning free build, no init sequences should have been
> emitted to begin with.

So the issue I think would be good to fix is perhaps best explained by
pseudo-code

  int testfn(struct somestruct __user *p)
  {
        struct somestruct a;

        initialize_struct(&a);
        if (copy_to_user(p, &a, sizeof(a)))
                return -EFAULT;
        return 0;
  }

which is obviously made-up code, but is not actually entirely unrealistic.

It's fairly common code in various ioctl-like functions, but also in
things like the "stat()" system call etc. The thing that initializes a
variable is not necessarily visible, and gcc can not warn about the
fact that "initialize_struct()" doesn't actually initialize all
fields.

Or even if it does initialize all the fields, what about the padding
bytes? That doesn't matter in most normal C programs, since by
definition the padding bytes aren't used, but for the kernel, it
*does* matter when they get copied outside the kernel.

              Linus