linux-kernel - Re: linux-next: manual merge of the random tree with the jc

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: <YmJMBnBV8wO4aco9@sol.localdomain>
Date:   Thu, 21 Apr 2022 23:32:38 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Theodore Ts'o <tytso@....edu>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Jonathan Corbet <corbet@....net>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the random tree with the jc_docs tree

On Fri, Apr 22, 2022 at 01:59:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the random tree got a conflict in:
> 
>   Documentation/security/siphash.rst
> 
> between commits:
> 
>   dc701cfc5b26 ("Documentation: siphash: convert danger note to warning for HalfSipHash")
>   561fb3cd5ec2 ("Documentation: siphash: enclose HalfSipHash usage example in the literal block")
> 
> from the jc_docs tree and commit:
> 
>   91afe794c070 ("siphash: update the hsiphash documentation")
> 
> from the random tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc Documentation/security/siphash.rst
> index 06d793e68086,79ac8101406c..000000000000
> --- a/Documentation/security/siphash.rst
> +++ b/Documentation/security/siphash.rst
> @@@ -121,15 -121,23 +121,25 @@@ even scarier, uses an easily brute-forc
>   instead of SipHash's 128-bit key. However, this may appeal to some
>   high-performance `jhash` users.
>   
> + HalfSipHash support is provided through the "hsiphash" family of functions.
> + 
>  -**Danger!** Do not ever use the hsiphash functions except for as a hashtable key
>  -function, and only then when you can be absolutely certain that the outputs will
>  -never be transmitted out of the kernel. This is only remotely useful over
>  -`jhash` as a means of mitigating hashtable flooding denial of service attacks.
>  +.. warning::
>  +   Do not ever use HalfSipHash except for as a hashtable key function, and
>  +   only then when you can be absolutely certain that the outputs will never
>  +   be transmitted out of the kernel. This is only remotely useful over
>  +   `jhash` as a means of mitigating hashtable flooding denial of service
>  +   attacks.

That's not exactly the correct resolution, since it dropped the change to the
text of this paragraph that my patch made ("HalfSipHash" => "the hsiphash
functions").

We should get the updates to this file to go through one tree.  Jason, probably
you'd want it to be yours?

- Eric