* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Hannes Frederic Sowa @ 2015-01-28 14:17 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, Vladislav Yasevich, virtualization, edumazet,
Ben Hutchings
In-Reply-To: <20150128134335.GA31959@redhat.com>
On Mi, 2015-01-28 at 15:43 +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 28, 2015 at 11:34:02AM +0100, Hannes Frederic Sowa wrote:
> > Hi,
> >
> > On Mi, 2015-01-28 at 11:46 +0200, Michael S. Tsirkin wrote:
> > > On Wed, Jan 28, 2015 at 09:25:08AM +0100, Hannes Frederic Sowa wrote:
> > > > Hello,
> > > >
> > > > On Di, 2015-01-27 at 18:08 +0200, Michael S. Tsirkin wrote:
> > > > > On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
> > > > > > On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
> > > > > > > On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
> > > > > > > > On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> > > > > > > >> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> > > > > > > >>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> > > > > > > >>>> If the IPv6 fragment id has not been set and we perform
> > > > > > > >>>> fragmentation due to UFO, select a new fragment id.
> > > > > > > >>>> When we store the fragment id into skb_shinfo, set the bit
> > > > > > > >>>> in the skb so we can re-use the selected id.
> > > > > > > >>>> This preserves the behavior of UFO packets generated on the
> > > > > > > >>>> host and solves the issue of id generation for packet sockets
> > > > > > > >>>> and tap/macvtap devices.
> > > > > > > >>>>
> > > > > > > >>>> This patch moves ipv6_select_ident() back in to the header file.
> > > > > > > >>>> It also provides the helper function that sets skb_shinfo() fragd have to patch both kernels *in your case*.
If it's all done by host, then it's in a single place, on host.
> > > > > > > >>>> id and sets the bit.
> > > > > > > >>>>
> > > > > > > >>>> It also makes sure that we select the fragment id when doing
> > > > > > > >>>> just gso validation, since it's possible for the packet to
> > > > > > > >>>> come from an untrusted source (VM) and be forwarded through
> > > > > > > >>>> a UFO enabled device which will expect the fragment id.
> > > > > > > >>>>
> > > > > > > >>>> CC: Eric Dumazet <edumazet@google.com>
> > > > > > > >>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > > > > > >>>> ---
> > > > > > > >>>> include/linux/skbuff.h | 3 ++-
> > > > > > > >>>> include/net/ipv6.h | 2 ++
> > > > > > > >>>> net/ipv6/ip6_output.c | 4 ++--
> > > > > > > >>>> net/ipv6/output_core.c | 9 ++++++++-
> > > > > > > >>>> net/ipv6/udp_offload.c | 10 +++++++++-
> > > > > > > >>>> 5 files changed, 23 insertions(+), 5 deletions(-)
> > > > > > > >>>>
> > > > > > > >>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > > > >>>> index 85ab7d7..3ad5203 100644
> > > > > > > >>>> --- a/include/linux/skbuff.h
> > > > > > > >>>> +++ b/include/linux/skbuff.h
> > > > > > > >>>> @@ -605,7 +605,8 @@ struct sk_buff {
> > > > > > > >>>> __u8 ipvs_property:1;
> > > > > > > >>>> __u8 inner_protocol_type:1;
> > > > > > > >>>> __u8 remcsum_offload:1;
> > > > > > > >>>> - /* 3 or 5 bit hole */
> > > > > > > >>>> + __u8 ufo_fragid_set:1;
> > > > > > > >>> [...]
> > > > > > > >>>
> > > > > > > >>> Doesn't the flag belong in struct skb_shared_info, rather than struct
> > > > > > > >>> sk_buff? Otherwise this looks fine.
> > > > > > > >>>
> > > > > > > >>> Ben.
> > > > > > > >>
> > > > > > > >> Hmm we seem to be out of tx flags.
> > > > > > > >> Maybe ip6_frag_id == 0 should mean "not set".
> > > > > > > >
> > > > > > > > Maybe that is the best idea. Definitely the ufo_fragid_set bit should
> > > > > > > > move into the skb_shared_info area.
> > > > > > >
> > > > > > > That's what I originally wanted to do, but had to move and grow txflags thus
> > > > > > > skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
> > > > > > >
> > > > > > > I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
> > > > > > > from the protocol perspective and could actually be generated by the id generator
> > > > > > > functions. This may cause us to call the id generation multiple times.
> > > > > >
> > > > > > Are there plans in the long run to let virtio_net transmit auxiliary
> > > > > > data to the other end so we can clean all of this this up one day?
> > > > > >
> > > > > > I don't like the whole situation: looking into the virtio_net headers
> > > > > > just adding a field for ipv6 fragmentation ids to those small structs
> > > > > > seems bloated, not doing it feels incorrect. :/
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Bye,
> > > > > > Hannes
> > > > >
> > > > > I'm not sure - what will be achieved by generating the IDs guest side as
> > > > > opposed to host side? It's certainly harder to get hold of entropy
> > > > > guest-side.
> > > >
> > > > It is not only about entropy but about uniqueness. Also fragmentation
> > > > ids should not be discoverable,
> > >
> > > I belive "predictable" is the language used by the IETF draft.
> > >
> > > > so there are several aspects:
> > > >
> > > > I see fragmentation id generation still as security critical:
> > > > When Eric patched the frag id generator in 04ca6973f7c1a0d ("ip: make IP
> > > > identifiers less predictable") I could patch my kernels and use the
> > > > patch regardless of the machine being virtualized or not. It was not
> > > > dependent on the hypervisor.
> > >
> > > And now it's even easier - just patch the hypervisor, and all VMs
> > > automatically benefit.
> >
> > Sometimes the hypervisor is not under my control. You would need to
> > patch both kernels in your case - non gso frames would still get the
> > fragmentation id generated in the host kernel.
>
> Confused. You would have to patch both kernels *in your case*.
> If it's all done by host, then it's in a single place, on host.
host is the hypervisor?
Anyway, we would have to patch both kernels now anyway. :)
We still have a working ipv6_fragment routine in the virtualized kernel
which can embed fragmentation extension headers in frames, thus
generating the fragmentation id in the virtualized kernel.
> > > > I think that is the same reasoning why we
> > > > don't support TOE.
> > > > If we use one generator in the hypervisor in an openstack alike setting,
> > > > the host deals with quite a lot of overlay networks. A lot of default
> > > > configurations use the same addresses internally, so on the hypervisor
> > > > the frag id generators would interfere by design.
> > > > I could come up with an attack scenario for DNS servers (again :) ):
> > > >
> > > > You are sitting next to a DNS server on the same hypervisor and can send
> > > > packets without source validation (because that is handled later on in
> > > > case of openvswitch when the packet is put into the corresponding
> > > > overlay network). You emit a gso packet with the same source and
> > > > destination addresses as the DNS server would do and would get an
> > > > fragmentation id which is linearly (+ time delta) incremented depending
> > > > on the source and destination address. With such a leak you could start
> > > > trying attack and spoof DNS responses (fragmentation attacks etc.).
> > > > See also details on such kind of attacks in the description of commit
> > > > 04ca6973f7c1a0d.
> > > >
> > > > AFAIK IETF tried with IPv6 to push fragmentation id generation to the
> > > > end hosts, that's also the reason for the introduction of atomic
> > > > fragments (which are now being rolled back ;) ).
> > > >
> > > > Still it is better to generate a frag id on the hypervisor than just
> > > > sending a 0, so I am ok with this change, albeit not happy.
> > > >
> > > > Thanks,
> > > > Hannes
> > > >
> > >
> > > OK so to summarize, identifiers are only re-randomized once per jiffy,
> > > so you worry that within this window, an external observer can discover
> > > past fragment ID values and so predict the future ones.
> > > All that's required is that two paths go through the same box performing
> > > fragmentation.
> > >
> > > Is that a fair summary?
> > >
> > > If yes, we can make this a bit harder by mixing in some
> > > data per input and/or output devices.
> > >
> > > For example, just to give you the idea:
> > >
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index 683d493..4faa7ef 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -3625,6 +3625,7 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
> > > trace_netif_receive_skb(skb);
> > >
> > > orig_dev = skb->dev;
> > > + skb_shinfo(skb)->ip6_frag_id = skb->dev->ifindex;
> > >
> > > skb_reset_network_header(skb);
> > > if (!skb_transport_header_was_set(skb))
> > > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> > > index ce69a12..819a821 100644
> > > --- a/net/ipv6/ip6_output.c
> > > +++ b/net/ipv6/ip6_output.c
> > > @@ -1092,7 +1092,8 @@ static inline int ip6_ufo_append_data(struct sock *sk,
> > > sizeof(struct frag_hdr)) & ~7;
> > > skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
> > > ipv6_select_ident(&fhdr, rt);
> > > - skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
> > > + skb_shinfo(skb)->ip6_frag_id = jhash_1word(skb_shinfo(skb)->ip6_frag_id,
> > > + fhdr.identification);
> > >
> > > append:
> > > return skb_append_datato_frags(sk, skb, getfrag, from,
> > >
> >
> > I thought about mixing in the incoming interface identifier into the
> > frag id generation, but that could hurt us badly as soon as a VM has
> > more than one interface to the outside world and uses e.g. ECMP.
>
> I don't understand. Fragmentation is done after routing,
> isn't it? So all fragments always go out on the same device.
It is the other way around:
(Source, Dest) is the key to lookup the next fragmentation id. We send
two fragments and use (Source, Dest, ifindex) as key, then the first
packet leaves the host on ifindex 1 with fragid x (because it was a big
gso packet it got segments), second packet leaves host on ifindex 2 with
same Source and Dest and results in fragid y. Ideally both those packets
should use the same bucket to improve uniqueness. Without ifindex we
would have y = x+<number segments>, otherwise it would be (I guess)
random.
> > We need
> > to make sure that those frag ids are unique and the kernel needs to be
> > better than just using a random number generator.
> >
> > Bye,
> > Hannes
>
> 32 bit numbers can't be unique. They just shouldn't be discoverable
> by an off-path observer.
No, they can't. But they should be reasonable unique and, as you said,
not discoverable.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Vlad Yasevich @ 2015-01-28 14:16 UTC (permalink / raw)
To: Hannes Frederic Sowa, Michael S. Tsirkin
Cc: netdev, Vladislav Yasevich, Ben Hutchings, edumazet,
virtualization
In-Reply-To: <1422441242.4678.32.camel@stressinduktion.org>
On 01/28/2015 05:34 AM, Hannes Frederic Sowa wrote:
> Hi,
>
> On Mi, 2015-01-28 at 11:46 +0200, Michael S. Tsirkin wrote:
>> On Wed, Jan 28, 2015 at 09:25:08AM +0100, Hannes Frederic Sowa wrote:
>>> Hello,
>>>
>>> On Di, 2015-01-27 at 18:08 +0200, Michael S. Tsirkin wrote:
>>>> On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
>>>>> On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
>>>>>> On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
>>>>>>> On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
>>>>>>>> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
>>>>>>>>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
>>>>>>>>>> If the IPv6 fragment id has not been set and we perform
>>>>>>>>>> fragmentation due to UFO, select a new fragment id.
>>>>>>>>>> When we store the fragment id into skb_shinfo, set the bit
>>>>>>>>>> in the skb so we can re-use the selected id.
>>>>>>>>>> This preserves the behavior of UFO packets generated on the
>>>>>>>>>> host and solves the issue of id generation for packet sockets
>>>>>>>>>> and tap/macvtap devices.
>>>>>>>>>>
>>>>>>>>>> This patch moves ipv6_select_ident() back in to the header file.
>>>>>>>>>> It also provides the helper function that sets skb_shinfo() frag
>>>>>>>>>> id and sets the bit.
>>>>>>>>>>
>>>>>>>>>> It also makes sure that we select the fragment id when doing
>>>>>>>>>> just gso validation, since it's possible for the packet to
>>>>>>>>>> come from an untrusted source (VM) and be forwarded through
>>>>>>>>>> a UFO enabled device which will expect the fragment id.
>>>>>>>>>>
>>>>>>>>>> CC: Eric Dumazet <edumazet@google.com>
>>>>>>>>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>>>>>>>>>> ---
>>>>>>>>>> include/linux/skbuff.h | 3 ++-
>>>>>>>>>> include/net/ipv6.h | 2 ++
>>>>>>>>>> net/ipv6/ip6_output.c | 4 ++--
>>>>>>>>>> net/ipv6/output_core.c | 9 ++++++++-
>>>>>>>>>> net/ipv6/udp_offload.c | 10 +++++++++-
>>>>>>>>>> 5 files changed, 23 insertions(+), 5 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>>>>>>>>> index 85ab7d7..3ad5203 100644
>>>>>>>>>> --- a/include/linux/skbuff.h
>>>>>>>>>> +++ b/include/linux/skbuff.h
>>>>>>>>>> @@ -605,7 +605,8 @@ struct sk_buff {
>>>>>>>>>> __u8 ipvs_property:1;
>>>>>>>>>> __u8 inner_protocol_type:1;
>>>>>>>>>> __u8 remcsum_offload:1;
>>>>>>>>>> - /* 3 or 5 bit hole */
>>>>>>>>>> + __u8 ufo_fragid_set:1;
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> Doesn't the flag belong in struct skb_shared_info, rather than struct
>>>>>>>>> sk_buff? Otherwise this looks fine.
>>>>>>>>>
>>>>>>>>> Ben.
>>>>>>>>
>>>>>>>> Hmm we seem to be out of tx flags.
>>>>>>>> Maybe ip6_frag_id == 0 should mean "not set".
>>>>>>>
>>>>>>> Maybe that is the best idea. Definitely the ufo_fragid_set bit should
>>>>>>> move into the skb_shared_info area.
>>>>>>
>>>>>> That's what I originally wanted to do, but had to move and grow txflags thus
>>>>>> skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
>>>>>>
>>>>>> I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
>>>>>> from the protocol perspective and could actually be generated by the id generator
>>>>>> functions. This may cause us to call the id generation multiple times.
>>>>>
>>>>> Are there plans in the long run to let virtio_net transmit auxiliary
>>>>> data to the other end so we can clean all of this this up one day?
>>>>>
>>>>> I don't like the whole situation: looking into the virtio_net headers
>>>>> just adding a field for ipv6 fragmentation ids to those small structs
>>>>> seems bloated, not doing it feels incorrect. :/
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Bye,
>>>>> Hannes
>>>>
>>>> I'm not sure - what will be achieved by generating the IDs guest side as
>>>> opposed to host side? It's certainly harder to get hold of entropy
>>>> guest-side.
>>>
>>> It is not only about entropy but about uniqueness. Also fragmentation
>>> ids should not be discoverable,
>>
>> I belive "predictable" is the language used by the IETF draft.
>>
>>> so there are several aspects:
>>>
>>> I see fragmentation id generation still as security critical:
>>> When Eric patched the frag id generator in 04ca6973f7c1a0d ("ip: make IP
>>> identifiers less predictable") I could patch my kernels and use the
>>> patch regardless of the machine being virtualized or not. It was not
>>> dependent on the hypervisor.
>>
>> And now it's even easier - just patch the hypervisor, and all VMs
>> automatically benefit.
>
> Sometimes the hypervisor is not under my control. You would need to
> patch both kernels in your case - non gso frames would still get the
> fragmentation id generated in the host kernel.
Why would non-gso frames need a frag id? We are talking only UDP IPv6
here, so there is no frag id generation if the packet does't need to
be fragmented.
>
>>> I think that is the same reasoning why we
>>> don't support TOE.
>>> If we use one generator in the hypervisor in an openstack alike setting,
>>> the host deals with quite a lot of overlay networks. A lot of default
>>> configurations use the same addresses internally, so on the hypervisor
>>> the frag id generators would interfere by design.
>>> I could come up with an attack scenario for DNS servers (again :) ):
>>>
>>> You are sitting next to a DNS server on the same hypervisor and can send
>>> packets without source validation (because that is handled later on in
>>> case of openvswitch when the packet is put into the corresponding
>>> overlay network). You emit a gso packet with the same source and
>>> destination addresses as the DNS server would do and would get an
>>> fragmentation id which is linearly (+ time delta) incremented depending
>>> on the source and destination address. With such a leak you could start
>>> trying attack and spoof DNS responses (fragmentation attacks etc.).
>>> See also details on such kind of attacks in the description of commit
>>> 04ca6973f7c1a0d.
>>>
>>> AFAIK IETF tried with IPv6 to push fragmentation id generation to the
>>> end hosts, that's also the reason for the introduction of atomic
>>> fragments (which are now being rolled back ;) ).
>>>
>>> Still it is better to generate a frag id on the hypervisor than just
>>> sending a 0, so I am ok with this change, albeit not happy.
>>>
>>> Thanks,
>>> Hannes
>>>
>>
>> OK so to summarize, identifiers are only re-randomized once per jiffy,
>> so you worry that within this window, an external observer can discover
>> past fragment ID values and so predict the future ones.
>> All that's required is that two paths go through the same box performing
>> fragmentation.
>>
>> Is that a fair summary?
>>
>> If yes, we can make this a bit harder by mixing in some
>> data per input and/or output devices.
>>
>> For example, just to give you the idea:
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 683d493..4faa7ef 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -3625,6 +3625,7 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
>> trace_netif_receive_skb(skb);
>>
>> orig_dev = skb->dev;
>> + skb_shinfo(skb)->ip6_frag_id = skb->dev->ifindex;
>>
>> skb_reset_network_header(skb);
>> if (!skb_transport_header_was_set(skb))
>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>> index ce69a12..819a821 100644
>> --- a/net/ipv6/ip6_output.c
>> +++ b/net/ipv6/ip6_output.c
>> @@ -1092,7 +1092,8 @@ static inline int ip6_ufo_append_data(struct sock *sk,
>> sizeof(struct frag_hdr)) & ~7;
>> skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
>> ipv6_select_ident(&fhdr, rt);
>> - skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
>> + skb_shinfo(skb)->ip6_frag_id = jhash_1word(skb_shinfo(skb)->ip6_frag_id,
>> + fhdr.identification);
>>
>> append:
>> return skb_append_datato_frags(sk, skb, getfrag, from,
>>
>
> I thought about mixing in the incoming interface identifier into the
> frag id generation, but that could hurt us badly as soon as a VM has
> more than one interface to the outside world and uses e.g. ECMP. We need
> to make sure that those frag ids are unique and the kernel needs to be
> better than just using a random number generator.
>
So the goal behind this series of patches is to restore VM functionality to
pre-916e4cf46d0204 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data").
-vlad
> Bye,
> Hannes
>
>
^ permalink raw reply
* [PATCH 4/4] net: am2150: fix nmclan_cs.c shared interrupt handling
From: Arnd Bergmann @ 2015-01-28 14:15 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, linux-pcmcia, jeffrey.t.kirsher, kas, davem,
linux-arm-kernel
In-Reply-To: <1422454504-439085-1-git-send-email-arnd@arndb.de>
A recent patch tried to work around a valid warning for the use of a
deprecated interface by blindly changing from the old
pcmcia_request_exclusive_irq() interface to pcmcia_request_irq().
This driver has an interrupt handler that is not currently aware
of shared interrupts, but can be easily converted to be.
At the moment, the driver reads the interrupt status register
repeatedly until it contains only zeroes in the interesting bits,
and handles each bit individually.
This patch adds the missing part of returning IRQ_NONE in case none
of the bits are set to start with, so we can move on to the next
interrupt source.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 5f5316fcd08ef7 ("am2150: Update nmclan_cs.c to use update PCMCIA API")
---
drivers/net/ethernet/amd/nmclan_cs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/amd/nmclan_cs.c b/drivers/net/ethernet/amd/nmclan_cs.c
index 5b22764ba88d..27245efe9f50 100644
--- a/drivers/net/ethernet/amd/nmclan_cs.c
+++ b/drivers/net/ethernet/amd/nmclan_cs.c
@@ -952,6 +952,8 @@ static irqreturn_t mace_interrupt(int irq, void *dev_id)
do {
/* WARNING: MACE_IR is a READ/CLEAR port! */
status = inb(ioaddr + AM2150_MACE_BASE + MACE_IR);
+ if (!(status & ~MACE_IMR_DEFAULT) && IntrCnt == MACE_MAX_IR_ITERATIONS)
+ return IRQ_NONE;
pr_debug("mace_interrupt: irq 0x%X status 0x%X.\n", irq, status);
--
2.1.0.rc2
^ permalink raw reply related
* [PATCH 3/4] net: lance,ni64: don't build for ARM
From: Arnd Bergmann @ 2015-01-28 14:15 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, linux-pcmcia, jeffrey.t.kirsher, kas, davem,
linux-arm-kernel
In-Reply-To: <1422454504-439085-1-git-send-email-arnd@arndb.de>
The ni65 and lance ethernet drivers manually program the ISA DMA
controller that is only available on x86 PCs and a few compatible
systems. Trying to build it on ARM results in this error:
ni65.c: In function 'ni65_probe1':
ni65.c:496:62: error: 'DMA1_STAT_REG' undeclared (first use in this function)
((inb(DMA1_STAT_REG) >> 4) & 0x0f)
^
ni65.c:496:62: note: each undeclared identifier is reported only once for each function it appears in
ni65.c:497:63: error: 'DMA2_STAT_REG' undeclared (first use in this function)
| (inb(DMA2_STAT_REG) & 0xf0);
The DMA1_STAT_REG and DMA2_STAT_REG registers are only defined for
alpha, mips, parisc, powerpc and x86, although it is not clear
which subarchitectures actually have them at the correct location.
This patch for now just disables it for ARM, to avoid randconfig
build errors. We could also decide to limit it to the set of
architectures on which it does compile, but that might look more
deliberate than guessing based on where the drivers build.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/amd/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 5d3b5202327c..c638c85f3954 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -45,7 +45,7 @@ config AMD8111_ETH
config LANCE
tristate "AMD LANCE and PCnet (AT1500 and NE2100) support"
- depends on ISA && ISA_DMA_API
+ depends on ISA && ISA_DMA_API && !ARM
---help---
If you have a network (Ethernet) card of this type, say Y and read
the Ethernet-HOWTO, available from
@@ -142,7 +142,7 @@ config PCMCIA_NMCLAN
config NI65
tristate "NI6510 support"
- depends on ISA && ISA_DMA_API
+ depends on ISA && ISA_DMA_API && !ARM
---help---
If you have a network (Ethernet) card of this type, say Y and read
the Ethernet-HOWTO, available from
--
2.1.0.rc2
^ permalink raw reply related
* [PATCH 2/4] net: wan: add missing virt_to_bus dependencies
From: Arnd Bergmann @ 2015-01-28 14:15 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, linux-pcmcia, jeffrey.t.kirsher, kas, davem,
linux-arm-kernel
In-Reply-To: <1422454504-439085-1-git-send-email-arnd@arndb.de>
The cosa driver is rather outdated and does not get built on most
platforms because it requires the ISA_DMA_API symbol. However
there are some ARM platforms that have ISA_DMA_API but no virt_to_bus,
and they get this build error when enabling the ltpc driver.
drivers/net/wan/cosa.c: In function 'tx_interrupt':
drivers/net/wan/cosa.c:1768:3: error: implicit declaration of function 'virt_to_bus'
unsigned long addr = virt_to_bus(cosa->txbuf);
^
The same problem exists for the Hostess SV-11 and Sealevel Systems 4021
drivers.
This adds another dependency in Kconfig to avoid that configuration.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wan/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 94e234975c61..a2fdd15f285a 100644
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@ -25,7 +25,7 @@ if WAN
# There is no way to detect a comtrol sv11 - force it modular for now.
config HOSTESS_SV11
tristate "Comtrol Hostess SV-11 support"
- depends on ISA && m && ISA_DMA_API && INET && HDLC
+ depends on ISA && m && ISA_DMA_API && INET && HDLC && VIRT_TO_BUS
help
Driver for Comtrol Hostess SV-11 network card which
operates on low speed synchronous serial links at up to
@@ -37,7 +37,7 @@ config HOSTESS_SV11
# The COSA/SRP driver has not been tested as non-modular yet.
config COSA
tristate "COSA/SRP sync serial boards support"
- depends on ISA && m && ISA_DMA_API && HDLC
+ depends on ISA && m && ISA_DMA_API && HDLC && VIRT_TO_BUS
---help---
Driver for COSA and SRP synchronous serial boards.
@@ -87,7 +87,7 @@ config LANMEDIA
# There is no way to detect a Sealevel board. Force it modular
config SEALEVEL_4021
tristate "Sealevel Systems 4021 support"
- depends on ISA && m && ISA_DMA_API && INET && HDLC
+ depends on ISA && m && ISA_DMA_API && INET && HDLC && VIRT_TO_BUS
help
This is a driver for the Sealevel Systems ACB 56 serial I/O adapter.
--
2.1.0.rc2
^ permalink raw reply related
* [PATCH 1/4] net: cs89x0: always build platform code if !HAS_IOPORT_MAP
From: Arnd Bergmann @ 2015-01-28 14:15 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, linux-pcmcia, jeffrey.t.kirsher, kas, davem,
linux-arm-kernel
In-Reply-To: <1422454504-439085-1-git-send-email-arnd@arndb.de>
The cs89x0 driver can either be built as an ISA driver or a platform
driver, the choice is controlled by the CS89x0_PLATFORM Kconfig
symbol. Building the ISA driver on a system that does not have
a way to map I/O ports fails with this error:
drivers/built-in.o: In function `cs89x0_ioport_probe.constprop.1':
:(.init.text+0x4794): undefined reference to `ioport_map'
:(.init.text+0x4830): undefined reference to `ioport_unmap'
This changes the Kconfig logic to take that option away and
always force building the platform variant of this driver if
CONFIG_HAS_IOPORT_MAP is not set. This is the only correct
choice in this case, and it avoids the build error.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/cirrus/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cirrus/Kconfig b/drivers/net/ethernet/cirrus/Kconfig
index 7403dff8f14a..905ac5f5d9a6 100644
--- a/drivers/net/ethernet/cirrus/Kconfig
+++ b/drivers/net/ethernet/cirrus/Kconfig
@@ -32,7 +32,8 @@ config CS89x0
will be called cs89x0.
config CS89x0_PLATFORM
- bool "CS89x0 platform driver support"
+ bool "CS89x0 platform driver support" if HAS_IOPORT_MAP
+ default !HAS_IOPORT_MAP
depends on CS89x0
help
Say Y to compile the cs89x0 driver as a platform driver. This
--
2.1.0.rc2
^ permalink raw reply related
* [PATCH 0/4] net: driver fixes from arm randconfig builds
From: Arnd Bergmann @ 2015-01-28 14:15 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, linux-pcmcia, jeffrey.t.kirsher, kas, davem,
linux-arm-kernel
These four patches are fallout from test builds on ARM. I have a
few more of them in my backlog but have not yet confirmed them
to still be valid.
The first three patches are about incomplete dependencies on
old drivers. One could backport them to the beginning of time
in theory, but there is little value since nobody would run into
these problems.
The final patch is one I had submitted before together with the
respective pcmcia patch but forgot to follow up on that. It's
still a valid but relatively theoretical bug, because the previous
behavior of the driver was just as broken as what we have in
mainline.
Please apply,
Arnd
Arnd Bergmann (4):
net: cs89x0: always build platform code if !HAS_IOPORT_MAP
net: wan: add missing virt_to_bus dependencies
net: lance,ni64: don't build for ARM
net: am2150: fix nmclan_cs.c shared interrupt handling
drivers/net/ethernet/amd/Kconfig | 4 ++--
drivers/net/ethernet/amd/nmclan_cs.c | 2 ++
drivers/net/ethernet/cirrus/Kconfig | 3 ++-
drivers/net/wan/Kconfig | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
--
2.1.0.rc2
^ permalink raw reply
* pull-request: can-next 2015-28-01
From: Marc Kleine-Budde @ 2015-01-28 13:58 UTC (permalink / raw)
To: netdev; +Cc: David Miller, kernel@pengutronix.de, linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]
Hello David,
this is a pull request of 12 patches for net-next/master.
There are 3 patches by Ahmed S. Darwish, which update the kvaser_usb
driver and add support for the USBcan-II based adapters. Stéphane
Grosjean contributes 7 patches for the peak_usb driver, which add
support for the CANFD USB adapters. I contribute 2 patches which clean
up the peak_usb driver structure a bit.
Marc
---
The following changes since commit ff660f75be36e6db75d45dc742a4a468c5a9c20d:
Merge branch 'stmmac-pci' (2015-01-27 21:08:13 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-3.20-20150128
for you to fetch changes up to 0a25e1f4f18566b750ebd3ae995af64e23111e63:
can: peak_usb: add support for PEAK new CANFD USB adapters (2015-01-28 14:47:06 +0100)
----------------------------------------------------------------
linux-can-next-for-3.20-20150128
----------------------------------------------------------------
Ahmed S. Darwish (3):
can: kvaser_usb: Update interface state before exiting on OOM
can: kvaser_usb: Consolidate and unify state change handling
can: kvaser_usb: Add support for the USBcan-II family
Marc Kleine-Budde (2):
can: peak_usb: use ARRAY_SIZE instead of NULL termination for peak_usb_adapters_list
can: peak_usb: constify struct peak_usb_adapter
Stephane Grosjean (7):
can: peak_usb: export ctrlmode_supported to adapter specific definition
can: peak_usb: add adapter BEC callback definition
can: peak_usb: upgrade core to data bittiming specs
can: peak_usb: upgrade core to new struct canfd_frame
can: peak_usb: export pcan_usb_pro functions
can: peak_usb: add peak_usb_netif_rx() new function
can: peak_usb: add support for PEAK new CANFD USB adapters
drivers/net/can/usb/Kconfig | 22 +-
drivers/net/can/usb/kvaser_usb.c | 722 ++++++++++++-----
drivers/net/can/usb/peak_usb/Makefile | 2 +-
drivers/net/can/usb/peak_usb/pcan_ucan.h | 222 ++++++
drivers/net/can/usb/peak_usb/pcan_usb.c | 3 +-
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 83 +-
drivers/net/can/usb/peak_usb/pcan_usb_core.h | 26 +-
drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 1095 ++++++++++++++++++++++++++
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 19 +-
drivers/net/can/usb/peak_usb/pcan_usb_pro.h | 13 +
10 files changed, 1981 insertions(+), 226 deletions(-)
create mode 100644 drivers/net/can/usb/peak_usb/pcan_ucan.h
create mode 100644 drivers/net/can/usb/peak_usb/pcan_usb_fd.c
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Michael S. Tsirkin @ 2015-01-28 13:43 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: netdev, Vladislav Yasevich, virtualization, edumazet,
Ben Hutchings
In-Reply-To: <1422441242.4678.32.camel@stressinduktion.org>
On Wed, Jan 28, 2015 at 11:34:02AM +0100, Hannes Frederic Sowa wrote:
> Hi,
>
> On Mi, 2015-01-28 at 11:46 +0200, Michael S. Tsirkin wrote:
> > On Wed, Jan 28, 2015 at 09:25:08AM +0100, Hannes Frederic Sowa wrote:
> > > Hello,
> > >
> > > On Di, 2015-01-27 at 18:08 +0200, Michael S. Tsirkin wrote:
> > > > On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
> > > > > On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
> > > > > > On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
> > > > > > > On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> > > > > > >> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> > > > > > >>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> > > > > > >>>> If the IPv6 fragment id has not been set and we perform
> > > > > > >>>> fragmentation due to UFO, select a new fragment id.
> > > > > > >>>> When we store the fragment id into skb_shinfo, set the bit
> > > > > > >>>> in the skb so we can re-use the selected id.
> > > > > > >>>> This preserves the behavior of UFO packets generated on the
> > > > > > >>>> host and solves the issue of id generation for packet sockets
> > > > > > >>>> and tap/macvtap devices.
> > > > > > >>>>
> > > > > > >>>> This patch moves ipv6_select_ident() back in to the header file.
> > > > > > >>>> It also provides the helper function that sets skb_shinfo() frag
> > > > > > >>>> id and sets the bit.
> > > > > > >>>>
> > > > > > >>>> It also makes sure that we select the fragment id when doing
> > > > > > >>>> just gso validation, since it's possible for the packet to
> > > > > > >>>> come from an untrusted source (VM) and be forwarded through
> > > > > > >>>> a UFO enabled device which will expect the fragment id.
> > > > > > >>>>
> > > > > > >>>> CC: Eric Dumazet <edumazet@google.com>
> > > > > > >>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > > > > >>>> ---
> > > > > > >>>> include/linux/skbuff.h | 3 ++-
> > > > > > >>>> include/net/ipv6.h | 2 ++
> > > > > > >>>> net/ipv6/ip6_output.c | 4 ++--
> > > > > > >>>> net/ipv6/output_core.c | 9 ++++++++-
> > > > > > >>>> net/ipv6/udp_offload.c | 10 +++++++++-
> > > > > > >>>> 5 files changed, 23 insertions(+), 5 deletions(-)
> > > > > > >>>>
> > > > > > >>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > > >>>> index 85ab7d7..3ad5203 100644
> > > > > > >>>> --- a/include/linux/skbuff.h
> > > > > > >>>> +++ b/include/linux/skbuff.h
> > > > > > >>>> @@ -605,7 +605,8 @@ struct sk_buff {
> > > > > > >>>> __u8 ipvs_property:1;
> > > > > > >>>> __u8 inner_protocol_type:1;
> > > > > > >>>> __u8 remcsum_offload:1;
> > > > > > >>>> - /* 3 or 5 bit hole */
> > > > > > >>>> + __u8 ufo_fragid_set:1;
> > > > > > >>> [...]
> > > > > > >>>
> > > > > > >>> Doesn't the flag belong in struct skb_shared_info, rather than struct
> > > > > > >>> sk_buff? Otherwise this looks fine.
> > > > > > >>>
> > > > > > >>> Ben.
> > > > > > >>
> > > > > > >> Hmm we seem to be out of tx flags.
> > > > > > >> Maybe ip6_frag_id == 0 should mean "not set".
> > > > > > >
> > > > > > > Maybe that is the best idea. Definitely the ufo_fragid_set bit should
> > > > > > > move into the skb_shared_info area.
> > > > > >
> > > > > > That's what I originally wanted to do, but had to move and grow txflags thus
> > > > > > skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
> > > > > >
> > > > > > I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
> > > > > > from the protocol perspective and could actually be generated by the id generator
> > > > > > functions. This may cause us to call the id generation multiple times.
> > > > >
> > > > > Are there plans in the long run to let virtio_net transmit auxiliary
> > > > > data to the other end so we can clean all of this this up one day?
> > > > >
> > > > > I don't like the whole situation: looking into the virtio_net headers
> > > > > just adding a field for ipv6 fragmentation ids to those small structs
> > > > > seems bloated, not doing it feels incorrect. :/
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Bye,
> > > > > Hannes
> > > >
> > > > I'm not sure - what will be achieved by generating the IDs guest side as
> > > > opposed to host side? It's certainly harder to get hold of entropy
> > > > guest-side.
> > >
> > > It is not only about entropy but about uniqueness. Also fragmentation
> > > ids should not be discoverable,
> >
> > I belive "predictable" is the language used by the IETF draft.
> >
> > > so there are several aspects:
> > >
> > > I see fragmentation id generation still as security critical:
> > > When Eric patched the frag id generator in 04ca6973f7c1a0d ("ip: make IP
> > > identifiers less predictable") I could patch my kernels and use the
> > > patch regardless of the machine being virtualized or not. It was not
> > > dependent on the hypervisor.
> >
> > And now it's even easier - just patch the hypervisor, and all VMs
> > automatically benefit.
>
> Sometimes the hypervisor is not under my control. You would need to
> patch both kernels in your case - non gso frames would still get the
> fragmentation id generated in the host kernel.
Confused. You would have to patch both kernels *in your case*.
If it's all done by host, then it's in a single place, on host.
> > > I think that is the same reasoning why we
> > > don't support TOE.
> > > If we use one generator in the hypervisor in an openstack alike setting,
> > > the host deals with quite a lot of overlay networks. A lot of default
> > > configurations use the same addresses internally, so on the hypervisor
> > > the frag id generators would interfere by design.
> > > I could come up with an attack scenario for DNS servers (again :) ):
> > >
> > > You are sitting next to a DNS server on the same hypervisor and can send
> > > packets without source validation (because that is handled later on in
> > > case of openvswitch when the packet is put into the corresponding
> > > overlay network). You emit a gso packet with the same source and
> > > destination addresses as the DNS server would do and would get an
> > > fragmentation id which is linearly (+ time delta) incremented depending
> > > on the source and destination address. With such a leak you could start
> > > trying attack and spoof DNS responses (fragmentation attacks etc.).
> > > See also details on such kind of attacks in the description of commit
> > > 04ca6973f7c1a0d.
> > >
> > > AFAIK IETF tried with IPv6 to push fragmentation id generation to the
> > > end hosts, that's also the reason for the introduction of atomic
> > > fragments (which are now being rolled back ;) ).
> > >
> > > Still it is better to generate a frag id on the hypervisor than just
> > > sending a 0, so I am ok with this change, albeit not happy.
> > >
> > > Thanks,
> > > Hannes
> > >
> >
> > OK so to summarize, identifiers are only re-randomized once per jiffy,
> > so you worry that within this window, an external observer can discover
> > past fragment ID values and so predict the future ones.
> > All that's required is that two paths go through the same box performing
> > fragmentation.
> >
> > Is that a fair summary?
> >
> > If yes, we can make this a bit harder by mixing in some
> > data per input and/or output devices.
> >
> > For example, just to give you the idea:
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 683d493..4faa7ef 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -3625,6 +3625,7 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
> > trace_netif_receive_skb(skb);
> >
> > orig_dev = skb->dev;
> > + skb_shinfo(skb)->ip6_frag_id = skb->dev->ifindex;
> >
> > skb_reset_network_header(skb);
> > if (!skb_transport_header_was_set(skb))
> > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> > index ce69a12..819a821 100644
> > --- a/net/ipv6/ip6_output.c
> > +++ b/net/ipv6/ip6_output.c
> > @@ -1092,7 +1092,8 @@ static inline int ip6_ufo_append_data(struct sock *sk,
> > sizeof(struct frag_hdr)) & ~7;
> > skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
> > ipv6_select_ident(&fhdr, rt);
> > - skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
> > + skb_shinfo(skb)->ip6_frag_id = jhash_1word(skb_shinfo(skb)->ip6_frag_id,
> > + fhdr.identification);
> >
> > append:
> > return skb_append_datato_frags(sk, skb, getfrag, from,
> >
>
> I thought about mixing in the incoming interface identifier into the
> frag id generation, but that could hurt us badly as soon as a VM has
> more than one interface to the outside world and uses e.g. ECMP.
I don't understand. Fragmentation is done after routing,
isn't it? So all fragments always go out on the same device.
> We need
> to make sure that those frag ids are unique and the kernel needs to be
> better than just using a random number generator.
>
> Bye,
> Hannes
32 bit numbers can't be unique. They just shouldn't be discoverable
by an off-path observer.
--
MST
^ permalink raw reply
* [PATCH 0/2] Two printf fixes
From: Rasmus Villemoes @ 2015-01-28 13:25 UTC (permalink / raw)
To: Andy Shevchenko, Andrew Morton, Trond Myklebust, J. Bruce Fields,
David S. Miller
Cc: Rasmus Villemoes, linux-kernel, linux-nfs, netdev
Both %pE and %ph are unusable in kasprintf(), since the occurrence of
either will trigger an oops during the first vsnprintf call where
kasprintf tries to find the correct size to allocate. These oopses
could be papered over with somewhat smaller patches than these, but
then the return value from vsnprintf would still not reflect the
actual size needed. For %pE, this requires a change of semantics of
string_escape_mem and hence an annoyingly large diffstat.
Whether this is 3.20, 3.21 and/or -stable material (or /dev/null
material, for that matter ;-)) I'll leave to others to decide.
Rasmus Villemoes (2):
lib/vsprintf.c: Fix potential NULL deref in hex_string
string_helpers: Change semantics of string_escape_mem
include/linux/string_helpers.h | 10 +--
lib/string_helpers.c | 195 ++++++++++++++++-------------------------
lib/test-string_helpers.c | 37 ++++----
lib/vsprintf.c | 25 ++++--
net/sunrpc/cache.c | 8 +-
5 files changed, 119 insertions(+), 156 deletions(-)
--
2.1.3
^ permalink raw reply
* Re: [PATCH v2] lib/checksum.c: fix carry in csum_tcpudp_nofold
From: Eric Dumazet @ 2015-01-28 13:04 UTC (permalink / raw)
To: Karl Beldan
Cc: Karl Beldan, Al Viro, Arnd Bergmann, Mike Frysinger, netdev,
linux-kernel, stable
In-Reply-To: <1422439091-31413-1-git-send-email-karl.beldan@rivierawaves.com>
On Wed, 2015-01-28 at 10:58 +0100, Karl Beldan wrote:
> The carry from the 64->32bits folding was dropped, e.g with:
> saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1,
> csum_tcpudp_nofold returned 0 instead of 1.
>
> Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
> Cc: Al Viro <viro@ZenIV.linux.org.uk>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Mike Frysinger <vapier@gentoo.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: stable@vger.kernel.org
> ---
> lib/checksum.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
Signed-off-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Hannes Frederic Sowa @ 2015-01-28 10:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, Vladislav Yasevich, virtualization, edumazet,
Ben Hutchings
In-Reply-To: <1422441242.4678.32.camel@stressinduktion.org>
On Mi, 2015-01-28 at 11:34 +0100, Hannes Frederic Sowa wrote:
>
> > And now it's even easier - just patch the hypervisor, and all VMs
> > automatically benefit.
>
> Sometimes the hypervisor is not under my control. You would need to
> patch both kernels in your case - non gso frames would still get the
> fragmentation id generated in the host kernel.
Actually this now became my biggest concern. :/
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Hannes Frederic Sowa @ 2015-01-28 10:34 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, Vladislav Yasevich, virtualization, edumazet,
Ben Hutchings
In-Reply-To: <20150128094658.GB16775@redhat.com>
Hi,
On Mi, 2015-01-28 at 11:46 +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 28, 2015 at 09:25:08AM +0100, Hannes Frederic Sowa wrote:
> > Hello,
> >
> > On Di, 2015-01-27 at 18:08 +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
> > > > On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
> > > > > On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
> > > > > > On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> > > > > >> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> > > > > >>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> > > > > >>>> If the IPv6 fragment id has not been set and we perform
> > > > > >>>> fragmentation due to UFO, select a new fragment id.
> > > > > >>>> When we store the fragment id into skb_shinfo, set the bit
> > > > > >>>> in the skb so we can re-use the selected id.
> > > > > >>>> This preserves the behavior of UFO packets generated on the
> > > > > >>>> host and solves the issue of id generation for packet sockets
> > > > > >>>> and tap/macvtap devices.
> > > > > >>>>
> > > > > >>>> This patch moves ipv6_select_ident() back in to the header file.
> > > > > >>>> It also provides the helper function that sets skb_shinfo() frag
> > > > > >>>> id and sets the bit.
> > > > > >>>>
> > > > > >>>> It also makes sure that we select the fragment id when doing
> > > > > >>>> just gso validation, since it's possible for the packet to
> > > > > >>>> come from an untrusted source (VM) and be forwarded through
> > > > > >>>> a UFO enabled device which will expect the fragment id.
> > > > > >>>>
> > > > > >>>> CC: Eric Dumazet <edumazet@google.com>
> > > > > >>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > > > >>>> ---
> > > > > >>>> include/linux/skbuff.h | 3 ++-
> > > > > >>>> include/net/ipv6.h | 2 ++
> > > > > >>>> net/ipv6/ip6_output.c | 4 ++--
> > > > > >>>> net/ipv6/output_core.c | 9 ++++++++-
> > > > > >>>> net/ipv6/udp_offload.c | 10 +++++++++-
> > > > > >>>> 5 files changed, 23 insertions(+), 5 deletions(-)
> > > > > >>>>
> > > > > >>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > >>>> index 85ab7d7..3ad5203 100644
> > > > > >>>> --- a/include/linux/skbuff.h
> > > > > >>>> +++ b/include/linux/skbuff.h
> > > > > >>>> @@ -605,7 +605,8 @@ struct sk_buff {
> > > > > >>>> __u8 ipvs_property:1;
> > > > > >>>> __u8 inner_protocol_type:1;
> > > > > >>>> __u8 remcsum_offload:1;
> > > > > >>>> - /* 3 or 5 bit hole */
> > > > > >>>> + __u8 ufo_fragid_set:1;
> > > > > >>> [...]
> > > > > >>>
> > > > > >>> Doesn't the flag belong in struct skb_shared_info, rather than struct
> > > > > >>> sk_buff? Otherwise this looks fine.
> > > > > >>>
> > > > > >>> Ben.
> > > > > >>
> > > > > >> Hmm we seem to be out of tx flags.
> > > > > >> Maybe ip6_frag_id == 0 should mean "not set".
> > > > > >
> > > > > > Maybe that is the best idea. Definitely the ufo_fragid_set bit should
> > > > > > move into the skb_shared_info area.
> > > > >
> > > > > That's what I originally wanted to do, but had to move and grow txflags thus
> > > > > skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
> > > > >
> > > > > I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
> > > > > from the protocol perspective and could actually be generated by the id generator
> > > > > functions. This may cause us to call the id generation multiple times.
> > > >
> > > > Are there plans in the long run to let virtio_net transmit auxiliary
> > > > data to the other end so we can clean all of this this up one day?
> > > >
> > > > I don't like the whole situation: looking into the virtio_net headers
> > > > just adding a field for ipv6 fragmentation ids to those small structs
> > > > seems bloated, not doing it feels incorrect. :/
> > > >
> > > > Thoughts?
> > > >
> > > > Bye,
> > > > Hannes
> > >
> > > I'm not sure - what will be achieved by generating the IDs guest side as
> > > opposed to host side? It's certainly harder to get hold of entropy
> > > guest-side.
> >
> > It is not only about entropy but about uniqueness. Also fragmentation
> > ids should not be discoverable,
>
> I belive "predictable" is the language used by the IETF draft.
>
> > so there are several aspects:
> >
> > I see fragmentation id generation still as security critical:
> > When Eric patched the frag id generator in 04ca6973f7c1a0d ("ip: make IP
> > identifiers less predictable") I could patch my kernels and use the
> > patch regardless of the machine being virtualized or not. It was not
> > dependent on the hypervisor.
>
> And now it's even easier - just patch the hypervisor, and all VMs
> automatically benefit.
Sometimes the hypervisor is not under my control. You would need to
patch both kernels in your case - non gso frames would still get the
fragmentation id generated in the host kernel.
> > I think that is the same reasoning why we
> > don't support TOE.
> > If we use one generator in the hypervisor in an openstack alike setting,
> > the host deals with quite a lot of overlay networks. A lot of default
> > configurations use the same addresses internally, so on the hypervisor
> > the frag id generators would interfere by design.
> > I could come up with an attack scenario for DNS servers (again :) ):
> >
> > You are sitting next to a DNS server on the same hypervisor and can send
> > packets without source validation (because that is handled later on in
> > case of openvswitch when the packet is put into the corresponding
> > overlay network). You emit a gso packet with the same source and
> > destination addresses as the DNS server would do and would get an
> > fragmentation id which is linearly (+ time delta) incremented depending
> > on the source and destination address. With such a leak you could start
> > trying attack and spoof DNS responses (fragmentation attacks etc.).
> > See also details on such kind of attacks in the description of commit
> > 04ca6973f7c1a0d.
> >
> > AFAIK IETF tried with IPv6 to push fragmentation id generation to the
> > end hosts, that's also the reason for the introduction of atomic
> > fragments (which are now being rolled back ;) ).
> >
> > Still it is better to generate a frag id on the hypervisor than just
> > sending a 0, so I am ok with this change, albeit not happy.
> >
> > Thanks,
> > Hannes
> >
>
> OK so to summarize, identifiers are only re-randomized once per jiffy,
> so you worry that within this window, an external observer can discover
> past fragment ID values and so predict the future ones.
> All that's required is that two paths go through the same box performing
> fragmentation.
>
> Is that a fair summary?
>
> If yes, we can make this a bit harder by mixing in some
> data per input and/or output devices.
>
> For example, just to give you the idea:
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 683d493..4faa7ef 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3625,6 +3625,7 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
> trace_netif_receive_skb(skb);
>
> orig_dev = skb->dev;
> + skb_shinfo(skb)->ip6_frag_id = skb->dev->ifindex;
>
> skb_reset_network_header(skb);
> if (!skb_transport_header_was_set(skb))
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index ce69a12..819a821 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1092,7 +1092,8 @@ static inline int ip6_ufo_append_data(struct sock *sk,
> sizeof(struct frag_hdr)) & ~7;
> skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
> ipv6_select_ident(&fhdr, rt);
> - skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
> + skb_shinfo(skb)->ip6_frag_id = jhash_1word(skb_shinfo(skb)->ip6_frag_id,
> + fhdr.identification);
>
> append:
> return skb_append_datato_frags(sk, skb, getfrag, from,
>
I thought about mixing in the incoming interface identifier into the
frag id generation, but that could hurt us badly as soon as a VM has
more than one interface to the outside world and uses e.g. ECMP. We need
to make sure that those frag ids are unique and the kernel needs to be
better than just using a random number generator.
Bye,
Hannes
^ permalink raw reply
* [PATCH v2] lib/checksum.c: fix carry in csum_tcpudp_nofold
From: Karl Beldan @ 2015-01-28 9:58 UTC (permalink / raw)
Cc: Karl Beldan, Karl Beldan, Al Viro, Eric Dumazet, Arnd Bergmann,
Mike Frysinger, netdev, linux-kernel, stable
The carry from the 64->32bits folding was dropped, e.g with:
saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1,
csum_tcpudp_nofold returned 0 instead of 1.
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
---
lib/checksum.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/checksum.c b/lib/checksum.c
index 129775e..fcf3894 100644
--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,6 +47,15 @@ static inline unsigned short from32to16(unsigned int x)
return x;
}
+static inline u32 from64to32(u64 x)
+{
+ /* add up 32-bit and 32-bit for 32+c bit */
+ x = (x & 0xffffffff) + (x >> 32);
+ /* add up carry.. */
+ x = (x & 0xffffffff) + (x >> 32);
+ return (u32)x;
+}
+
static unsigned int do_csum(const unsigned char *buff, int len)
{
int odd;
@@ -195,8 +204,7 @@ __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
#else
s += (proto + len) << 8;
#endif
- s += (s >> 32);
- return (__force __wsum)s;
+ return (__force __wsum)from64to32(s);
}
EXPORT_SYMBOL(csum_tcpudp_nofold);
#endif
--
2.0.1
^ permalink raw reply related
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Michael S. Tsirkin @ 2015-01-28 9:46 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: netdev, Vladislav Yasevich, virtualization, edumazet,
Ben Hutchings
In-Reply-To: <1422433508.4678.14.camel@stressinduktion.org>
On Wed, Jan 28, 2015 at 09:25:08AM +0100, Hannes Frederic Sowa wrote:
> Hello,
>
> On Di, 2015-01-27 at 18:08 +0200, Michael S. Tsirkin wrote:
> > On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
> > > On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
> > > > On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
> > > > > On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> > > > >> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> > > > >>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> > > > >>>> If the IPv6 fragment id has not been set and we perform
> > > > >>>> fragmentation due to UFO, select a new fragment id.
> > > > >>>> When we store the fragment id into skb_shinfo, set the bit
> > > > >>>> in the skb so we can re-use the selected id.
> > > > >>>> This preserves the behavior of UFO packets generated on the
> > > > >>>> host and solves the issue of id generation for packet sockets
> > > > >>>> and tap/macvtap devices.
> > > > >>>>
> > > > >>>> This patch moves ipv6_select_ident() back in to the header file.
> > > > >>>> It also provides the helper function that sets skb_shinfo() frag
> > > > >>>> id and sets the bit.
> > > > >>>>
> > > > >>>> It also makes sure that we select the fragment id when doing
> > > > >>>> just gso validation, since it's possible for the packet to
> > > > >>>> come from an untrusted source (VM) and be forwarded through
> > > > >>>> a UFO enabled device which will expect the fragment id.
> > > > >>>>
> > > > >>>> CC: Eric Dumazet <edumazet@google.com>
> > > > >>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > > >>>> ---
> > > > >>>> include/linux/skbuff.h | 3 ++-
> > > > >>>> include/net/ipv6.h | 2 ++
> > > > >>>> net/ipv6/ip6_output.c | 4 ++--
> > > > >>>> net/ipv6/output_core.c | 9 ++++++++-
> > > > >>>> net/ipv6/udp_offload.c | 10 +++++++++-
> > > > >>>> 5 files changed, 23 insertions(+), 5 deletions(-)
> > > > >>>>
> > > > >>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > >>>> index 85ab7d7..3ad5203 100644
> > > > >>>> --- a/include/linux/skbuff.h
> > > > >>>> +++ b/include/linux/skbuff.h
> > > > >>>> @@ -605,7 +605,8 @@ struct sk_buff {
> > > > >>>> __u8 ipvs_property:1;
> > > > >>>> __u8 inner_protocol_type:1;
> > > > >>>> __u8 remcsum_offload:1;
> > > > >>>> - /* 3 or 5 bit hole */
> > > > >>>> + __u8 ufo_fragid_set:1;
> > > > >>> [...]
> > > > >>>
> > > > >>> Doesn't the flag belong in struct skb_shared_info, rather than struct
> > > > >>> sk_buff? Otherwise this looks fine.
> > > > >>>
> > > > >>> Ben.
> > > > >>
> > > > >> Hmm we seem to be out of tx flags.
> > > > >> Maybe ip6_frag_id == 0 should mean "not set".
> > > > >
> > > > > Maybe that is the best idea. Definitely the ufo_fragid_set bit should
> > > > > move into the skb_shared_info area.
> > > >
> > > > That's what I originally wanted to do, but had to move and grow txflags thus
> > > > skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
> > > >
> > > > I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
> > > > from the protocol perspective and could actually be generated by the id generator
> > > > functions. This may cause us to call the id generation multiple times.
> > >
> > > Are there plans in the long run to let virtio_net transmit auxiliary
> > > data to the other end so we can clean all of this this up one day?
> > >
> > > I don't like the whole situation: looking into the virtio_net headers
> > > just adding a field for ipv6 fragmentation ids to those small structs
> > > seems bloated, not doing it feels incorrect. :/
> > >
> > > Thoughts?
> > >
> > > Bye,
> > > Hannes
> >
> > I'm not sure - what will be achieved by generating the IDs guest side as
> > opposed to host side? It's certainly harder to get hold of entropy
> > guest-side.
>
> It is not only about entropy but about uniqueness. Also fragmentation
> ids should not be discoverable,
I belive "predictable" is the language used by the IETF draft.
> so there are several aspects:
>
> I see fragmentation id generation still as security critical:
> When Eric patched the frag id generator in 04ca6973f7c1a0d ("ip: make IP
> identifiers less predictable") I could patch my kernels and use the
> patch regardless of the machine being virtualized or not. It was not
> dependent on the hypervisor.
And now it's even easier - just patch the hypervisor, and all VMs
automatically benefit.
> I think that is the same reasoning why we
> don't support TOE.
> If we use one generator in the hypervisor in an openstack alike setting,
> the host deals with quite a lot of overlay networks. A lot of default
> configurations use the same addresses internally, so on the hypervisor
> the frag id generators would interfere by design.
> I could come up with an attack scenario for DNS servers (again :) ):
>
> You are sitting next to a DNS server on the same hypervisor and can send
> packets without source validation (because that is handled later on in
> case of openvswitch when the packet is put into the corresponding
> overlay network). You emit a gso packet with the same source and
> destination addresses as the DNS server would do and would get an
> fragmentation id which is linearly (+ time delta) incremented depending
> on the source and destination address. With such a leak you could start
> trying attack and spoof DNS responses (fragmentation attacks etc.).
> See also details on such kind of attacks in the description of commit
> 04ca6973f7c1a0d.
>
> AFAIK IETF tried with IPv6 to push fragmentation id generation to the
> end hosts, that's also the reason for the introduction of atomic
> fragments (which are now being rolled back ;) ).
>
> Still it is better to generate a frag id on the hypervisor than just
> sending a 0, so I am ok with this change, albeit not happy.
>
> Thanks,
> Hannes
>
OK so to summarize, identifiers are only re-randomized once per jiffy,
so you worry that within this window, an external observer can discover
past fragment ID values and so predict the future ones.
All that's required is that two paths go through the same box performing
fragmentation.
Is that a fair summary?
If yes, we can make this a bit harder by mixing in some
data per input and/or output devices.
For example, just to give you the idea:
diff --git a/net/core/dev.c b/net/core/dev.c
index 683d493..4faa7ef 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3625,6 +3625,7 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
trace_netif_receive_skb(skb);
orig_dev = skb->dev;
+ skb_shinfo(skb)->ip6_frag_id = skb->dev->ifindex;
skb_reset_network_header(skb);
if (!skb_transport_header_was_set(skb))
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index ce69a12..819a821 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1092,7 +1092,8 @@ static inline int ip6_ufo_append_data(struct sock *sk,
sizeof(struct frag_hdr)) & ~7;
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
ipv6_select_ident(&fhdr, rt);
- skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
+ skb_shinfo(skb)->ip6_frag_id = jhash_1word(skb_shinfo(skb)->ip6_frag_id,
+ fhdr.identification);
append:
return skb_append_datato_frags(sk, skb, getfrag, from,
--
MST
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Daniel Borkmann @ 2015-01-28 8:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Jiri Pirko
In-Reply-To: <20150128120214.3307aed8@canb.auug.org.au>
On 01/28/2015 02:02 AM, Stephen Rothwell wrote:
...
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks!
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Hannes Frederic Sowa @ 2015-01-28 8:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, Vladislav Yasevich, virtualization, edumazet,
Ben Hutchings
In-Reply-To: <20150127160808.GA10765@redhat.com>
Hello,
On Di, 2015-01-27 at 18:08 +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
> > On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
> > > On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
> > > > On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> > > >> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> > > >>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> > > >>>> If the IPv6 fragment id has not been set and we perform
> > > >>>> fragmentation due to UFO, select a new fragment id.
> > > >>>> When we store the fragment id into skb_shinfo, set the bit
> > > >>>> in the skb so we can re-use the selected id.
> > > >>>> This preserves the behavior of UFO packets generated on the
> > > >>>> host and solves the issue of id generation for packet sockets
> > > >>>> and tap/macvtap devices.
> > > >>>>
> > > >>>> This patch moves ipv6_select_ident() back in to the header file.
> > > >>>> It also provides the helper function that sets skb_shinfo() frag
> > > >>>> id and sets the bit.
> > > >>>>
> > > >>>> It also makes sure that we select the fragment id when doing
> > > >>>> just gso validation, since it's possible for the packet to
> > > >>>> come from an untrusted source (VM) and be forwarded through
> > > >>>> a UFO enabled device which will expect the fragment id.
> > > >>>>
> > > >>>> CC: Eric Dumazet <edumazet@google.com>
> > > >>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > >>>> ---
> > > >>>> include/linux/skbuff.h | 3 ++-
> > > >>>> include/net/ipv6.h | 2 ++
> > > >>>> net/ipv6/ip6_output.c | 4 ++--
> > > >>>> net/ipv6/output_core.c | 9 ++++++++-
> > > >>>> net/ipv6/udp_offload.c | 10 +++++++++-
> > > >>>> 5 files changed, 23 insertions(+), 5 deletions(-)
> > > >>>>
> > > >>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > >>>> index 85ab7d7..3ad5203 100644
> > > >>>> --- a/include/linux/skbuff.h
> > > >>>> +++ b/include/linux/skbuff.h
> > > >>>> @@ -605,7 +605,8 @@ struct sk_buff {
> > > >>>> __u8 ipvs_property:1;
> > > >>>> __u8 inner_protocol_type:1;
> > > >>>> __u8 remcsum_offload:1;
> > > >>>> - /* 3 or 5 bit hole */
> > > >>>> + __u8 ufo_fragid_set:1;
> > > >>> [...]
> > > >>>
> > > >>> Doesn't the flag belong in struct skb_shared_info, rather than struct
> > > >>> sk_buff? Otherwise this looks fine.
> > > >>>
> > > >>> Ben.
> > > >>
> > > >> Hmm we seem to be out of tx flags.
> > > >> Maybe ip6_frag_id == 0 should mean "not set".
> > > >
> > > > Maybe that is the best idea. Definitely the ufo_fragid_set bit should
> > > > move into the skb_shared_info area.
> > >
> > > That's what I originally wanted to do, but had to move and grow txflags thus
> > > skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
> > >
> > > I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
> > > from the protocol perspective and could actually be generated by the id generator
> > > functions. This may cause us to call the id generation multiple times.
> >
> > Are there plans in the long run to let virtio_net transmit auxiliary
> > data to the other end so we can clean all of this this up one day?
> >
> > I don't like the whole situation: looking into the virtio_net headers
> > just adding a field for ipv6 fragmentation ids to those small structs
> > seems bloated, not doing it feels incorrect. :/
> >
> > Thoughts?
> >
> > Bye,
> > Hannes
>
> I'm not sure - what will be achieved by generating the IDs guest side as
> opposed to host side? It's certainly harder to get hold of entropy
> guest-side.
It is not only about entropy but about uniqueness. Also fragmentation
ids should not be discoverable, so there are several aspects:
I see fragmentation id generation still as security critical:
When Eric patched the frag id generator in 04ca6973f7c1a0d ("ip: make IP
identifiers less predictable") I could patch my kernels and use the
patch regardless of the machine being virtualized or not. It was not
dependent on the hypervisor. I think that is the same reasoning why we
don't support TOE.
If we use one generator in the hypervisor in an openstack alike setting,
the host deals with quite a lot of overlay networks. A lot of default
configurations use the same addresses internally, so on the hypervisor
the frag id generators would interfere by design.
I could come up with an attack scenario for DNS servers (again :) ):
You are sitting next to a DNS server on the same hypervisor and can send
packets without source validation (because that is handled later on in
case of openvswitch when the packet is put into the corresponding
overlay network). You emit a gso packet with the same source and
destination addresses as the DNS server would do and would get an
fragmentation id which is linearly (+ time delta) incremented depending
on the source and destination address. With such a leak you could start
trying attack and spoof DNS responses (fragmentation attacks etc.).
See also details on such kind of attacks in the description of commit
04ca6973f7c1a0d.
AFAIK IETF tried with IPv6 to push fragmentation id generation to the
end hosts, that's also the reason for the introduction of atomic
fragments (which are now being rolled back ;) ).
Still it is better to generate a frag id on the hypervisor than just
sending a 0, so I am ok with this change, albeit not happy.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH RESEND] ssb: Fix Sparse error in main
From: Rafał Miłecki @ 2015-01-28 7:13 UTC (permalink / raw)
To: Pramod Gurav
Cc: Kalle Valo, John Linville, Michael Buesch, Network Development,
Linux Kernel Mailing List, linux-wireless@vger.kernel.org
In-Reply-To: <1422424187-19059-1-git-send-email-pramod.gurav@smartplayin.com>
On 28 January 2015 at 06:49, Pramod Gurav <pramod.gurav@smartplayin.com> wrote:
> This change fixes below sparse error:
> drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
> was not declared. Should it be static?
Seems like it was never used. Looks OK.
^ permalink raw reply
* Re: A problem about ICMP packet-too-big message handler
From: Yang Yingliang @ 2015-01-28 6:46 UTC (permalink / raw)
To: Martin Lau; +Cc: netdev, David S. Miller
In-Reply-To: <20150128051929.GA3369592@devbig242.prn2.facebook.com>
On 2015/1/28 13:19, Martin Lau wrote:
> On Tue, Jan 27, 2015 at 08:58:53PM +0800, Yang Yingliang wrote:
>> Hi,
>>
>> My kernel is 3.10 LTS.
>>
>> I got a problem here about handling ICMP packet-too-big message.
>>
>> Before sending a packet-too-big packet :
> The expires should be set by the host _receiving_ the icmpv6 too-big.
>
> Can you spell out some details of the outgoing icmpv6 too-big packet?
> like, the src/dst ip of the icmpv6 and the original ip packet that triggered the
> too-big.
>
I don't send too-big packet to trigger the err handling.
I just only send a ICMPv6 packet which type is ICMPV6_PKT_TOOBIG.
^ permalink raw reply
* [PATCH RESEND] ssb: Fix Sparse error in main
From: Pramod Gurav @ 2015-01-28 5:49 UTC (permalink / raw)
To: Kalle Valo, John Linville, Michael Buesch
Cc: netdev, linux-kernel, linux-wireless, Pramod Gurav
This change fixes below sparse error:
drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
was not declared. Should it be static?
Acked-by: Michael Buesch <m@bues.ch>
Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
---
drivers/ssb/main.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index 2fead38..1e180c4 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -90,25 +90,6 @@ found:
}
#endif /* CONFIG_SSB_PCMCIAHOST */
-#ifdef CONFIG_SSB_SDIOHOST
-struct ssb_bus *ssb_sdio_func_to_bus(struct sdio_func *func)
-{
- struct ssb_bus *bus;
-
- ssb_buses_lock();
- list_for_each_entry(bus, &buses, list) {
- if (bus->bustype == SSB_BUSTYPE_SDIO &&
- bus->host_sdio == func)
- goto found;
- }
- bus = NULL;
-found:
- ssb_buses_unlock();
-
- return bus;
-}
-#endif /* CONFIG_SSB_SDIOHOST */
-
int ssb_for_each_bus_call(unsigned long data,
int (*func)(struct ssb_bus *bus, unsigned long data))
{
--
1.7.9.5
^ permalink raw reply related
* [PATCH] bridge: dont send notification when skb->len == 0 in rtnl_bridge_notify
From: roopa @ 2015-01-28 5:46 UTC (permalink / raw)
To: netdev, stephen, rami.rosen
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Reported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081
This patch avoids calling rtnl_notify if the device ndo_bridge_getlink
handler does not return any bytes in the skb.
Alternately, the skb->len check can be moved inside rtnl_notify.
For the bridge vlan case described in 92081, there is also a fix needed
in bridge driver to generate a proper notification. Will fix that in
subsequent patch.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
net/core/rtnetlink.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 07447d1..e9d0f86 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2934,7 +2934,7 @@ static int rtnl_bridge_notify(struct net_device *dev)
}
err = dev->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev, 0);
- if (err < 0)
+ if (err < 0 || !skb->len)
goto errout;
rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, GFP_ATOMIC);
@@ -2942,7 +2942,8 @@ static int rtnl_bridge_notify(struct net_device *dev)
errout:
WARN_ON(err == -EMSGSIZE);
kfree_skb(skb);
- rtnl_set_sk_err(net, RTNLGRP_LINK, err);
+ if (err)
+ rtnl_set_sk_err(net, RTNLGRP_LINK, err);
return err;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND] ssb: Fix Sparse error in main
From: Pramod Gurav @ 2015-01-28 5:22 UTC (permalink / raw)
To: Kalle Valo, John Linville, Michael Buesch
Cc: netdev, linux-kernel, Pramod Gurav
This change fixes below sparse error:
drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
was not declared. Should it be static?
Acked-by: Michael Buesch <m@bues.ch>
Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
---
drivers/ssb/main.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index 2fead38..1e180c4 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -90,25 +90,6 @@ found:
}
#endif /* CONFIG_SSB_PCMCIAHOST */
-#ifdef CONFIG_SSB_SDIOHOST
-struct ssb_bus *ssb_sdio_func_to_bus(struct sdio_func *func)
-{
- struct ssb_bus *bus;
-
- ssb_buses_lock();
- list_for_each_entry(bus, &buses, list) {
- if (bus->bustype == SSB_BUSTYPE_SDIO &&
- bus->host_sdio == func)
- goto found;
- }
- bus = NULL;
-found:
- ssb_buses_unlock();
-
- return bus;
-}
-#endif /* CONFIG_SSB_SDIOHOST */
-
int ssb_for_each_bus_call(unsigned long data,
int (*func)(struct ssb_bus *bus, unsigned long data))
{
--
1.7.9.5
^ permalink raw reply related
* Re: A problem about ICMP packet-too-big message handler
From: Martin Lau @ 2015-01-28 5:19 UTC (permalink / raw)
To: Yang Yingliang; +Cc: netdev, David S. Miller
In-Reply-To: <54C78B8D.1070104@huawei.com>
On Tue, Jan 27, 2015 at 08:58:53PM +0800, Yang Yingliang wrote:
> Hi,
>
> My kernel is 3.10 LTS.
>
> I got a problem here about handling ICMP packet-too-big message.
>
> Before sending a packet-too-big packet :
The expires should be set by the host _receiving_ the icmpv6 too-big.
Can you spell out some details of the outgoing icmpv6 too-big packet?
like, the src/dst ip of the icmpv6 and the original ip packet that triggered the
too-big.
^ permalink raw reply
* Re: Fw: [Bug 92081] New: skb->len=0 and getting "EOF on netlink" with "ip monitor all" (of iproute) when adding a vlan with "bridge vlan add"
From: roopa @ 2015-01-28 5:18 UTC (permalink / raw)
To: Rosen, Rami; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <9B0331B6EBBD0E4684FBFAEDA55776F91890AE59@HASMSX110.ger.corp.intel.com>
On 1/27/15, 10:38 AM, Rosen, Rami wrote:
> Hi, Roopa,
>
>> I think my below commit fixed one case of such error:
> I am well aware of your commit (in fact I even sent cleanup patch on top of it, removing the oflags, which was applied).
>
> It seems to me that this commit of yours does not avoid the specific problem of getting EOF with "ip monitor all" which is described in the BUG I opened; it
> could be that it avoid problem with other scenarios, and with wrong message size when both SELF and MASTER flags are set.
>
>> The reason for the zero length message in this case is that the user is sending
>> the setlink request to the bridge with self flag set.
>> And since the getlink on the bridge device only returns bytes when its a bridge port, there are no bytes in the skb.
>> I will reconfirm that the above is true and submit a patch (I can update the bugzilla link below as well).
> This is exactly so, I am fully confident about it, I checked it in depth with debug , and I had printed the skb->len before calling rtnl_notify() in
> rtnl_bridge_notify() in net/core/rtnetlink.c under such scenario described in the BUG mentioned in the bugzilla link and it was indeed 0.
>
> For the sake of those who are interested in more implementation details and in the code walkthrough under such scenario, what happens when "bridge vlan add vid 1 dev br0 self" , you should follow this path:
>
> Look at rtnl_bridge_setlink() method, it is invoked in this case.
> http://lxr.free-electrons.com/source/net/core/rtnetlink.c#L2782
>
> If the SELF flag is set it calls dev->netdev_ops->ndo_bridge_setlink()
> See:
> http://lxr.free-electrons.com/source/net/core/rtnetlink.c#L2840
>
> and then it calls rtnl_bridge_notify()
> See:
> http://lxr.free-electrons.com/source/net/core/rtnetlink.c#L2850
>
> Now, rtnl_bridge_notify() calls dev->netdev_ops->ndo_bridge_getlink()
> when the self flag is set.
> See:
> http://lxr.free-electrons.com/source/net/core/rtnetlink.c#L2767
>
> Now, when running the "bridge vlan add" on a bridge device like we do (and **not on a bridge port**)
> then the dev variable is an instance of a software bridge. So this calls the ndo_bridge_getlink() callback of the software bridge, which is br_getlink():
> See:
> http://lxr.free-electrons.com/source/net/bridge/br_netlink.c#L205
>
> Now, br_getlink() first checks if the device is a bridge port:
> struct net_bridge_port *port = br_port_get_rtnl(dev);
>
> And it returns 0 if not.
> So as a result, the skb->len is 0 and an empty notification is sent.
>
> And when the rtneltnlink socket, which is opened by "ip monitor all" and listens to netlink messages, receives an
> empty notification it terminates with the "EOF" message (as mentioned in the bugzilla link).
>
> Sending a patch for resolving it and updating the bugzilla will be really great!
Thanks for the details. I have updated the bugzilla with my notes and
your notes from this email.
Now i have a patch that avoids sending a notification if skb->len == 0.
But, the real fix is to get bridge driver ndo_bridge_getlink to do the
right thing and send the updated vlan notification.
I will send the skb->len check patch shortly. And then look at fixing
ndo_bridge_getlink
^ permalink raw reply
* Re: [PATCH v3 0/3] net: stmmac: Enable Intel Quark SoC X1000 Ethernet support
From: David Miller @ 2015-01-28 5:08 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: peppe.cavallaro, netdev
In-Reply-To: <1422387889-21559-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 27 Jan 2015 21:44:46 +0200
> This is third version of the patch series [1] to bring network card support to
> Intel Quark SoC.
>
> The series has been tested on Intel Galileo board.
>
> Changelog v3:
> - rebase on top of recent net-next
> - rework an approach to get the custom configuration
> - rework an approach how to get unique bus_id
> - improve DMI lookup function
>
> [1] http://www.spinics.net/lists/netdev/msg296010.html
Series applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox