[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <924ef794-eae0-2a6b-508b-069718339edc@stressinduktion.org>
Date: Thu, 15 Dec 2016 16:53:12 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: David Laight <David.Laight@...LAB.COM>,
"Jason A. Donenfeld" <Jason@...c4.com>
Cc: Netdev <netdev@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
"Daniel J . Bernstein" <djb@...yp.to>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Eric Biggers <ebiggers3@...il.com>
Subject: Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable
function
On 15.12.2016 16:41, David Laight wrote:
> 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.
I used __alignof__(unsigned long long) with -m32.
>> 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.
Yes, and that is actually my fear, because we support those
architectures. I can't comment on that as I don't understand enough of this.
If someone finds a way to cause misaligned reads on a small box this
seems (maybe depending on sysctls they get fixed up or panic) to be a
much bigger issue than having a hash DoS.
Thanks,
Hannes
Powered by blists - more mailing lists