David Laight writes:
> From: Måns Rullgård
>> Sent: 10 December 2016 13:25
> ...
>> I solved this problem in an Ethernet driver by copying the initial part
>> of the packet to an aligned skb and appending the remainder using
>> skb_add_rx_frag(). The kernel network
From: Måns Rullgård
> Sent: 10 December 2016 13:25
...
> I solved this problem in an Ethernet driver by copying the initial part
> of the packet to an aligned skb and appending the remainder using
> skb_add_rx_frag(). The kernel network stack only cares about the
> headers, so the alignment of
On Sun, Dec 11, 2016 at 03:50:31PM +0100, Jason A. Donenfeld wrote:
> 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
On Sun, Dec 11, 2016 at 4:30 PM, Andrew Lunn wrote:
> I'm not a crypto expert, but does this not give you a helping hand in
> breaking the crypto? You know the plain text value of these bytes, and
> where they are in the encrypted text.
You also know with some probability that
> 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
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,
Willy Tarreau writes:
> Hi Jason,
>
> On Thu, Dec 08, 2016 at 11:20:04PM +0100, Jason A. Donenfeld wrote:
>> Hi David,
>>
>> On Thu, Dec 8, 2016 at 1:37 AM, David Miller wrote:
>> > You really have to land the IP header on a proper 4 byte boundary.
>> >
>> > I
Hi Jason,
On Thu, Dec 08, 2016 at 11:20:04PM +0100, Jason A. Donenfeld wrote:
> Hi David,
>
> On Thu, Dec 8, 2016 at 1:37 AM, David Miller wrote:
> > You really have to land the IP header on a proper 4 byte boundary.
> >
> > I would suggest pushing 3 dummy garbage bytes of
On Sat, Dec 10, 2016 at 11:18:14PM +0100, Dan Lüdtke wrote:
>
> > On 8 Dec 2016, at 05:34, Daniel Kahn Gillmor wrote:
> >
> > On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
> >> Your custom protocol should be designed in a way you get an aligned ip
> >>
> On 8 Dec 2016, at 05:34, Daniel Kahn Gillmor wrote:
>
> On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
>> Your custom protocol should be designed in a way you get an aligned ip
>> header. Most protocols of the IETF follow this mantra and it is always
>>
On 2016-12-10 21:32, Måns Rullgård wrote:
> Felix Fietkau writes:
>
>> On 2016-12-10 14:25, Måns Rullgård wrote:
>>> Felix Fietkau writes:
>>>
On 2016-12-07 19:54, Jason A. Donenfeld wrote:
> On Wed, Dec 7, 2016 at 7:51 PM, David Miller
Felix Fietkau writes:
> On 2016-12-10 14:25, Måns Rullgård wrote:
>> Felix Fietkau writes:
>>
>>> On 2016-12-07 19:54, Jason A. Donenfeld wrote:
On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
> It's so much better to analyze
On 2016-12-10 14:25, Måns Rullgård wrote:
> Felix Fietkau writes:
>
>> On 2016-12-07 19:54, Jason A. Donenfeld wrote:
>>> On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
It's so much better to analyze properly where the misalignment comes from
Felix Fietkau writes:
> On 2016-12-07 19:54, Jason A. Donenfeld wrote:
>> On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
>>> It's so much better to analyze properly where the misalignment comes from
>>> and address it at the source, as we have for
On 2016-12-07 19:54, Jason A. Donenfeld wrote:
> On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
>> It's so much better to analyze properly where the misalignment comes from
>> and address it at the source, as we have for various cases that trip up
>> Sparc too.
>
>
On Wed, 07 Dec 2016 23:34:21 -0500, Daniel Kahn Gillmor wrote:
> fwiw, i'm not convinced that "most protocols of the IETF follow this
> mantra". we've had multiple discussions in different protocol groups
> about shaving or bloating by a few bytes here or there in different
> protocols, and i
From: "Jason A. Donenfeld"
Date: Thu, 8 Dec 2016 23:20:04 +0100
> Hi David,
>
> On Thu, Dec 8, 2016 at 1:37 AM, David Miller wrote:
>> You really have to land the IP header on a proper 4 byte boundary.
>>
>> I would suggest pushing 3 dummy garbage bytes of
Hi David,
On Thu, Dec 8, 2016 at 1:37 AM, David Miller wrote:
> You really have to land the IP header on a proper 4 byte boundary.
>
> I would suggest pushing 3 dummy garbage bytes of padding at the front
> or the end of your header.
Are you sure 3 bytes to get 4 byte
On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
> Your custom protocol should be designed in a way you get an aligned ip
> header. Most protocols of the IETF follow this mantra and it is always
> possible to e.g. pad options so you end up on aligned boundaries for the
> next header.
From: "Jason A. Donenfeld"
Date: Thu, 8 Dec 2016 01:29:42 +0100
> On Wed, Dec 7, 2016 at 8:52 PM, David Miller wrote:
>> The only truly difficult case to handle is GRE encapsulation. Is
>> that the situation you are running into?
>>
>> If not, please
On Wed, Dec 7, 2016 at 8:52 PM, David Miller wrote:
> The only truly difficult case to handle is GRE encapsulation. Is
> that the situation you are running into?
>
> If not, please figure out what the header configuration looks like
> in the case that hits for you, and what
Hi Jason,
On 07.12.2016 19:35, Jason A. Donenfeld wrote:
> I receive encrypted packets with a 13 byte header. I decrypt the
> ciphertext in place, and then discard the header. I then pass the
> plaintext to the rest of the networking stack. The plaintext is an IP
> packet. Due to the 13 byte
From: "Jason A. Donenfeld"
Date: Wed, 7 Dec 2016 19:54:12 +0100
> On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
>> It's so much better to analyze properly where the misalignment comes from
>> and address it at the source, as we have for various cases
On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
> It's so much better to analyze properly where the misalignment comes from
> and address it at the source, as we have for various cases that trip up
> Sparc too.
That's sort of my attitude too, hence starting this thread.
From: Dave Taht
Date: Wed, 7 Dec 2016 10:47:16 -0800
> https://git.lede-project.org/?p=openwrt/source.git;a=blob;f=target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch;h=b4b749e4b9c02a74a9f712a2740d63e554de5c64;hb=ee53a240ac902dc83209008a2671e7fdcf55957a
It's so
The openwrt tree has long contained a set of patches that correct for
unaligned issues throughout the linux network stack.
Hey MIPS Networking People,
I receive encrypted packets with a 13 byte header. I decrypt the
ciphertext in place, and then discard the header. I then pass the
plaintext to the rest of the networking stack. The plaintext is an IP
packet. Due to the 13 byte header that was discarded, the plaintext
27 matches
Mail list logo