From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH v2] fs: select: fix information leak to userspace Date: Wed, 15 Dec 2010 21:52:48 +0100 Message-ID: <1292446368.2603.13.camel@edumazet-laptop> 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> <20101215094953.GG19804@ZenIV.linux.org.uk> <0BAF9CFC-72BF-49A1-93D3-BF60B892389B@dilger.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andreas Dilger , Al Viro , P??draig Brady , Am??rico Wang , wharms@bfs.de, Andrew Morton , Vasiliy Kulikov , kernel-janitors@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jakub Jelinek To: Julia Lawall Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:48691 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752158Ab0LOUwx (ORCPT ); Wed, 15 Dec 2010 15:52:53 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Le mercredi 15 d=C3=A9cembre 2010 =C3=A0 21:33 +0100, Julia Lawall a =C3= =A9crit : > On Wed, 15 Dec 2010, Andreas Dilger wrote: >=20 > > On 2010-12-15, at 02:49, Al Viro wrote: > > > Incorrect. See 6.2.6.1 in C99; basically, padding bytes have uns= pecified > > > contents. Implementation is allowed to leave them in any state > > > (including not bothering to copy them when doing struct assignmen= ts, > > > etc.). See Appendix J (portability issues) as well. > > >=20 > > > The bottom line: if you rely on that, you are relying on non-port= able > > > details of compiler behaviour. Moreover, the authors are not eve= n > > > required to document what they are doing or to keep that behaviou= r > > > consistent. > >=20 > > I thought my proposed solution was reasonable - add explicit paddin= g fields where there are holes in the structure, which would be unused = by the kernel, but since they are defined fields the compiler is obliga= ted to initialize them. >=20 > Is the presence of holes always apparent at the source code level? O= r is=20 > it dependent on the compiler or target architecture? It depends on target architecture. This means doing a full review to add a named padding only for arches that need it. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html