Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1681858

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

From Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups linux.kernel
Subject Re: [GIT PULL] gcc-plugins updates for v4.13-rc1
Date 2017-07-05 23:40 +0200
Message-ID <u00bF-3nZ-33@gated-at.bofh.it> (permalink)
References <tZKJz-1Ny-9@gated-at.bofh.it> <tZXQu-1WT-19@gated-at.bofh.it> <tZZpg-2RM-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[GIT PULL] gcc-plugins updates for v4.13-rc1 Kees Cook <keescook@chromium.org> - 2017-07-05 07:10 +0200
  Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 21:10 +0200
    Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-07-05 22:50 +0200
      Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 23:40 +0200
        Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Arnd Bergmann <arnd@arndb.de> - 2017-07-05 23:50 +0200
          Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Kees Cook <keescook@chromium.org> - 2017-07-06 00:00 +0200
          Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-06 00:00 +0200
            Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-07-06 00:30 +0200
              Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-06 00:40 +0200
            Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Andrey Ryabinin <ryabinin.a.a@gmail.com> - 2017-07-06 00:50 +0200
    Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Arnd Bergmann <arnd@arndb.de> - 2017-07-05 23:20 +0200
    Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Kees Cook <keescook@chromium.org> - 2017-07-05 23:50 +0200

csiph-web