netdev - Re: Non-packed structures in IP headers

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]

Message-ID: <87bl48v74v.fsf@oldenburg.str.redhat.com>
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