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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 01 Oct 2021 22:10:08 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     "Cufi, Carles" <Carles.Cufi@...dicsemi.no>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jukka.rissanen@...ux.intel.com" <jukka.rissanen@...ux.intel.com>,
        "johan.hedberg@...el.com" <johan.hedberg@...el.com>,
        "Lubos, Robert" <Robert.Lubos@...dicsemi.no>,
        "Bursztyka, Tomasz" <tomasz.bursztyka@...el.com>,
        linux-toolchains@...r.kernel.org
Subject: Re: Non-packed structures in IP headers

* Carles Cufi:

> I was looking through the structures for IPv{4,6} packet headers and
> noticed that several of those that seem to be used to parse a packet
> directly from the wire are not declared as packed. This surprised me
> because, although I did find that provisions are made so that the
> alignment of the structure, it is still technically possible for the
> compiler to inject padding bytes inside those structures, since AFAIK
> the C standard makes no guarantees about padding unless it's
> instructed to pack the structure.

The C standards do not make such guarantees, but the platform ABI
standards describe struct layout and ensure that there is no padding.
Linux relies on that not just for networking, but also for the userspace
ABI, support for separately compiled kernel modules, and in other
places.

Sometimes there are alignment concerns in the way these structs are
used, but I believe the kernel generally controls placement of the data
that is being worked on, so that does not matter, either.

Therefore, I do not believe this is an actual problem.

Thanks,
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ