Messages in this thread | | | Date | Tue, 23 Nov 2010 23:23:55 +0800 | From | Américo Wang <> | Subject | Re: [PATCH v2] fs: select: fix information leak to userspace |
| |
On Tue, Nov 23, 2010 at 03:45:18PM +0100, walter harms wrote: >Am 23.11.2010 15:01, schrieb Américo Wang: >> On Mon, Nov 15, 2010 at 08:12:21PM +0100, Eric Dumazet wrote: >>> >>> In my understanding, gcc should initialize all holes (and other not >>> mentioned fields) with 0, even for automatic storage [C99 only mandates >>> this on static storage] >>> >>> I tested on x86_64 and this is the case, but could not find a definitive >>> answer in gcc documentation. >>> >> >> Yeah, this is not clearly defined by C99 I think, but we can still >> find some clues in 6.2.6.1, Paragraph 6, >> >> " >> When a value is stored in an object of structure or union type, >> including in a member object, the bytes of the object representation >> that correspond to any padding bytes take unspecified values. >> " >> >> So we can't rely on the compiler to initialize the padding bytes >> too. >> >hi all, >as we see this is not a question of c99. >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. > >People that still want a "undefined" (for what ever reason) can use an option to enable it >again (e.g. --no-zero-padding).
Well, IMHO, the default behavior should be "undefined", thus "-fzero-padding" is needed. But, you know, I am not a compiler people at all. :)
> >do anyone have a contact so we can forward that request ? >
gcc@gcc.gnu.org ?
-- Live like a child, think like the god.
-- 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/
| |