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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ