linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "'Hannes Frederic Sowa'" <hannes@stressinduktion.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Netdev <netdev@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
	"Daniel J . Bernstein" <djb@cr.yp.to>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Eric Biggers <ebiggers3@gmail.com>
Subject: RE: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function
Date: Thu, 15 Dec 2016 15:41:46 +0000	[thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB0240529@AcuExch.aculab.com> (raw)
In-Reply-To: <f6813084-6f46-0b22-e9c3-97b2e266f8f6@stressinduktion.org>

From: Hannes Frederic Sowa
> Sent: 15 December 2016 14:57
> On 15.12.2016 14:56, David Laight wrote:
> > From: Hannes Frederic Sowa
> >> Sent: 15 December 2016 12:50
> >> On 15.12.2016 13:28, David Laight wrote:
> >>> From: Hannes Frederic Sowa
> >>>> Sent: 15 December 2016 12:23
> >>> ...
> >>>> Hmm? Even the Intel ABI expects alignment of unsigned long long to be 8
> >>>> bytes on 32 bit. Do you question that?
> >>>
> >>> Yes.
> >>>
> >>> The linux ABI for x86 (32 bit) only requires 32bit alignment for u64 (etc).
> >>
> >> Hmm, u64 on 32 bit is unsigned long long and not unsigned long. Thus I
> >> am actually not sure if the ABI would say anything about that (sorry
> >> also for my wrong statement above).
> >>
> >> Alignment requirement of unsigned long long on gcc with -m32 actually
> >> seem to be 8.
> >
> > It depends on the architecture.
> > For x86 it is definitely 4.
> 
> May I ask for a reference?

Ask anyone who has had to do compatibility layers to support 32bit
binaries on 64bit systems.

> I couldn't see unsigned long long being
> mentioned in the ia32 abi spec that I found. I agree that those accesses
> might be synthetically assembled by gcc and for me the alignment of 4
> would have seemed natural. But my gcc at least in 32 bit mode disagrees
> with that.

Try (retyped):

echo 'struct { long a; long long b; } s; int bar { return sizeof s; }' >foo.c
gcc [-m32] -O2 -S foo.c; cat foo.s

And look at what is generated.

> Right now ipv6 addresses have an alignment of 4. So we couldn't even
> naturally pass them to siphash but would need to copy them around, which
> I feel like a source of bugs.

That is more of a problem on systems that don't support misaligned accesses.
Reading the 64bit values with two explicit 32bit reads would work.
I think you can get gcc to do that by adding an aligned(4) attribute to the
structure member.

	David

  reply	other threads:[~2016-12-15 15:41 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14  3:59 [PATCH v2 1/4] siphash: add cryptographically secure hashtable function Jason A. Donenfeld
2016-12-14  3:59 ` [PATCH v2 2/4] siphash: add convenience functions for jhash converts Jason A. Donenfeld
2016-12-14  3:59 ` [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform Jason A. Donenfeld
2016-12-14 12:53   ` Jason A. Donenfeld
2016-12-14 13:16     ` Hannes Frederic Sowa
2016-12-14 13:44       ` Jason A. Donenfeld
2016-12-14 14:47         ` David Laight
2016-12-14 17:49           ` Jason A. Donenfeld
2016-12-14 17:56     ` David Miller
2016-12-14 18:06       ` Jason A. Donenfeld
2016-12-14 19:22         ` Hannes Frederic Sowa
2016-12-14 19:38           ` Jason A. Donenfeld
2016-12-14 20:27             ` Hannes Frederic Sowa
2016-12-14 20:12     ` Tom Herbert
2016-12-14 21:01       ` Jason A. Donenfeld
2016-12-14  3:59 ` [PATCH v2 4/4] random: use siphash24 instead of md5 for get_random_int/long Jason A. Donenfeld
2016-12-14 11:21 ` [PATCH v2 1/4] siphash: add cryptographically secure hashtable function Hannes Frederic Sowa
2016-12-14 13:10   ` Jason A. Donenfeld
2016-12-14 15:09     ` Hannes Frederic Sowa
2016-12-14 19:47       ` Jason A. Donenfeld
2016-12-15  7:57     ` Herbert Xu
2016-12-15  8:15       ` [kernel-hardening] " Daniel Micay
2016-12-14 12:46 ` Jason A. Donenfeld
2016-12-14 22:03   ` Hannes Frederic Sowa
2016-12-14 23:29     ` Jason A. Donenfeld
2016-12-15  8:31       ` Hannes Frederic Sowa
2016-12-15 11:04     ` David Laight
2016-12-15 12:23       ` Hannes Frederic Sowa
2016-12-15 12:28         ` David Laight
2016-12-15 12:50           ` Hannes Frederic Sowa
2016-12-15 13:56             ` David Laight
2016-12-15 14:56               ` Hannes Frederic Sowa
2016-12-15 15:41                 ` David Laight [this message]
2016-12-15 15:53                   ` Hannes Frederic Sowa
2016-12-15 18:50                     ` Jason A. Donenfeld
2016-12-15 20:31                       ` Hannes Frederic Sowa
2016-12-15 20:43                         ` Jason A. Donenfeld
2016-12-15 21:04                           ` Peter Zijlstra
2016-12-15 21:09                             ` Hannes Frederic Sowa
2016-12-15 21:17                           ` Hannes Frederic Sowa
2016-12-15 21:09                       ` Peter Zijlstra
2016-12-15 21:11                         ` [kernel-hardening] " Jason A. Donenfeld
2016-12-15 21:14                           ` Linus Torvalds
2016-12-14 18:46 ` [PATCH v3 1/3] " Jason A. Donenfeld
2016-12-14 18:46   ` [PATCH v3 2/3] secure_seq: use siphash24 instead of md5_transform Jason A. Donenfeld
2016-12-14 21:44     ` kbuild test robot
2016-12-14 18:46   ` [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long Jason A. Donenfeld
2016-12-14 21:56     ` kbuild test robot
2016-12-14 21:57     ` kbuild test robot
2016-12-15 10:14     ` David Laight
2016-12-15 18:51       ` Jason A. Donenfeld
2016-12-14 19:18   ` [PATCH v3 1/3] siphash: add cryptographically secure hashtable function Tom Herbert
2016-12-14 19:35     ` Jason A. Donenfeld
2016-12-14 20:55       ` Jason A. Donenfeld
2016-12-14 21:35         ` Tom Herbert
2016-12-14 22:56           ` Jason A. Donenfeld
2016-12-14 23:14             ` Tom Herbert
2016-12-14 23:17               ` Jason A. Donenfeld
2016-12-18  0:06                 ` Christian Kujau
2016-12-14 23:30             ` Linus Torvalds
2016-12-14 23:34               ` Jason A. Donenfeld
2016-12-15  0:10                 ` Linus Torvalds
2016-12-15 10:22                   ` David Laight
2016-12-14 21:15   ` kbuild test robot
2016-12-14 21:21     ` Jason A. Donenfeld
2016-12-15  1:46   ` [PATCH v4 1/4] " Jason A. Donenfeld
2016-12-15  1:46     ` [PATCH v4 2/4] siphash: add N[qd]word helpers Jason A. Donenfeld
2016-12-15  1:46     ` [PATCH v4 3/4] secure_seq: use siphash instead of md5_transform Jason A. Donenfeld
2016-12-15  1:46     ` [PATCH v4 4/4] random: use siphash instead of MD5 for get_random_int/long Jason A. Donenfeld
2016-12-15  4:23     ` [PATCH v4 1/4] siphash: add cryptographically secure hashtable function kbuild test robot
2016-12-15 21:25 [PATCH v2 " Jason A. Donenfeld
2016-12-15 21:45 ` Hannes Frederic Sowa
2016-12-15 23:43   ` Jason A. Donenfeld
2016-12-16  0:03     ` Hannes Frederic Sowa
2016-12-15 23:47   ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=063D6719AE5E284EB5DD2968C1650D6DB0240529@AcuExch.aculab.com \
    --to=david.laight@aculab.com \
    --cc=Jason@zx2c4.com \
    --cc=djb@cr.yp.to \
    --cc=ebiggers3@gmail.com \
    --cc=hannes@stressinduktion.org \
    --cc=jeanphilippe.aumasson@gmail.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).