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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 5 Jul 2017 14:35:08 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>, Jean Delvare <jdelvare@...e.de>
Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1

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