netdev - Re: lib/packing.c behaving weird if buffer length is not multiple of 4 with QUIRK_LSW32_IS

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: <20240818132910.jmsvqg363vkzbaxw@skbuf>
Date: Sun, 18 Aug 2024 16:29:10 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: lib/packing.c behaving weird if buffer length is not multiple of
 4 with QUIRK_LSW32_IS_FIRST

Hi Jake,

On Fri, Aug 16, 2024 at 04:37:22PM -0700, Jacob Keller wrote:
> I'm honestly not sure what the right solution here is, because the way
> LITTLE_ENDIAN and LSW32_IS_FIRST work they effectively *require*
> word-aligned sizes. If we use a word-aligned size, then they both make
> sense, but my hardware buffer isn't word aligned. I can cheat, and just
> make sure I never use bits that access the invalid parts of the buffer..
> but that seems like the wrong solution... A larger size would break
> normal Big endian ordering without quirks...

It is a use case that I would like to support. Thanks for having the
patience to explain the issue to me.

> Really, what my hardware buffer wants is to map the lowest byte of the
> data to the lowest byte of the buffer. This is what i would consider
> traditionally little endian ordering.
> 
> This also happens to be is equivalent to LSW32_IS_FIRST and
> LITTLE_ENDIAN when sizes are multiples of 4.

Yes, "traditionally little endian" would indeed translate into
QUIRK_LSW32_IS_FIRST | QUIRK_LITTLE_ENDIAN. Your use of the API seems
correct. I did need that further distinction between "little endian
within a group of 4 bytes" and "little endian among groups of 4 bytes"
because the NXP SJA1105 memory layout is weird like that, and is
"little endian" in one way but not in another. Anyway..

I've attached 2 patches which hopefully make the API usable for your
driver. I've tested them locally and did not notice issues.

View attachment "0001-lib-packing-refuse-operating-on-bit-indices-which-ex.patch" of type "text/x-diff" (1510 bytes)

View attachment "0002-lib-packing-adjust-definitions-and-implementation-fo.patch" of type "text/x-diff" (9052 bytes)