Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752516AbdGEVfL (ORCPT ); Wed, 5 Jul 2017 17:35:11 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:35903 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751659AbdGEVfK (ORCPT ); Wed, 5 Jul 2017 17:35:10 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170705050500.GA72383@beast> From: Linus Torvalds Date: Wed, 5 Jul 2017 14:35:08 -0700 X-Google-Sender-Auth: MV_OtZ9wRSihk29qkb7s7owky9E Message-ID: Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 To: Ard Biesheuvel Cc: Kees Cook , Linux Kernel Mailing List , Arnd Bergmann , Jean Delvare Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1446 Lines: 38 On Wed, Jul 5, 2017 at 1:40 PM, Ard Biesheuvel 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