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 stack only cares about the
>>
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 the
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 for
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 there's going to be
> 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, overwrit
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 would suggest pushing 3 dummy garb
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 padding at the front
>
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
> >> header. Most protocols of t
> 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
>> possible to e.g. pad opti
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 wrote:
>> It's so much better to analyze pro
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 properly where the misalignment comes from
> and ad
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
and address it at the source, as we ha
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 various cases that trip up
>>> Sparc too.
>
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.
>
> That's sort of my attitude
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 don'
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 padding at the front
>> or the end 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 alignment is really the bes
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 figure out what the header configuration loo
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 the originating device
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 heade
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 that trip up
>> Sparc too.
>
> That's
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. Any
pointers you have
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 much better to analyz
The openwrt tree has long contained a set of patches that correct for
unaligned issues throughout the linux network stack.
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=ee53
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
p
27 matches
Mail list logo
