From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755552AbcLNMxc (ORCPT ); Wed, 14 Dec 2016 07:53:32 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:49592 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755424AbcLNMx3 (ORCPT ); Wed, 14 Dec 2016 07:53:29 -0500 MIME-Version: 1.0 In-Reply-To: <20161214035927.30004-3-Jason@zx2c4.com> References: <20161214035927.30004-1-Jason@zx2c4.com> <20161214035927.30004-3-Jason@zx2c4.com> From: "Jason A. Donenfeld" Date: Wed, 14 Dec 2016 13:53:10 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform To: David Laight Cc: Netdev , kernel-hardening@lists.openwall.com, Andi Kleen , LKML , Linux Crypto Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Wed, Dec 14, 2016 at 10:51 AM, David Laight wrote: > From: Jason A. Donenfeld >> Sent: 14 December 2016 00:17 >> This gives a clear speed and security improvement. Rather than manually >> filling MD5 buffers, we simply create a layout by a simple anonymous >> struct, for which gcc generates rather efficient code. > ... >> + const struct { >> + struct in6_addr saddr; >> + struct in6_addr daddr; >> + __be16 sport; >> + __be16 dport; >> + } __packed combined = { >> + .saddr = *(struct in6_addr *)saddr, >> + .daddr = *(struct in6_addr *)daddr, >> + .sport = sport, >> + .dport = dport >> + }; > > You need to look at the effect of marking this (and the other) > structures 'packed' on architectures like sparc64. In all current uses of __packed in the code, I think the impact is precisely zero, because all structures have members in descending order of size, with each member being a perfect multiple of the one below it. The __packed is therefore just there for safety, in case somebody comes in and screws everything up by sticking a u8 in between. In that case, it wouldn't be desirable to hash the structure padding bits. In the worst case, I don't believe the impact would be worse than a byte-by-byte memcpy, which is what the old code did. But anyway, these structures are already naturally packed anyway, so the present impact is nil. Jason