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

From: Linus Torvalds
Date: Wed Jul 05 2017 - 17:35:15 EST

On Wed, Jul 5, 2017 at 1:40 PM, Ard Biesheuvel
<ard.biesheuvel@xxxxxxxxxx> 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

int testfn(struct somestruct __user *p)
struct somestruct 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

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.