All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Samuel Thibault <samuel.thibault@gnu.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH, DoS] slirp (arp): do not special-case bogus IP addresses
Date: Wed, 14 May 2014 00:30:09 +0000	[thread overview]
Message-ID: <20140514003009.GB21821@hostname> (raw)
In-Reply-To: <20140513221547.GE6302@type.youpi.perso.aquilenet.fr>

On Wed, May 14, 2014 at 12:15:47AM +0200, Samuel Thibault wrote:
> Edgar E. Iglesias, le Thu 08 May 2014 06:59:22 +0000, a écrit :
> > On Thu, May 08, 2014 at 08:50:33AM +0200, Samuel Thibault wrote:
> > > Edgar E. Iglesias, le Thu 08 May 2014 06:10:18 +0000, a écrit :
> > > > The search part looks OK to me but when adding to the arp table, don't
> > > > you at least want to avoid adding mappings for 0.0.0.0/32?
> > > 
> > > I don't see the gain, actually.  It would mean burning some CPU all the
> > > time just to save a small potential memory loss and CPU burning in the
> > > rare case when the guest behaves oddly.
> > > 
> > > > to avoid for ex garps to pollute the cache with invalid entries?
> > > 
> > > Only one entry will be created and updated by garps. The guest already
> > > has a lot of ways to pollute the cache :)
> > 
> > I was under the impression that entries for 0.0.0.0 are strictly
> > invalid (not about performance). I might be wrong though.
> 
> I'd tend to think that, but what should be done? I don't think we want
> an assert failure :)
> 

Right, I didn't mean that the assert should stay.

> At best I could think of using the patch below, which avoids registering
> anything for 0.0.0.0, and use a broadcast to answer a guest which
> would have used 0.0.0.0 as a source for whatever reason.  I don't find
> anything else reasonable.  What would be preferred?

Specs are not super clear on this but rfc1700 says that 0.0.0.0 is a source only address.
http://www.rfc-editor.org/rfc/rfc1700.txt Page 3
http://tools.ietf.org/html/draft-iana-special-ipv4-04 Page 1

What I was trying to suggest was a mix between your two versions.
Removing the assert in table_search and avoid adding 0.0.0.0/32 to the cache
in table_add. We might need to complement with something that drops datagrams
destined to 0.0.0.0 in upper layers so we dont keep trying, not sure.
Does something like that make sense?

Cheers,
Edgar


> 
> Samuel
> 
> diff --git a/slirp/arp_table.c b/slirp/arp_table.c
> index ecdb0ba..d160cfc 100644
> --- a/slirp/arp_table.c
> +++ b/slirp/arp_table.c
> @@ -37,12 +37,7 @@ void arp_table_add(Slirp *slirp, uint32_t ip_addr, uint8_t ethaddr[ETH_ALEN])
>                  ethaddr[0], ethaddr[1], ethaddr[2],
>                  ethaddr[3], ethaddr[4], ethaddr[5]));
>  
> -    /* Check 0.0.0.0/8 invalid source-only addresses */
> -    if ((ip_addr & htonl(~(0xfU << 28))) == 0) {
> -        return;
> -    }
> -
> -    if (ip_addr == 0xffffffff || ip_addr == broadcast_addr) {
> +    if (ip_addr == 0 || ip_addr == 0xffffffff || ip_addr == broadcast_addr) {
>          /* Do not register broadcast addresses */
>          return;
>      }
> @@ -73,11 +68,8 @@ bool arp_table_search(Slirp *slirp, uint32_t ip_addr,
>      DEBUG_CALL("arp_table_search");
>      DEBUG_ARG("ip = 0x%x", ip_addr);
>  
> -    /* Check 0.0.0.0/8 invalid source-only addresses */
> -    assert((ip_addr & htonl(~(0xfU << 28))) != 0);
> -
>      /* If broadcast address */
> -    if (ip_addr == 0xffffffff || ip_addr == broadcast_addr) {
> +    if (ip_addr == 0 || ip_addr == 0xffffffff || ip_addr == broadcast_addr) {
>          /* return Ethernet broadcast address */
>          memset(out_ethaddr, 0xff, ETH_ALEN);
>          return 1;

  reply	other threads:[~2014-05-14  0:30 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-30 22:22 [Qemu-devel] [PATCHv4 00/18] slirp: Adding IPv6 support to Qemu -net user mode Samuel Thibault
2014-03-30 22:22 ` [Qemu-devel] [PATCH 01/18] slirp: goto bad in udp_input if sosendto fails Samuel Thibault
2014-05-07 22:15   ` [Qemu-devel] [PATCH, DoS] slirp (arp): do not special-case bogus IP addresses Samuel Thibault
2014-05-08  6:10     ` Edgar E. Iglesias
2014-05-08  6:50       ` Samuel Thibault
2014-05-08  6:59         ` Edgar E. Iglesias
2014-05-13 22:15           ` Samuel Thibault
2014-05-14  0:30             ` Edgar E. Iglesias [this message]
2014-05-14  0:44               ` Samuel Thibault
2014-05-14  0:54                 ` Edgar E. Iglesias
2014-05-14  1:11                   ` Samuel Thibault
2014-05-14  1:13     ` [Qemu-devel] [PATCHv2, " Samuel Thibault
2014-05-14  1:22       ` Edgar E. Iglesias
     [not found]         ` <20140527231002.GB3396@toto>
2014-06-12  5:48           ` Jan Kiszka
2014-06-09  0:01       ` Edgar E. Iglesias
2014-03-30 22:22 ` [Qemu-devel] [PATCH 02/18] slirp: Generalizing and neutralizing code before adding IPv6 stuff Samuel Thibault
2014-03-30 22:22 ` [Qemu-devel] [PATCH 03/18] slirp: Reindent after refactoring Samuel Thibault
2014-03-30 22:22 ` [Qemu-devel] [PATCH 04/18] slirp: Make Socket structure IPv6 compatible Samuel Thibault
2014-03-30 22:22 ` [Qemu-devel] [PATCH 05/18] slirp: Factorizing address translation Samuel Thibault
2014-03-30 22:22 ` [Qemu-devel] [PATCH 06/18] slirp: Factorizing and cleaning solookup() Samuel Thibault
2014-03-30 22:22 ` [Qemu-devel] [PATCH 07/18] slirp: Make udp_attach IPv6 compatible Samuel Thibault
2014-03-30 22:22 ` [Qemu-devel] [PATCH 08/18] slirp: Adding family argument to tcp_fconnect() Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 09/18] qemu/timer.h : Adding function to second scale Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 10/18] slirp: Adding IPv6, ICMPv6 Echo and NDP autoconfiguration Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 11/18] slirp: Adding ICMPv6 error sending Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 12/18] slirp: Adding IPv6 UDP support Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 13/18] slirp: Factorizing tcpiphdr structure with an union Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 14/18] slirp: Generalizing and neutralizing various TCP functions before adding IPv6 stuff Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 15/18] slirp: Reindent after refactoring Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 16/18] slirp: Handle IPv6 in TCP functions Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 17/18] slirp: Adding IPv6 address for DNS relay Samuel Thibault
2014-03-30 22:23 ` [Qemu-devel] [PATCH 18/18] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses Samuel Thibault

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140514003009.GB21821@hostname \
    --to=edgar.iglesias@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=samuel.thibault@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.