Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755869Ab0KWSCs (ORCPT ); Tue, 23 Nov 2010 13:02:48 -0500 Received: from idcmail-mo2no.shaw.ca ([64.59.134.9]:29101 "EHLO idcmail-mo2no.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753774Ab0KWSCq convert rfc822-to-8bit (ORCPT ); Tue, 23 Nov 2010 13:02:46 -0500 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=dyVpuHYQJROgCHwBBw1H+I+7e1rgZIKdHwrI0HSbuo4= c=1 sm=1 a=btxqJe0AtA4A:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=c23vf5CSMVc0QQz9B4a6RA==:17 a=WETlFUPZjA9XnLtGGzAA:9 a=In-BYlvDvJtGH69SQBrkr7cSMnUA:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [PATCH v2] fs: select: fix information leak to userspace Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Andreas Dilger In-Reply-To: <4CEBD37E.5060107@bfs.de> Date: Tue, 23 Nov 2010 11:02:44 -0700 Cc: =?iso-8859-1?Q?Am=E9rico_Wang?= , Eric Dumazet , Andrew Morton , Vasiliy Kulikov , kernel-janitors@vger.kernel.org, Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jakub Jelinek Content-Transfer-Encoding: 8BIT Message-Id: <203E1F2A-2D04-4B7F-8D1B-9DC24522CB5E@dilger.ca> References: <1289421483-23907-1-git-send-email-segooon@gmail.com> <20101112120834.33062900.akpm@linux-foundation.org> <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> To: wharms@bfs.de X-Mailer: Apple Mail (2.1082) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 944 Lines: 16 On 2010-11-23, at 07:45, walter harms wrote: > Maybe we can convince the gcc people to make 0 padding default. That 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-trivial for commonly-used and/or large structures. Since GCC is already explicitly zeroing the _used_ fields in the struct, it can much more easily determine whether there is padding in the structure, and zero those few bytes as needed. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/