Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936660AbcLOPl4 (ORCPT ); Thu, 15 Dec 2016 10:41:56 -0500 Received: from smtp-out6.electric.net ([192.162.217.187]:60968 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932595AbcLOPly (ORCPT ); Thu, 15 Dec 2016 10:41:54 -0500 From: David Laight To: "'Hannes Frederic Sowa'" , "Jason A. Donenfeld" CC: Netdev , "kernel-hardening@lists.openwall.com" , Jean-Philippe Aumasson , LKML , "Linux Crypto Mailing List" , "Daniel J . Bernstein" , Linus Torvalds , Eric Biggers Subject: RE: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function Thread-Topic: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function Thread-Index: AQHSVlXqRQkWzQTQMEKnoUhn/mXjb6EI16gAgAAXtACAAAD1UIAABoMAgAASNlCAABE2gIAACYzg Date: Thu, 15 Dec 2016 15:41:46 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB0240529@AcuExch.aculab.com> References: <20161214035927.30004-1-Jason@zx2c4.com> <8ea3fdff-23c4-b81d-2588-44549bd2d8c1@stressinduktion.org> <063D6719AE5E284EB5DD2968C1650D6DB02401ED@AcuExch.aculab.com> <707472e1-b385-836d-c4c6-791c1dcc0776@stressinduktion.org> <063D6719AE5E284EB5DD2968C1650D6DB02402C0@AcuExch.aculab.com> <0f3c3694-c00b-aae2-5b08-25bc64bf6372@stressinduktion.org> <063D6719AE5E284EB5DD2968C1650D6DB0240437@AcuExch.aculab.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id uBFFg125021938 Content-Length: 1881 Lines: 55 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