From: Dave Taht <dave.taht@gmail.com>
To: John Huttley <john@mib-infotech.co.nz>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Odd length headers and alignment
Date: Wed, 7 Dec 2016 10:28:50 -0800 [thread overview]
Message-ID: <CAA93jw5c4WM8zJq5Rdm5c0958cNmtGvAQ-Jjp+ALaz0oE_uCiQ@mail.gmail.com> (raw)
In-Reply-To: <e1f43ccf-85eb-8ad5-9bde-8332218fe3f8@mib-infotech.co.nz>
Instruction traps are really bad news on mips. We had to expressly
patch the entire linux kernel stack in the openwrt project to shift to
shorter loads on some arches (because other things come through the
stack, misaligned).
The fix was pretty simple tho, you just declare the relevant struct
__attribute__((packed, aligned(2)));
(see http://git.razvi.ro/?p=3Dopenwrt.git&a=3Dcommitdiff&h=3Dc0bcd44660e5ff=
27068bbcc1a5e3ee5f2483a9c3
)
Still, I'd support a pad.
On Wed, Dec 7, 2016 at 10:17 AM, John Huttley <john@mib-infotech.co.nz> wro=
te:
> I think an extra byte would be a great idea.
> We can use that in the future to implement a user space
> IUnknown/O_PONIES end to end negotiation
>
> --John
>
>
>
> On 8/12/2016 7:11 a.m., Jason A. Donenfeld wrote:
>> Hey guys,
>>
>> Wireguard data packets have a 1 byte type, a 4 byte index, an 8 byte
>> nonce, the ciphertext, and then a 16 byte auth tag. Having 13 bytes in
>> the beginning means that when we do in-place decryption, the plaintext
>> winds up starting at an odd-byte, transferring misalignment down to
>> the rest of the stack.
>>
>> Now, in my testing on alignment-sensitive MIPS boxes, I've only had
>> alignment exceptions with this regarding the first byte, which is the
>> version number of the IP header. Since this is just a single byte, the
>> alignment doesn't actually matter. But in practice, the compiler
>> generates a 16-bit load instead of an 8-bit load, which sucks. I may
>> be able to work around this though. Beyond that, I haven't actually
>> observed exceptions from elsewhere in the stack regarding
>> misalignment.
>>
>> So, how much of a problem do you suppose this is? Would it be
>> worthwhile to stick an _extra byte_ in the header, just to get even
>> alignment? Or an extra three bytes to get 16-byte alignment? Or do you
>> suppose this isn't really worth the bloat and MTU loss?
>>
>> Just something to think about...
>>
>> Jason
>> _______________________________________________
>> WireGuard mailing list
>> WireGuard@lists.zx2c4.com
>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
--=20
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
prev parent reply other threads:[~2016-12-07 18:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-07 18:11 Jason A. Donenfeld
2016-12-07 18:17 ` John Huttley
2016-12-07 18:28 ` Dave Taht [this message]
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=CAA93jw5c4WM8zJq5Rdm5c0958cNmtGvAQ-Jjp+ALaz0oE_uCiQ@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=john@mib-infotech.co.nz \
--cc=wireguard@lists.zx2c4.com \
/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).