From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Am=C3=A9rico?= Wang <xiyou.wangcong@gmail.com>
Subject: Re: [PATCH v2] fs: select: fix information leak to userspace
Date: Wed, 24 Nov 2010 20:32:13 +0800
Message-ID: <20101124123213.GB2922@hack>
References: <8D90F8B2-EA29-4EB9-9807-294CE0D5523B@dilger.ca> <20101114092533.GB5323@albatros> <20101114180643.593d19ac.akpm@linux-foundation.org> <1289848341.2607.125.camel@edumazet-laptop> <20101123140111.GA3816@hack> <4CEBD37E.5060107@bfs.de> <203E1F2A-2D04-4B7F-8D1B-9DC24522CB5E@dilger.ca> <4CECECA2.6070301@draigBrady.com> <20101124110535.GD5139@cr0.nay.redhat.com> <4CECFB19.1090003@draigBrady.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: =?utf-8?Q?Am=C3=A9rico?= Wang <xiyou.wangcong@gmail.com>,
	Andreas Dilger <adilger.kernel@dilger.ca>, wharms@bfs.de,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vasiliy Kulikov <segoon@openwall.com>,
	kernel-janitors@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jakub Jelinek <jakub@redhat.com>
To: =?utf-8?Q?P=C3=A1draig?= Brady <P@draigBrady.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <4CECFB19.1090003@draigBrady.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Wed, Nov 24, 2010 at 11:46:33AM +0000, P=C3=A1draig Brady wrote:
>On 24/11/10 11:05, Am=C3=A9rico Wang wrote:
>> On Wed, Nov 24, 2010 at 10:44:50AM +0000, P=C3=A1draig Brady wrote:
>>> On 23/11/10 18:02, Andreas Dilger wrote:
>>>> On 2010-11-23, at 07:45, walter harms wrote:
>>>>> Maybe we can convince the gcc people to make 0 padding default. T=
hat will not solve the problems for other compilers but when they claim=
 "works like gcc" we can press then to support this also. I can imagine=
 that this will close some other subtle leaks also.
>>>>
>>>> It makes the most sense to tackle this at the GCC level, since the=
 added overhead of doing memset(0) on the whole struct may be non-trivi=
al for commonly-used and/or large structures.  Since GCC is already exp=
licitly zeroing the _used_ fields in the struct, it can much more easil=
y determine whether there is padding in the structure, and zero those f=
ew bytes as needed.
>>>
>>> Zero padding structs is part of C90. Details here:
>>> http://www.pixelbeat.org/programming/gcc/auto_init.html
>>=20
>> Nope.
>>=20
>>>
>>> gcc doesn't zero pad when _all_ elements are specified.
>>>
>>=20
>> That is what gcc does, not what C standard specifies.
>
>Looks like gcc is following the standard exactly.
>
>C90 - 6.5.7
>C99 - 6.7.8
>
>  If there are fewer initializers in a brace-enclosed list than
>  there are elements or members of an aggregate ... the remainder
>  of the aggregate shall be initialized implicitly the same as
>  objects that have static storage duration.
>

Depends on if "the remainder of the aggregate" includes padding bytes
or not.