All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 1/4] slirp: Fix restricted mode
Date: Tue, 24 May 2011 17:37:55 +0200	[thread overview]
Message-ID: <4DDBD0D3.3030306@siemens.com> (raw)
In-Reply-To: <20110524143758.GA22042@redhat.com>

On 2011-05-24 16:37, Gleb Natapov wrote:
> On Tue, May 24, 2011 at 03:34:33PM +0200, Jan Kiszka wrote:
>> On 2011-05-24 15:01, Gleb Natapov wrote:
>>> On Tue, May 24, 2011 at 02:42:55PM +0200, Jan Kiszka wrote:
>>>> On 2011-05-24 14:37, Gleb Natapov wrote:
>>>>> On Mon, May 23, 2011 at 04:48:16PM +0200, Jan Kiszka wrote:
>>>>>> This aligns the code to what the documentation claims: Allow everything
>>>>>> but requests that would have to be routed outside of the virtual LAN.
>>>>>>
>>>>>> So we need to drop the unneeded IP-level filter, allow TFTP requests,
>>>>>> and add the missing protocol-level filter to ICMP.
>>>>>>
>>>>> May be I am missing something, but how do you disallow requests by
>>>>> removing code that actually does filtering.
>>>>
>>>> All we need to filter are the per-IP-protocol parts that do the
>>>> forwarding via the host IP stack. That does not need to happen at IP level.
>>>>
>>>> Moreover, the existing code contained some practically dead bits anyway:
>>>>
>>>>         if ((ip->ip_dst.s_addr & slirp->vnetwork_mask.s_addr) ==
>>>>             slirp->vnetwork_addr.s_addr) {
>>>>             if (ip->ip_dst.s_addr == 0xffffffff && ip->ip_p !=
>>>>                 IPPROTO_UDP)
>>>>                 goto bad;
>>>>
>>>> This could only trigger if vnetwork_mask.s_addr was 0 (the same applied
>>>> to the original code before my refactoring in 2009).
>>>>
>>> Not sure what do you mean by that. This checks that the ip_dst.s_addr is in
>>> the vnetwork range. It does this by comparing net mask bits of ip_dst.s_addr with
>>> vnetwork_addr.s_addr. Grep for vnetwork_mask.s_addr. This idiom is used
>>> many times throughout the code.
>>
>> Ok, it's a bit more tricky, and I contributed some buglet. Let
>>
>> ip_dst.s_addr		= 255.255.255.255
>> vnetwork_mask.s_addr	= 0.255.255.255
> Isn't it 255.0.0.0?
> 
>> vnetwork_addr.s_addr	= 10.0.2.0
>> (QEMU's strange defaults)
>>
>> then dst & vnetwork_mask != vnetwork_addr, so the second condition to
>> exclude network broadcasts can't trigger.
>>
>> Your original code matched the first three bytes of dst against the
>> first three of vnetwork_addr, mine inverted the mask. However, both
>> variants fail to let DHCP broadcasts pass.
> The original code used memcmp which return 0 when equal. When you
> changed it to use variable length mask you also inverted if() condition.
> It should be != not == !
> 
> The code worked (for some value of 'worked') back then :)

Mmh, so I really broke - then it's only fair that I'm now fixing it
again. :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2011-05-24 15:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-23 14:48 [Qemu-devel] [PATCH 0/4] slirp: Fixes for restricted mode and more Jan Kiszka
2011-05-23 14:48 ` [Qemu-devel] [PATCH 1/4] slirp: Fix restricted mode Jan Kiszka
2011-05-24 12:37   ` Gleb Natapov
2011-05-24 12:42     ` Jan Kiszka
2011-05-24 13:01       ` Gleb Natapov
2011-05-24 13:34         ` Jan Kiszka
2011-05-24 14:37           ` Gleb Natapov
2011-05-24 15:37             ` Jan Kiszka [this message]
2011-05-23 14:48 ` [Qemu-devel] [PATCH 2/4] slirp: Canonicalize restrict syntax Jan Kiszka
2011-05-23 14:48 ` [Qemu-devel] [PATCH 3/4] slirp: Strictly associate DHCP/BOOTP and TFTP with virtual host Jan Kiszka
2011-05-23 14:48 ` [Qemu-devel] [PATCH 4/4] slirp: Replace m_freem with m_free Jan Kiszka

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=4DDBD0D3.3030306@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=gleb@redhat.com \
    --cc=qemu-devel@nongnu.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.