From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Jason@zx2c4.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 82dacfd2 for ; Sun, 11 Dec 2016 14:44:40 +0000 (UTC) Received: from frisell.zx2c4.com (frisell.zx2c4.com [192.95.5.64]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 5ceb1a20 for ; Sun, 11 Dec 2016 14:44:40 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 3be9ceb2 for ; Sun, 11 Dec 2016 14:44:40 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id ab03c270 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Sun, 11 Dec 2016 14:44:39 +0000 (UTC) Received: by mail-wm0-f45.google.com with SMTP id c184so6689441wmd.0 for ; Sun, 11 Dec 2016 06:50:34 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20161211071501.GA32621@kroah.com> References: <095cac5b-b757-6f4a-e699-8eedf9ed7221@stressinduktion.org> <87vauvhwdu.fsf@alice.fifthhorseman.net> <20161211071501.GA32621@kroah.com> From: "Jason A. Donenfeld" Date: Sun, 11 Dec 2016 15:50:31 +0100 Message-ID: Subject: Re: Misalignment, MIPS, and ip_hdr(skb)->version To: linux-mips@linux-mips.org, Netdev , LKML Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= , Jiri Benc , David Miller , Hannes Frederic Sowa , Willy Tarreau , WireGuard mailing list , Felix Fietkau List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hey guys, Thanks for the extremely detailed answers. The main take-away from this is that passing unaligned packets to the networking stack kills kittens. So now it's a question of mitigation. I have three options: 1. Copy the plaintext to three bytes before the start of the cipher text, overwriting parts of the header that aren't actually required. Pros: no changes required, MTU stays small. Cons: scatterwalk's fast paths aren't hit, which means two page table mappings are taken instead of one. I have no idea if this actually matters or will slow down anything relavent. 2. Add 3 bytes to the plaintext header, set to zero, marked for future use. Pros: satisfies IETF mantras and makes unaligned in-place decryption straightforward. Cons: lowers MTU, additional unauthenticated cleartext bits in the header are of limited utility in protocol. 3. Add 3 bytes of padding, set to zero, to the encrypted section just before the IP header, marked for future use. Pros: satisfies IETF mantras, can use those extra bits in the future for interesting protocol extensions for authenticated peers. Cons: lowers MTU, marginally more difficult to implement but still probably just one or two lines of code. Of these, I'm leaning toward (3). Anyway, thanks a lot for the input. "Doing nothing" is no longer under serious consideration, thanks to your messages. Thanks, Jason