All of lore.kernel.org
 help / color / mirror / Atom feed
From: walter harms <wharms@bfs.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Andreas Dilger" <adilger.kernel@dilger.ca>,
	"Américo Wang" <xiyou.wangcong@gmail.com>,
	"Eric Dumazet" <eric.dumazet@gmail.com>,
	"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>
Subject: Re: [PATCH v2] fs: select: fix information leak to userspace
Date: Wed, 24 Nov 2010 16:06:50 +0000	[thread overview]
Message-ID: <4CED381A.5060100@bfs.de> (raw)
In-Reply-To: <20101123121840.e9d17d91.akpm@linux-foundation.org>



Am 23.11.2010 21:18, schrieb Andrew Morton:
> On Tue, 23 Nov 2010 11:02:44 -0700
> Andreas Dilger <adilger.kernel@dilger.ca> wrote:
> 
>> 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.
> 
> (My, what long lines you have!)
> 
> We can't reasonably address this with gcc changes.  If gcc starts doing
> what we want in the next release, how long will it be until that
> release is the *oldest* version of gcc which the kernel may be compiled
> with?  Five years?
> 
> 
agreed, but it does not mean not to talk to the gcc people that there is
an interesse to change.

re,
 wh

WARNING: multiple messages have this Message-ID (diff)
From: walter harms <wharms@bfs.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Andreas Dilger" <adilger.kernel@dilger.ca>,
	"Américo Wang" <xiyou.wangcong@gmail.com>,
	"Eric Dumazet" <eric.dumazet@gmail.com>,
	"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>
Subject: Re: [PATCH v2] fs: select: fix information leak to userspace
Date: Wed, 24 Nov 2010 17:06:50 +0100	[thread overview]
Message-ID: <4CED381A.5060100@bfs.de> (raw)
In-Reply-To: <20101123121840.e9d17d91.akpm@linux-foundation.org>



Am 23.11.2010 21:18, schrieb Andrew Morton:
> On Tue, 23 Nov 2010 11:02:44 -0700
> Andreas Dilger <adilger.kernel@dilger.ca> wrote:
> 
>> 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.
> 
> (My, what long lines you have!)
> 
> We can't reasonably address this with gcc changes.  If gcc starts doing
> what we want in the next release, how long will it be until that
> release is the *oldest* version of gcc which the kernel may be compiled
> with?  Five years?
> 
> 
agreed, but it does not mean not to talk to the gcc people that there is
an interesse to change.

re,
 wh

  parent reply	other threads:[~2010-11-24 16:06 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-10 20:38 [PATCH] fs: select: fix information leak to userspace Vasiliy Kulikov
2010-11-10 20:38 ` Vasiliy Kulikov
2010-11-12 20:08 ` Andrew Morton
2010-11-12 20:08   ` Andrew Morton
2010-11-13 21:38   ` Andreas Dilger
2010-11-13 21:38     ` Andreas Dilger
2010-11-14  9:25     ` [PATCH v2] " Vasiliy Kulikov
2010-11-14  9:25       ` Vasiliy Kulikov
2010-11-15  2:06       ` Andrew Morton
2010-11-15  2:06         ` Andrew Morton
2010-11-15 19:12         ` Eric Dumazet
2010-11-15 19:12           ` Eric Dumazet
2010-11-15 19:12           ` Eric Dumazet
2010-11-16 11:19           ` Boaz Harrosh
2010-11-16 11:19             ` Boaz Harrosh
2010-11-22 23:50             ` Andrew Morton
2010-11-22 23:50               ` Andrew Morton
2010-11-23  0:20               ` Eric Dumazet
2010-11-23  0:20                 ` Eric Dumazet
2010-11-23  0:32                 ` Andrew Morton
2010-11-23  0:32                   ` Andrew Morton
2010-11-23  5:12                   ` Dan Carpenter
2010-11-23  5:12                     ` Dan Carpenter
2010-11-23  6:59                     ` Eric Dumazet
2010-11-23  6:59                       ` Eric Dumazet
2010-11-23  6:59                       ` Eric Dumazet
2010-11-23 13:58           ` Américo Wang
2010-11-23 14:01             ` Américo Wang
2010-11-23 14:01             ` Américo Wang
2010-11-23 14:45             ` walter harms
2010-11-23 14:45               ` walter harms
2010-11-23 14:45               ` walter harms
2010-11-23 15:23               ` Américo Wang
2010-11-23 15:23                 ` Américo Wang
2010-11-23 15:23                 ` Américo Wang
2010-11-23 18:02               ` Andreas Dilger
2010-11-23 18:02                 ` Andreas Dilger
2010-11-23 20:18                 ` Andrew Morton
2010-11-23 20:18                   ` Andrew Morton
2010-11-23 20:22                   ` David Miller
2010-11-23 20:22                     ` David Miller
2010-11-24  0:24                   ` Andreas Dilger
2010-11-24  0:24                     ` Andreas Dilger
2010-11-24 16:06                   ` walter harms [this message]
2010-11-24 16:06                     ` walter harms
2010-11-24 10:44                 ` Pádraig Brady
2010-11-24 10:44                   ` Pádraig Brady
2010-11-24 10:44                   ` Pádraig Brady
2010-11-24 11:05                   ` Américo Wang
2010-11-24 11:05                     ` Américo Wang
2010-11-24 11:46                     ` Pádraig Brady
2010-11-24 12:32                       ` Américo Wang
2010-11-24 12:32                         ` Américo Wang
2010-12-15  9:49                       ` Al Viro
2010-12-15 20:30                         ` Andreas Dilger
2010-12-15 20:30                           ` Andreas Dilger
2010-12-15 20:33                           ` Julia Lawall
2010-12-15 20:33                             ` Julia Lawall
2010-12-15 20:52                             ` Eric Dumazet
2010-12-15 20:52                               ` Eric Dumazet
2010-12-15 20:52                               ` Eric Dumazet
2010-12-15 22:19                               ` Andreas Dilger
2010-12-15 22:19                                 ` Andreas Dilger
2010-12-16  9:39                                 ` Boaz Harrosh
2010-12-16  9:39                                   ` Boaz Harrosh
2010-12-16  9:39                                   ` Boaz Harrosh
2010-11-24 17:54               ` Valdis.Kletnieks
2010-11-24 17:54                 ` Valdis.Kletnieks
2010-11-16 18:45         ` Vasiliy Kulikov
2010-11-16 18:45           ` Vasiliy Kulikov
2010-11-15  2:05     ` [PATCH] " Andrew Morton
2010-11-15  2:05       ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CED381A.5060100@bfs.de \
    --to=wharms@bfs.de \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=eric.dumazet@gmail.com \
    --cc=jakub@redhat.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=segoon@openwall.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.