svn commit: r302252 - head/sys/kern

[Bruce Evans]

On Mon, 4 Jul 2016, Adrian Chadd wrote:

> On 4 July 2016 at 12:28, Ed Schouten <ed at nuxi.nl> wrote:
>> 2016-07-04 21:08 GMT+02:00 Adrian Chadd <adrian.chadd at 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