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