From owner-svn-src-head@freebsd.org Tue Jul 5 10:22:56 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04D9AB219FB; Tue, 5 Jul 2016 10:22:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id B51AE1611; Tue, 5 Jul 2016 10:22:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c110-21-100-149.carlnfd1.nsw.optusnet.com.au [110.21.100.149]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id AE3A83C15D9; Tue, 5 Jul 2016 20:22:46 +1000 (AEST) Date: Tue, 5 Jul 2016 20:22:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Adrian Chadd cc: Ed Schouten , Benjamin Kaduk , Bruce Evans , Konstantin Belousov , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" Subject: Re: svn commit: r302252 - head/sys/kern In-Reply-To: Message-ID: <20160705202144.S1961@besplex.bde.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=OtmysHLt c=1 sm=1 tr=0 a=XDAe9YG+7EcdVXYrgT+/UQ==:117 a=XDAe9YG+7EcdVXYrgT+/UQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=Z5fnprLDicSC4eaaG4IA:9 a=CjuIK1q_8ugA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 10:22:56 -0000 On Mon, 4 Jul 2016, Adrian Chadd wrote: > On 4 July 2016 at 12:28, Ed Schouten wrote: >> 2016-07-04 21:08 GMT+02:00 Adrian Chadd : >>> 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