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.
  
- Generating a HalfSipHash key
- ============================
+ On 64-bit kernels, the hsiphash functions actually implement SipHash-1-3, a
+ reduced-round variant of SipHash, instead of HalfSipHash-1-3. This is because in
+ 64-bit code, SipHash-1-3 is no slower than HalfSipHash-1-3, and can be faster.
+ Note, this does *not* mean that in 64-bit kernels the hsiphash functions are the
+ same as the siphash ones, or that they are secure; the hsiphash functions still
+ use a less secure reduced-round algorithm and truncate their outputs to 32
+ bits.
+ 
+ Generating a hsiphash key
+ =========================
  
  Keys should always be generated from a cryptographically secure source of
  random numbers, either using get_random_bytes or get_random_once::

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

Eric Biggers <ebiggers@kernel.org> writes:

> 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?

If you want changes to parts of Documentation/ to not go through the
docs tree, just say the word and I'll avoid it.  A MAINTAINERS file
addition to direct those patches youward would also not be misplaced.

Meanwhile, Jason, if you want to pick up the offending patches directly,
I can drop them from docs-next.

Thanks,

jon

Hey Jonathan, Eric,

On Fri, Apr 22, 2022 at 01:21:56AM -0600, Jonathan Corbet wrote:
> Eric Biggers <ebiggers@kernel.org> writes:
> 
> > 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?
> 
> If you want changes to parts of Documentation/ to not go through the
> docs tree, just say the word and I'll avoid it.  A MAINTAINERS file
> addition to direct those patches youward would also not be misplaced.
> 
> Meanwhile, Jason, if you want to pick up the offending patches directly,
> I can drop them from docs-next.

Ah, I hadn't seen that other patch because it wasn't CC'd to me, but
that makes sense since it was mostly a docs fix rather than a
substantive technical change. Since we've now got both going on at once,
I'll just take the docs one to make the conflict easier, so sure, drop
it from your tree, and I'll apply it to mine.

Jason

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> Ah, I hadn't seen that other patch because it wasn't CC'd to me, but
> that makes sense since it was mostly a docs fix rather than a
> substantive technical change.

If you do want to see such things, I recommend a line in MAINTAINERS to
make it happen.

> Since we've now got both going on at once,
> I'll just take the docs one to make the conflict easier, so sure, drop
> it from your tree, and I'll apply it to mine.

OK, I've disappeared the offending commits and force-pushed docs-next.

Thanks,

jon

Hey again,

On Fri, Apr 22, 2022 at 11:02:33AM +0200, Jason A. Donenfeld wrote:
> > Meanwhile, Jason, if you want to pick up the offending patches directly,
> > I can drop them from docs-next.
> 
> Ah, I hadn't seen that other patch because it wasn't CC'd to me, but
> that makes sense since it was mostly a docs fix rather than a
> substantive technical change. Since we've now got both going on at once,
> I'll just take the docs one to make the conflict easier, so sure, drop
> it from your tree, and I'll apply it to mine.

Done, with the build conflicts fixed up. These are now in my tree:

- 3608cbde2518 ("Documentation: siphash: convert danger note to warning for HalfSipHash")
- 3addb633c82f ("Documentation: siphash: enclose HalfSipHash usage example in the literal block")
- 1ed2075e7202 ("Documentation: siphash: disambiguate HalfSipHash algorithm from hsiphash functions")

Jason