netdev - Re: net: Zeroing the structure ethtool_wolinfo in ethtool_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3fa1ab8-c7de-8dd0-f7db-c058483941a1@solarflare.com>
Date:   Tue, 23 Aug 2016 17:46:14 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        Joe Perches <joe@...ches.com>
CC:     Luis Henriques <luis.henriques@...onical.com>,
        Avijit Kanti Das <avijitnsec@...eaurora.org>,
        "David S . Miller" <davem@...emloft.net>,
        "Ben Hutchings" <ben@...adent.org.uk>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol()

On 23/08/16 16:36, Eric Dumazet wrote:
> On Tue, 2016-08-23 at 08:05 -0700, Joe Perches wrote:
>
>> A compiler does not have a standards based requirement to
>> initialize arbitrary padding bytes.
>>
>> I believe gcc always does zero all padding anyway.
> Even if the current standards are lazy (are they, I did not check ?),
> security needs would call for a sane compiler behavior and changing the
> standards accordingly.
Sadly C99 is: section 6.2.6.1.6 (in draft N1256) says
  "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."
with a footnote (42) reading
  "Thus, for example, structure assignment need not copy any padding bits."

In C11 (or, at least, draft N1570), the corresponding text is identical,
only the footnote number has changed (51).
HOWEVER, section 6.7.9.10 has changed, and now (for static objects) reads:
  "if it is an aggregate, every member is initialized (recursively)
   according to these rules, _and_any_padding_is_initialized_to_zero_bits_"
(emphasis added).
On the other hand, a sufficiently pedantic (and perverse) language lawyer
could argue that the initialiser only "specifies the initial value stored
in an object" (6.7.9.8), and that when a value is 'stored in an object'
section 6.2.6.1.6 applies to the storing process after the initial value
has been constructed.
On the gripping hand, such an interpretation would cause the new 6.7.9.10
language to have no observable effect, and thus clearly cannot be what was
intended by the C11 committee.

Aren't you glad you asked?

In any case, there is more to life than standards lawyering, compilers
that don't zero the padding bytes are as a practical matter broken even
though not in violation of the (C99) standard.  Besides, it's not as if
Linux doesn't already have requirements on its compilers that go beyond
the standards...

-Ed