* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Christoph Hellwig @ 2006-05-09 11:58 UTC (permalink / raw)
To: Chris Wright
Cc: linux-kernel, virtualization, xen-devel, Ian Pratt,
Christian Limpach, netdev
In-Reply-To: <20060509085201.446830000@sous-sol.org>
On Tue, May 09, 2006 at 12:00:34AM -0700, Chris Wright wrote:
> The network device frontend driver allows the kernel to access network
> devices exported exported by a virtual machine containing a physical
> network device driver.
Please don't add procfs code to new network drivers. Especially if it's oopsable
like the code in this driver by simple device renaming.
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Christian Limpach @ 2006-05-09 12:43 UTC (permalink / raw)
To: Herbert Xu
Cc: Chris Wright, linux-kernel, virtualization, xen-devel, netdev,
ian.pratt
In-Reply-To: <E1FdQoP-0007iN-00@gondolin.me.apana.org.au>
On Tue, May 09, 2006 at 09:55:33PM +1000, Herbert Xu wrote:
> Hi Chris:
>
> Chris Wright <chrisw@sous-sol.org> wrote:
> >
> > +/** Send a packet on a net device to encourage switches to learn the
> > + * MAC. We send a fake ARP request.
> > + *
> > + * @param dev device
> > + * @return 0 on success, error code otherwise
> > + */
> > +static int send_fake_arp(struct net_device *dev)
>
> I think we talked about this before. I don't see why Xen is so special
> that it needs its own gratuitous arp routine embedded in the driver.
> If this is needed at all (presumably for migration) then it should be
> performed by the management scripts which can send grat ARP packets just
> as easily.
There's at least two reasons why having it in the driver is preferable:
- synchronizing sending the fake ARP request with when the device is
operational -- you really want to make this well synchronized to keep
unreachability as short as possible, especially when doing live
migration
- anybody but the guest might not know (all) the MAC addresses for which
to send a fake ARP request
christian
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Herbert Xu @ 2006-05-09 13:01 UTC (permalink / raw)
To: Christian Limpach
Cc: herbert, xen-devel, ian.pratt, netdev, linux-kernel, chrisw,
virtualization
In-Reply-To: <20060509124359.GA5407@cl.cam.ac.uk>
Christian Limpach <Christian.Limpach@cl.cam.ac.uk> wrote:
>
> There's at least two reasons why having it in the driver is preferable:
> - synchronizing sending the fake ARP request with when the device is
> operational -- you really want to make this well synchronized to keep
> unreachability as short as possible, especially when doing live
> migration
> - anybody but the guest might not know (all) the MAC addresses for which
> to send a fake ARP request
Sure. However, what's there to stop you from doing this in user-space
inside the guest?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Andi Kleen @ 2006-05-09 13:14 UTC (permalink / raw)
To: virtualization
Cc: Herbert Xu, Christian Limpach, chrisw, ian.pratt, xen-devel,
netdev, linux-kernel
In-Reply-To: <E1FdRpp-0008HG-00@gondolin.me.apana.org.au>
On Tuesday 09 May 2006 15:01, Herbert Xu wrote:
> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> wrote:
> >
> > There's at least two reasons why having it in the driver is preferable:
> > - synchronizing sending the fake ARP request with when the device is
> > operational -- you really want to make this well synchronized to keep
> > unreachability as short as possible, especially when doing live
> > migration
> > - anybody but the guest might not know (all) the MAC addresses for which
> > to send a fake ARP request
>
> Sure. However, what's there to stop you from doing this in user-space
> inside the guest?
I guess they don't trust user space. But the standard ipup script
from iproute2 does this already so at least for modern distributions
it should just work.
-Andi
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Christian Limpach @ 2006-05-09 13:16 UTC (permalink / raw)
To: Herbert Xu
Cc: xen-devel, virtualization, netdev, linux-kernel, chrisw,
ian.pratt
In-Reply-To: <E1FdRpp-0008HG-00@gondolin.me.apana.org.au>
On Tue, May 09, 2006 at 11:01:05PM +1000, Herbert Xu wrote:
> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> wrote:
> >
> > There's at least two reasons why having it in the driver is preferable:
> > - synchronizing sending the fake ARP request with when the device is
> > operational -- you really want to make this well synchronized to keep
> > unreachability as short as possible, especially when doing live
> > migration
> > - anybody but the guest might not know (all) the MAC addresses for which
> > to send a fake ARP request
>
> Sure. However, what's there to stop you from doing this in user-space
> inside the guest?
Possibly having to page in the process and switching to it would add
to the live migration time. More importantly, having to install an
additional program in the guest is certainly not very convenient.
christian
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Herbert Xu @ 2006-05-09 13:26 UTC (permalink / raw)
To: Christian Limpach
Cc: xen-devel, herbert, virtualization, netdev, linux-kernel, chrisw,
ian.pratt
In-Reply-To: <20060509131632.GB7834@cl.cam.ac.uk>
Christian Limpach <Christian.Limpach@cl.cam.ac.uk> wrote:
>
> Possibly having to page in the process and switching to it would add
> to the live migration time. More importantly, having to install an
> additional program in the guest is certainly not very convenient.
Sorry I'm still not convinced. What's there to stop me from suspending
my laptop to disk, moving it from port A to port B and resuming it?
Wouldn't I be in exactly the same situation? By the same reasoning we'd
be adding a gratuitous ARP routine to every single laptop network driver.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] SECMARK 1.0
From: Karl MacMillan @ 2006-05-09 13:24 UTC (permalink / raw)
To: James Morris
Cc: Joshua Brindle, selinux, netdev, netfilter-devel, Stephen Smalley,
Daniel J Walsh
In-Reply-To: <Pine.LNX.4.64.0605081719440.18947@d.namei>
On Mon, 2006-05-08 at 17:29 -0400, James Morris wrote:
> On Mon, 8 May 2006, Karl MacMillan wrote:
>
> > Something like CONNMARK seems preferable to me (perhaps even allowing
> > type_transition rules to give the related packets a unique type). This
> > makes the labeling reflect the real security property of the packets.
>
> That's arguable. The real security property afaict is that the packets
> are of some state (established or related to an existing connection). It
> is implicit in the mechanism that they're tracked as part of an authorized
> connection.
>
This loses how the connection was initiated, however. Packets that are
part of a connection that was initiated on the ftp port are different
from packets that are part of a connection initiated on the telnet port.
Now, the name_bind permissions will limit which domains can initiate
those connection, but my concern is that connection could, through error
or exploit, be passed to another domain that should not receive packets
from that type of connection (see below).
> > Yes, we are trusting the conntrack to mark the packets accurately, but
> > it makes the policy match the intent. Otherwise it is not possible to
> > reason about information flow using just the policy.
>
> Why not? You just state that all established and related packets reaching
> vsftpd are valid, and that no invalid packets can deliver data to the
> application. You can play tricks and stick a label on a packet but that
> doesn't change what's actually happening or your ability to reason about
> it. You assume conntrack works correctly (and if it doesn't, then
> labeling connections will break, too).
>
The use of a single related packet type loses the strong binding between
the connection type (determined on connection) and domains, most likely
because an established connection is passed to another process.
For example, for xinetd to work all of the xinetd children would be
allowed to receive all related packets (i.e., tracked_packet_t). This
means that if xinetd incorrectly passed, say, an ftp connection to
telnet it would still be allowed to receive those packets because they
would be of type tracked_packet_t. Labeling using something like
connmark seems to solve this problem. There may be other examples
relating to enforcing data separation based on other connection
information, like the network interface, but I haven't had a chance to
work through those scenarios.
Now you may be saying that it is not possible to determine with any
assurance that a related packet is related to, for example, a connection
that was initiated on the ftp port (and therefore given a different type
- related_ftp_packet_t - fixing my xinetd example). If this is the case,
your argument makes more sense to me.
Karl
--
Karl MacMillan
Tresys Technology
www.tresys.com
> > Are there serious downsides to this approach?
>
> Yes, it's an ugly hack which is not needed.
>
> > > You can always not use conntrack and emulate the existing controls, as
> > > well.
> >
> > Yes, but gaining connection tracking is a major advantage of this
> > approach over the existing controls.
>
> The point is to show that this scheme provides much stonger security
> assurrances, and that if you wished, you could easily rervert to stateless
> filtering and have the "correct" labels on the packets; which would be
> worse.
>
>
>
> - James
^ permalink raw reply
* Scanning in ieee80211 softmac layer and setting essid (newbie)
From: Ian Brown @ 2006-05-09 13:38 UTC (permalink / raw)
To: netdev
Hello,
I see that setting the essid of a wireless card
(by iwconfig eth1 essid homenet)
triggers scanning;
namely , it calls ieee80211softmac_assoc_work() method which in
turn calls ieee80211softmac_start_scan().
I use zd1211 driver which works with the softmac layer
of the last git kernel.
I saw that this scanning call occurs wheter the card is down
or up (namely, ifconfig eth1 up was called).
Only in the first case (card is down) ,it only says:
Associate: Scanning for networks first.
SoftMAC: Associate: failed to initiate scan. Is device up?
and when card is up it says:
SoftMAC: Associate: Scanning for networks first.
SoftMAC: Start scanning with channel: 1
SoftMAC: Scanning 13 channels
SoftMAC: Scanning finished
several times.
My question is : why is this scanning needed when set essid is called?
and why is the repeatition?
I am a little newbie in this...
Regards,
IB
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Christian Limpach @ 2006-05-09 14:00 UTC (permalink / raw)
To: Herbert Xu
Cc: xen-devel, virtualization, netdev, linux-kernel, chrisw,
ian.pratt
In-Reply-To: <E1FdSDz-0008Lv-00@gondolin.me.apana.org.au>
On Tue, May 09, 2006 at 11:26:03PM +1000, Herbert Xu wrote:
> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> wrote:
> >
> > Possibly having to page in the process and switching to it would add
> > to the live migration time. More importantly, having to install an
> > additional program in the guest is certainly not very convenient.
>
> Sorry I'm still not convinced. What's there to stop me from suspending
> my laptop to disk, moving it from port A to port B and resuming it?
>
> Wouldn't I be in exactly the same situation? By the same reasoning we'd
> be adding a gratuitous ARP routine to every single laptop network driver.
It is the same situation except that in the laptop case you don't care
that reconfiguring your network will take a second or a few. For live
migration we're looking at network downtime from as low as 60ms to
something like 210ms on a busy virtual machine. I'm not saying that
a userspace solution wouldn't work but it would probably add a measurable
delay to the network downtime during live migration.
You might also find the following paper an interesting read:
http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2005-migration-nsdi-pre.pdf
christian
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: David Boutcher @ 2006-05-09 14:30 UTC (permalink / raw)
To: Christian Limpach
Cc: chrisw, Herbert Xu, ian.pratt, linux-kernel, netdev,
virtualization, xen-devel
In-Reply-To: <20060509140027.GD7834@cl.cam.ac.uk>
virtualization-bounces@lists.osdl.org wrote on 05/09/2006 09:00:27 AM:
> On Tue, May 09, 2006 at 11:26:03PM +1000, Herbert Xu wrote:
> > Christian Limpach <Christian.Limpach@cl.cam.ac.uk> wrote:
> > >
> > > Possibly having to page in the process and switching to it would add
> > > to the live migration time. More importantly, having to install an
> > > additional program in the guest is certainly not very convenient.
> >
> > Sorry I'm still not convinced. What's there to stop me from
suspending
> > my laptop to disk, moving it from port A to port B and resuming it?
> >
> > Wouldn't I be in exactly the same situation? By the same reasoning
we'd
> > be adding a gratuitous ARP routine to every single laptop network
driver.
>
> It is the same situation except that in the laptop case you don't care
> that reconfiguring your network will take a second or a few. For live
> migration we're looking at network downtime from as low as 60ms to
> something like 210ms on a busy virtual machine. I'm not saying that
> a userspace solution wouldn't work but it would probably add a
measurable
> delay to the network downtime during live migration.
Then make a generic solution. VMWare supports migration, the Power
virtualization will get around to it eventually. All will need something
similar. So either make a common user-land tool, or (if you insist on
incorrectly driving this into the kernel) add some kind of common hook to
the TCP/IP stack.
Dave Boutcher
IBM Linux Technology Center
^ permalink raw reply
* Re: Scanning in ieee80211 softmac layer and setting essid (newbie)
From: Dan Williams @ 2006-05-09 15:26 UTC (permalink / raw)
To: Ian Brown; +Cc: netdev
In-Reply-To: <d0383f90605090638u3ca7a5c0je1a4ce8bc3dc696e@mail.gmail.com>
On Tue, 2006-05-09 at 16:38 +0300, Ian Brown wrote:
> Hello,
> I see that setting the essid of a wireless card
> (by iwconfig eth1 essid homenet)
> triggers scanning;
> My question is : why is this scanning needed when set essid is called?
> and why is the repeatition?
Because the wireless card needs to know information about the access
point before it can associate, like channel, BSSID, supported rates,
etc. None of these things are indicated by the SSID you've just set on
the card. Normally, when you set an SSID and the card knows nothing
about that SSID, the card will scan all channels looking for access
points that happen to match the SSID you've just set. It can then get
all the necessary information that it needs to connect to the access
point, but only _after_ it's scanned and found one with that SSID.
If the card does background scanning and keeps a list of access points
on its own, that makes things a little faster. But the scan is still
necessary in many instances.
Dan
^ permalink raw reply
* r8169+NAPI soft lockup
From: Richard Gregory @ 2006-05-09 15:44 UTC (permalink / raw)
To: netdev
I'm seeing the crash below using 2.6.16.11 custom based on RedHat FC2.
The main culprit being the r8169+NAPI module, although the it821x module
(with noraid=1) seems to bring out the bug, maybe because it uses the
same interrupt.
The machine is an Athlon 2200+ with 1.5G of ram, NForce2 chipset. Two 40
gig drives create an ext3 software raid1 OS partition and eight 160 gig
drives form a software raid5 partition, 1.1TB in size using reiserfs.
The eight drives raid5 use four ITE8182 PCI cards, the r8169 gigabit
card is in the middle of 5 PCI slots. The two raid1 boot drives use the
onboard IDE.
BUG: soft lockup detected on CPU#0!
Pid: 11413, comm: cpio
EIP: 0060:[<c027d551>] CPU: 0
EIP is at ide_intr+0x41/0xe0
EFLAGS: 00000286 Not tainted (2.6.16.11 #1)
EAX: 00000050 EBX: f6f81d80 ECX: e81a9b1c EDX: 0000d007
ESI: 04000000 EDI: 00000286 EBP: c04a8740 DS: 007b ES: 007b
CR0: 8005003b CR2: b7fa5000 CR3: 2a319000 CR4: 000006d0
[<c012c5c0>] handle_IRQ_event+0x21/0x4a
[<c012c63c>] __do_IRQ+0x53/0x8f
[<c0103fab>] do_IRQ+0x19/0x24
[<c0102b6e>] common_interrupt+0x1a/0x20
[<c030fb30>] netif_receive_skb+0x108/0x1a9
[<f883017e>] rtl8169_rx_interrupt+0x287/0x31e [r8169]
[<f8830798>] pci_unmap_single+0x0/0x10 [r8169]
[<f88303ad>] rtl8169_poll+0x37/0xb5 [r8169]
[<c030fd18>] net_rx_action+0x75/0x10a
[<c0117be1>] __do_softirq+0x35/0x7d
[<c0117c4b>] do_softirq+0x22/0x26
[<c0103fb0>] do_IRQ+0x1e/0x24
[<c0102b6e>] common_interrupt+0x1a/0x20
[<c0187b38>] is_internal+0x37/0x6f
[<c018832c>] search_by_key+0x713/0xb06
[<c0177a4d>] make_cpu_key+0x2a/0x2f
[<c01799a8>] reiserfs_update_sd_size+0x77/0x17b
[<c01220d2>] autoremove_wake_function+0x0/0x2d
[<c017d8ba>] reiserfs_prepare_file_region_for_write+0x47f/0x749
[<c018ec49>] journal_begin+0x8c/0xcd
[<c01819c4>] reiserfs_dirty_inode+0x47/0x61
[<c015e1b7>] __mark_inode_dirty+0x27/0x14b
[<c017d246>] reiserfs_submit_file_region_for_write+0x150/0x1d2
[<c017e02e>] reiserfs_file_write+0x4aa/0x58e
[<c03364e2>] tcp_v4_do_rcv+0x1b/0xb6
[<c033699f>] tcp_v4_rcv+0x422/0x66e
[<c01220df>] autoremove_wake_function+0xd/0x2d
[<c01179a2>] current_fs_time+0x3a/0x50
[<c0157c9d>] touch_atime+0x65/0xa6
[<c014d82d>] pipe_readv+0x242/0x24e
[<c01444b1>] vfs_write+0x87/0x123
[<c01445eb>] sys_write+0x3c/0x62
[<c0102947>] sysenter_past_esp+0x54/0x75
(a full trace is available,
http://www.csc.liv.ac.uk/~greg/r8169bug.tar.gz , bug1.txt)
A similar lockup (with no info, sysreq wasn't enabled) has been seen
with 2.6.14, in fact, when using the r8169+NAPI driver, the lockup would
occur any time the it821x driver was used instead of ITE's own driver.
With the ITE driver, the system has seen 400 days uptime with r8169+NAPI.
Without NAPI, the r8169 driver is stable with it821x. Can transfer at
~35meg/second for hours with only a single unexplained 10 second pause
(and link down/link up in dmesg).
The lockup requires r8169 io and it821x based disk io, onboard IDE disk
io with r8169 io does not crash the system. A raid5 sync or slocate has
never yet lead to a lockup yet is 89% full. The crash above used cpio to
backup another machine via rsh, the machine froze an hour or so into
this operation, having been up and running for at least a day with the
raid5 partition mounted read/write but mostly unaccessed. Other tests
showed this wasn't a reiserfs issue, reading the block device also
crashed the machine.
Rebooting, a raid5 resync was required, which completed without
problems. raid5 was mounted read only for all these tests, if it was
mounted at all. linuxbox is another machine, also with an r8169 card,
without the NAPI option. The discard daemon was running on port 9.
# locked up after 63 mins. Output in bug2.txt
$ find raid5 -xdev | cpio -oHnewc > /dev/tcp/linuxbox/9
# was fine for 180 mins, rebooted and did next test.
$ find raid5 -xdev | cpio -oHnewc > /dev/tcp/localhost/9
# locked up in ~30 mins. Output in bug3.txt
$ find raid5 -xdev | cpio -oHnewc > /dev/tcp/linuxbox/9
# locked up in 15 mins. md0 is the raid5 drive. Output in bug4.txt
# This showed raid5 module and reiserfs were not part of the problem.
$ cat /dev/md0 > /dev/tcp/linuxbox/9
# ran to the end, md0 wasn't enabled. md1 is the onboard IDE based raid1
# `seq 0 26` is enough to tranfer 1.1TB of data.
$ for i in `seq 0 26` ; do cat /dev/md1 > /dev/tcp/linuxbox/9 ; done
# locked in 1 min. Output in bug5.txt
$ for i in `seq 0 26` ; do cat /dev/md1 > /dev/tcp/linuxbox/9 &
$ cat /dev/md0 > /dev/tcp/localhost/9
# locked in 150 mins. no raid5 module. Output in bug6.txt
$ for i in e g i k m o q s ; do cat /dev/hd${i}1 > /dev/tcp/linuxbox/9 ;
done
# locked in 7 hours. no raid5 module. Output in bug7.txt
$ for i in e g i k m o q s ; do cat /dev/hd${i}1 > /dev/udp/linuxbox/9 ;
done
# test onboard LAN, 100meg forcedeth module. Fine for 8 hours (approx
320gig transfered)
$ for i in g i k m o q s e ; do cat /dev/hd${i}1 > /dev/tcp/linuxbox/9 ;
done &
$ for i in e g i k m o q s ; do cat /dev/hd${i}1 > /dev/tcp/linuxbox/9 ;
done
# test r8169+NAPI at 100 meg. Locked in 110 mins. Output in bug8.txt
$ for i in g i k m o q s e ; do cat /dev/hd${i}1 > /dev/tcp/linuxbox/9 ;
done &
$ for i in e g i k m o q s ; do cat /dev/hd${i}1 > /dev/tcp/linuxbox/9 ;
done
# test r8169 at gigabit, with RX polling option disabled.
# Ran for 9 hours, so we have the winner. But why the NAPI interaction
problem with it821x and not ITE?
$ for i in g i k m o q s e ; do cat /dev/hd${i}1 > /dev/tcp/linuxbox/9 ;
done &
$ for i in e g i k m o q s ; do cat /dev/hd${i}1 > /dev/tcp/linuxbox/9 ;
done &
# Again without NAPI. Ran to the end.
$ cat /dev/md0 > /dev/tcp/linuxbox/9
These tests were done a few days ago, the system has been stable with
r8169(without NAPI) and it821x.
Am willing to test patches,
Richard
^ permalink raw reply
* Compensation for you,(From Mr Willims Karls)
From: Mr William Karls @ 2006-05-09 16:02 UTC (permalink / raw)
Dear Friend
I'm happy to inform you about my success in getting the fund
transferred under the cooperation of a new partner from South Korea.
You might find it so difficult to remember me. Though, it is indeed, a
very long time. On my singular, I am much delighted and privileged to
contact you again, after couple of months now.
Presently i'm in Seoul for an investment projects with my own share of
the total sum.meanwhile,i didn't forget your past efforts and attempts to assist
me in transferring those funds despite that it failed us some how.
Now contact my Secretary Mr Kennedy Agumefa his email address is
kennedy_Agumefa@yahoo.fr ask him to send you the total sum of $500.000.00 in a
Certificate Bank Draft which I kept for your compensation for all the past
efforts and attempts to assist me in this matter. I appreciated your efforts at
that time very much. so feel free and get in touched with my Secretry Mr Kennedy
Agumefa and instruct him where to send the amount to you.Please do let me know
immediately you receive it so that we can share the joy after all the
sufferness at that time. in the moment, i am very busy here because of the
investment projects which me and the new partner are having at hand,
finally, remember that I had forwarded instruction to the secretary on your
behalf to receive the Cheque, so feel free to get in touch with Secretry Mr
Kennedy Agumefa and he will send the amount to you without any delay.
Your Friend
Mr Williams Karls
^ permalink raw reply
* Re: [RFC] SECMARK 1.0
From: James Morris @ 2006-05-09 16:40 UTC (permalink / raw)
To: Karl MacMillan
Cc: Joshua Brindle, selinux, netdev, netfilter-devel, Stephen Smalley,
Daniel J Walsh
In-Reply-To: <1147181085.32719.105.camel@jackjack.columbia.tresys.com>
On Tue, 9 May 2006, Karl MacMillan wrote:
> those connection, but my concern is that connection could, through error
> or exploit, be passed to another domain that should not receive packets
> from that type of connection (see below).
Connection passing or inheritence should be subject to kernel MAC controls
anyway (also see below).
> The use of a single related packet type loses the strong binding between
> the connection type (determined on connection) and domains, most likely
> because an established connection is passed to another process.
>
> For example, for xinetd to work all of the xinetd children would be
> allowed to receive all related packets (i.e., tracked_packet_t). This
> means that if xinetd incorrectly passed, say, an ftp connection to
> telnet it would still be allowed to receive those packets because they
> would be of type tracked_packet_t. Labeling using something like
> connmark seems to solve this problem.
My understanding of xinetd is that it execs server applications, which
inherit the connection fd. In this case, flush_unauthorized_files() will
ensure that the new domain is authorized to access the fd.
Stephen, can you confirm this?
> There may be other examples relating to enforcing data separation based
> on other connection information, like the network interface, but I
> haven't had a chance to work through those scenarios.
I'm not sure exactly what you mean here, but the idea of this scheme is
that you can create new types to represent arbitrary combinations of
security-relevant properites of a packet.
e.g. extif_ftp_packet_t for ftp packets over an external interface.
> Now you may be saying that it is not possible to determine with any
> assurance that a related packet is related to, for example, a connection
> that was initiated on the ftp port (and therefore given a different type
> - related_ftp_packet_t - fixing my xinetd example). If this is the case,
> your argument makes more sense to me.
This is not the case. The problem is adding a secmark field to the
connection tracking system, and then having to implement several rules for
each labeling intent. The conntrack is first labeled from the initial
packet, then tracked packets are labeled from the conntrack label. It's
ugly.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: r8169+NAPI soft lockup
From: Francois Romieu @ 2006-05-09 16:43 UTC (permalink / raw)
To: Richard Gregory; +Cc: netdev
In-Reply-To: <4460B8DC.9080105@liv.ac.uk>
Richard Gregory <R.Gregory@liverpool.ac.uk> :
> I'm seeing the crash below using 2.6.16.11 custom based on RedHat FC2.
> The main culprit being the r8169+NAPI module, although the it821x module
> (with noraid=1) seems to bring out the bug, maybe because it uses the
> same interrupt.
(lot of things to digest...)
Is netconsole enabled ?
--
Ueimor
^ permalink raw reply
* Re: [NET] linkwatch: Handle jiffies wrap-around
From: Stefan Rompf @ 2006-05-09 16:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev
In-Reply-To: <20060509112626.GA29361@gondor.apana.org.au>
Am Dienstag 09 Mai 2006 13:26 schrieb Herbert Xu:
> The test used in the linkwatch does not handle wrap-arounds correctly.
> Since the intention of the code is to eliminate bursts of messages we
> can afford to delay things up to a second.
looks good, the code generates only up to 1 second delay for one second every
49 days, avoiding 64bit operations. David, please prefer this patch over mine.
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Stefan Rompf <stefan@loplof.de>
^ permalink raw reply
* Re: [RFC] SECMARK 1.0
From: Stephen Smalley @ 2006-05-09 17:11 UTC (permalink / raw)
To: James Morris
Cc: Karl MacMillan, Joshua Brindle, selinux, netdev, netfilter-devel,
Daniel J Walsh
In-Reply-To: <Pine.LNX.4.64.0605091229190.25948@d.namei>
On Tue, 2006-05-09 at 12:40 -0400, James Morris wrote:
> On Tue, 9 May 2006, Karl MacMillan wrote:
>
> > those connection, but my concern is that connection could, through error
> > or exploit, be passed to another domain that should not receive packets
> > from that type of connection (see below).
>
> Connection passing or inheritence should be subject to kernel MAC controls
> anyway (also see below).
>
> > The use of a single related packet type loses the strong binding between
> > the connection type (determined on connection) and domains, most likely
> > because an established connection is passed to another process.
> >
> > For example, for xinetd to work all of the xinetd children would be
> > allowed to receive all related packets (i.e., tracked_packet_t). This
> > means that if xinetd incorrectly passed, say, an ftp connection to
> > telnet it would still be allowed to receive those packets because they
> > would be of type tracked_packet_t. Labeling using something like
> > connmark seems to solve this problem.
>
> My understanding of xinetd is that it execs server applications, which
> inherit the connection fd. In this case, flush_unauthorized_files() will
> ensure that the new domain is authorized to access the fd.
>
> Stephen, can you confirm this?
That doesn't help, as that is just a check based on the socket label,
which will always be based on xinetd's label and won't reflect anything
about the individual connection.
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: [RFC] SECMARK 1.0
From: Karl MacMillan @ 2006-05-09 17:06 UTC (permalink / raw)
To: James Morris
Cc: Joshua Brindle, selinux, netdev, netfilter-devel, Stephen Smalley,
Daniel J Walsh
In-Reply-To: <Pine.LNX.4.64.0605091229190.25948@d.namei>
On Tue, 2006-05-09 at 12:40 -0400, James Morris wrote:
> On Tue, 9 May 2006, Karl MacMillan wrote:
>
> > those connection, but my concern is that connection could, through error
> > or exploit, be passed to another domain that should not receive packets
> > from that type of connection (see below).
>
> Connection passing or inheritence should be subject to kernel MAC controls
> anyway (also see below).
>
It is, but with no differentiation to how the connection was initially
established (continue to see below).
> > The use of a single related packet type loses the strong binding between
> > the connection type (determined on connection) and domains, most likely
> > because an established connection is passed to another process.
> >
> > For example, for xinetd to work all of the xinetd children would be
> > allowed to receive all related packets (i.e., tracked_packet_t). This
> > means that if xinetd incorrectly passed, say, an ftp connection to
> > telnet it would still be allowed to receive those packets because they
> > would be of type tracked_packet_t. Labeling using something like
> > connmark seems to solve this problem.
>
> My understanding of xinetd is that it execs server applications, which
> inherit the connection fd. In this case, flush_unauthorized_files() will
> ensure that the new domain is authorized to access the fd.
>
> Stephen, can you confirm this?
>
It doesn't matter whether the fd is inherited or passed over a unix
domain socket, the problem is the same. The fd and the underlying socket
will have the type of the creating process. So, yes there is control but
there is no differentiation; either a child can inherit/receive the
existing connection from xinetd or it cannot, regardless of how the
connection was initiated.
Another way of looking at this is that if a single type is used for all
related packets the network controls that we can place on, for example,
ftpd depend on whether it listens directly to the ftp port or it runs
through xinetd. This seems unfortunate.
> > There may be other examples relating to enforcing data separation based
> > on other connection information, like the network interface, but I
> > haven't had a chance to work through those scenarios.
>
> I'm not sure exactly what you mean here, but the idea of this scheme is
> that you can create new types to represent arbitrary combinations of
> security-relevant properites of a packet.
>
> e.g. extif_ftp_packet_t for ftp packets over an external interface.
>
Right, I understand that, but it seems that much of that granularity is
lost when connection tracking is used.
For example, if we have a xinetd execute the ftp daemon in different
domains based on the network interface, originating ip address, etc.
(presumably for confidentiality reasons). With the single related packet
type we must completely trust xinetd to pass the correct connections to
the ftp daemon in the correct domain: the related packets that the ftpd
will be the same regardless of whether the initial packets where
extif_ftp_packet_t or intern_ftp_packet_t.
If the security context of the related packets is the same as the
packets for the connection establishment we no longer have to trust
xinetd.
> > Now you may be saying that it is not possible to determine with any
> > assurance that a related packet is related to, for example, a connection
> > that was initiated on the ftp port (and therefore given a different type
> > - related_ftp_packet_t - fixing my xinetd example). If this is the case,
> > your argument makes more sense to me.
>
> This is not the case. The problem is adding a secmark field to the
> connection tracking system, and then having to implement several rules for
> each labeling intent. The conntrack is first labeled from the initial
> packet, then tracked packets are labeled from the conntrack label. It's
> ugly.
>
Ok - I obviously don't have the expertise to judge how ugly the code to
do this is. It becomes a question of whether the feature is compelling
enough.
Karl
--
Karl MacMillan
Tresys Technology
www.tresys.com
>
> - James
^ permalink raw reply
* Re: tcp compound
From: Stephen Hemminger @ 2006-05-09 18:01 UTC (permalink / raw)
To: Angelo P. Castellani; +Cc: netdev
In-Reply-To: <8dd26e70605091039n2669c4b0ka19d28fa2d502398@mail.gmail.com>
On Tue, 9 May 2006 19:39:43 +0200
"Angelo P. Castellani" <angelo.castellani+lkml@gmail.com> wrote:
> I resend the file because I've sent an old (quite identical) copy
Moved discussion over to netdev mailing list..
Could you export symbols in tcp_vegas (and change config dependencies) to
allow code reuse rather than having to copy/paste everything from vegas?
^ permalink raw reply
* Re: [PATCH] TCP congestion module: add TCP-LP supporting for 2.6.16.14
From: Wong Edison @ 2006-05-09 18:08 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <3feffd230605062232m1b9a3951h6d21071cdacc890f@mail.gmail.com>
as this patch is use to add a new function but not bug fix
what can i help after i have submit it ??
as i have test it before
i can provide the data that i have tested out ;-)
^ permalink raw reply
* Re: r8169+NAPI soft lockup
From: Richard Gregory @ 2006-05-09 18:17 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20060509164335.GA807@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Richard Gregory <R.Gregory@liverpool.ac.uk> :
>
>>I'm seeing the crash below using 2.6.16.11 custom based on RedHat FC2.
>>The main culprit being the r8169+NAPI module, although the it821x module
>>(with noraid=1) seems to bring out the bug, maybe because it uses the
>>same interrupt.
>
>
> (lot of things to digest...)
>
> Is netconsole enabled ?
It can be. How much output do you need, a single soft lockup?
Richard
^ permalink raw reply
* Re: iproute2 git repository
From: Stephen Hemminger @ 2006-05-09 18:31 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <E1FdQki-0007gj-00@gondolin.me.apana.org.au>
On Tue, 09 May 2006 21:51:44 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Stephen Hemminger <shemminger@osdl.org> wrote:
> > I moved iproute2 out of CVS. New home is:
> > git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
>
> Thanks Stephen.
>
> BTW, how come there is a checked out tree sitting in that git directory?
fixed. stupid git
^ permalink raw reply
* Re: iproute2 git repository
From: Stefan Rompf @ 2006-05-09 18:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Herbert Xu, netdev
In-Reply-To: <20060509113115.4a838f26@localhost.localdomain>
Am Dienstag 09 Mai 2006 20:31 schrieb Stephen Hemminger:
> > > I moved iproute2 out of CVS. New home is:
>
> fixed. stupid git
maybe you should have kept CVS. *Ducks and runs* ;-)
Stefan
^ permalink raw reply
* Re: Associate on 'ifconfig up'
From: David Woodhouse @ 2006-05-09 18:53 UTC (permalink / raw)
To: Michael Buesch; +Cc: linville, bcm43xx-dev, netdev, Stephen Hemminger
In-Reply-To: <200605071506.06552.mb@bu3sch.de>
On Sun, 2006-05-07 at 15:06 +0200, Michael Buesch wrote:
> On Saturday 06 May 2006 20:24, David Woodhouse wrote:
> > On Fri, 2006-05-05 at 17:38 +0100, David Woodhouse wrote:
> > > I still need this hack to work around the fact that softmac doesn't
> > > attempt to associate when we bring the device up...
> >
> > It'd be quite good to get this fixed in 2.6.17 too. Otherwise, the
> > device doesn't manage to associate if you use the fairly common sequence
> > of iwconfig then dhclient.
> >
> > It's a bit of an evil hack and it should really be fixed in softmac --
> > but it's only moving an _existing_ hack from one place in the driver to
> > another.
> >
> > Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
>
> John, please try to push this before 2.6.17.
> Thanks.
This didn't make it into the tree that Linus just pulled?
--
dwmw2
^ permalink raw reply
* Re: dBm cutoff at -1dBm is too low
From: Jean Tourrilhes @ 2006-05-09 18:54 UTC (permalink / raw)
To: Pavel Roskin; +Cc: NetDev
In-Reply-To: <1147150495.4453.65.camel@dv>
On Tue, May 09, 2006 at 12:54:55AM -0400, Pavel Roskin wrote:
> On Mon, 2006-05-08 at 10:17 -0700, Jean Tourrilhes wrote:
> > > But shouldn't you trust the drivers using IW_QUAL_DBM, whether the value
> > > is positive or negative?
> >
> > You can't remove the test, making the rest pointeless. Old
> > style driver never used the flags, new style driver that don't report
> > dBm will never use the flags, and there is not way to dinstinguish
> > both, apart from the 'sign' of the value.
>
> I used "new style driver" as synonymous to the driver using IW_QUAL_DBM
> and "old style driver" as the one that doesn't use IW_QUAL_DBM.
>
> I don't think any drivers need to specify both dBm and non-dBm data for
> the same device.
>
> Drivers that give non-dBm data are already well served by wireless
> tools. They don't need to change.
>
> Drivers that give dBm data had to limit the data to avoid its
> misinterpretation as non-dBm data. Now IW_QUAL_DBM is supposed to free
> drivers from such checks. But it doesn't deliver its promise, because
> the data can still be misinterpreted, just is a different way. Namely,
> a strong signal (0dBm) can be interpreted as an incredibly weak signal
> (-256dBm). That's what I want to see fixed.
I hear you 100%. But, before removing the backward
compatibility for old style drivers, we need to make sure all of them
are gone. I don't plan to keep backward compatibility forever, but
just enough to cover the transition.
Technically, we can't make backward compatibility for old
driver and this proposal to work together, because of the test on the
sign. We need to pick one.
> One tricky case would be when the driver sets the max signal e.g. to 30
> and reports 35 (i.e. a positive value within the "reasonable" dBm
> range). I would probably prefer to show it as 30/30 rather than 35dBm,
> but the driver is nuts anyway, and I'm not really concerned about it to
> write an extra line of code.
Agreed.
> Regards,
> Pavel Roskin
Jean
^ 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