Date: Tue, 5 Jul 2016 20:22:46 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Ed Schouten <ed@nuxi.nl>, Benjamin Kaduk <bjkfbsd@gmail.com>, Bruce Evans <brde@optusnet.com.au>, Konstantin Belousov <kostikbel@gmail.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r302252 - head/sys/kern Message-ID: <20160705202144.S1961@besplex.bde.org> In-Reply-To: <CAJ-Vmo=1-PbZWdB%2B06bqMH3WBQ-pU6tyR8FjH5eVksVmxb3yQA@mail.gmail.com> References: <201606281643.u5SGhNsi061606@repo.freebsd.org> <20160629175917.O968@besplex.bde.org> <20160629145443.GG38613@kib.kiev.ua> <20160629153233.GI38613@kib.kiev.ua> <20160630040123.F791@besplex.bde.org> <20160629211953.GK38613@kib.kiev.ua> <20160701005401.Q1084@besplex.bde.org> <20160630180106.GU38613@kib.kiev.ua> <20160701031549.GV38613@kib.kiev.ua> <20160701185743.Q1600@besplex.bde.org> <20160701142516.GW38613@kib.kiev.ua> <20160702153817.O1458@besplex.bde.org> <CAJ5_RoA-d8YGeFHEiGziOU6VutfuX6cHh%2BJ4YGYPcLhVv77B3w@mail.gmail.com> <CABh_MKmjSJoLYMAsrtgxfZVpedpX9wDz7osFrsz63qawdOkWLQ@mail.gmail.com> <CABh_MKm1Zat%2By22O5JfBX9vt8=e5dmULqUUELHZXHMpVAjopDA@mail.gmail.com> <CAJ-VmokVp8QmKX6VRMeKn=Er_SG7V=MNJVHyzr%2ByXcN6cRstYw@mail.gmail.com> <CABh_MKmvGFy81ws8G4N-cMPLMYhVVkVzZfQAK2SwAZsxRu%2Bpag@mail.gmail.com> <CAJ-Vmo=1-PbZWdB%2B06bqMH3WBQ-pU6tyR8FjH5eVksVmxb3yQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 4 Jul 2016, Adrian Chadd wrote: > On 4 July 2016 at 12:28, Ed Schouten <ed@nuxi.nl> wrote: >> 2016-07-04 21:08 GMT+02:00 Adrian Chadd <adrian.chadd@gmail.com>: >>> Does the specification / implementation also mandate that the padding >>> is zero'ed out or otherwise initialised? Only QOI and POLA require it. >> Well... That's tricky: >> >> [URLs lost to fighting with spam filter] Hmm, it's worse than that. C11 adds the requirement that padding in aggregates and unions is initialized to all-bits-zero. This is half-baked since it doesn't apply to pointers or arithmetic types, though it seems to unintentionally apply to pointers and arithmetic types within aggregates (since it says "any" bits). The padding bits in integers are explicitly unspecified elsewhere, except that ordinary stores (and initializations?) must not set them to trap respresentations. Since they are not explicitly specifued here, they are unspecified throughout. Thus, padding bits in at least integers can be set to a representation of the user's password. Low quality implementations do this accidentantly. A perverse implementation would make plain int large enough to hold any password; then whenever a positive value of N is stored to the value bits, it would store the password for user N to the padding bits :-). > Right, so if we're not careful, we could leak bits of kernel memory, > and it can also screw up key cache comparisons. This requires more than a reasonable amount of care for perverse implementations. It is necessary to find and zero all the padding bits in most cases. This is possible by copying to an array of bytes, zeroing the bits there, and copying back. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160705202144.S1961>