linux-kernel - Re: [PATCH v2] random: vDSO: move prototype of arch chacha function to vdso/getrandom.h

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] [day] [month] [year] [list]

Message-ID: <CAHmME9p9vEN_zcwgFt07m7jtHJ3cxkN=yEQNNb5h8uYShJrajg@mail.gmail.com>
Date: Tue, 27 Aug 2024 18:55:22 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] random: vDSO: move prototype of arch chacha function
 to vdso/getrandom.h

On Tue, Aug 27, 2024 at 6:53 PM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:
>
>
>
> Le 27/08/2024 à 17:47, Jason A. Donenfeld a écrit :
> > Having the prototype for __arch_chacha20_blocks_nostack in
> > arch/x86/include/asm/vdso/getrandom.h meant that the prototype and large
> > doc comment were cloned by every architecture, which has been causing
> > unnecessary churn. Instead move it into include/vdso/getrandom.h, where
> > it can be shared by all archs implementing it.
> >
> > As a side bonus, this then lets us use that prototype in the
> > vdso_test_chacha self test, to ensure that it matches the source, and
> > indeed doing so turned up some inconsistencies, which are rectified
> > here.
>
> Side bonus that I dislike. Or ... it is all that u32 key stuff that I
> dislike.
>
> If it was really u32 I would be able to read it with a LWZ instruction
> (Load Word Zero extended). That's what I did at the begining. But if I
> want the selftest to work, I have to use LWBRX (Load Word Byte Reversed
> ...)instead  because the bytes in the word are in reversed order in reality.
>
> So either it is a table of 32 bytes, or it is as defined in RFC 7539:
>
>    A 256-bit key, treated as a concatenation of eight 32-bit
> little-endian integers.
>
> And in that case it is not a table of 8x u32 but table of 8x __le32

It's a table of bytes that are 4-byte aligned. Or, sure, a table of __le32.