> From: bugzi...@dpdk.org [mailto:bugzi...@dpdk.org]
> Sent: Wednesday, 15 June 2022 09.16
>
> https://bugs.dpdk.org/show_bug.cgi?id=1035
>
> Bug ID: 1035
> Summary: __rte_raw_cksum() crash with misaligned pointer
> Product: DPDK
> Version: 21.11
> Hardware: All
> OS: All
> Status: UNCONFIRMED
> Severity: normal
> Priority: Normal
> Component: ethdev
> Assignee: dev@dpdk.org
> Reporter: emil.b...@ericsson.com
> Target Milestone: ---
>
> See rte_raw_cksum() in rte_ip.h, which is part of the public API. See
> also the
> subfunction __rte_raw_cksum().
>
> _rte_raw_cksum assumes that the buffer over which the checksum is
> calculated is
> an even address (divisible by two). See for example this stack overflow
> post:
> https://stackoverflow.com/questions/46790550/c-undefined-behavior-
> strict-aliasing-rule-or-incorrect-alignment
>
> The post explains that there is undefined behavior in C11 when
> "conversion
> between two pointer types produces a result that is incorrectly
> aligned". When
> the buf argument starts on an odd address we thus have undefined
> behavior,
> since a pointer is cast from void* to uint16_t*.
>
> In most cases (at least on x86) that isn't a problem, but with higher
> optimization levels it may break due to vector instructions. This new
> function
> seems to be easier to optimize by the compiler, resulting in a crash
> when the
> buf argument is odd. Please note that the undefined behavior is present
> in
> earlier versions of dpdk as well.
>
> Now you're probably thinking: "Just align your buffers". The problem is
> that we
> have a packet buffer which is aligned. The checksum is calculated on a
> subset
> of that aligned packet buffer, and that sometimes lies on odd
> addresses.
>
> The question remains if this is an issue with dpdk or not.
I can imagine other systems doing what you describe too. So it needs to be
addressed.
Off the top of my head, an easy fix would be updating __rte_raw_cksum() like
this:
static inline uint32_t
__rte_raw_cksum(const void *buf, size_t len, uint32_t sum)
{
if (likely((buf & 1) == 0)) {
/* The buffer is 16 bit aligned. */
Keep the existing, optimized implementation here.
} else {
/* The buffer is not 16 bit aligned. */
Add a new odd-buf tolerant implementation here.
}
}
However, I'm not sure that it covers your scenario!
The checksum is 16 bit wide, so if you calculate the checksum of e.g. 4 bytes
of memory starting at offset 1 in a 6 byte packet buffer, the memory block can
be treated as either 4 or 6 bytes relative to the data covered by the checksum,
i.e.:
A: XX [01 02] [03 04] XX --> cksum = [04 06]
B: [XX 01] [02 03] [04 XX] --> cksum = [06 04]
Which one do you need?
Perhaps an additional function is required to support your use case, and the
documentation for rte_raw_cksum() and __rte_raw_cksum() needs to reflect that
the buffer must be 16 bit aligned.
Or the rte_raw_cksum() function can be modified to support an odd buffer
pointer as outlined above, with documentation added about alignment of the
running checksum.
