Re: tap(4): will it be more reasonable if it preserved UP/DOWN state, when closed?
On 04/01/2015 15:58, Yuri wrote: I am going to create the corresponding net.link.tap.down_on_close. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [oss-security] CVE Request : IPv6 Hop limit lowering via RA messages
On Fri, Apr 3, 2015 at 6:06 AM, Jim Thompson wrote: > have you considered that there might not be a relevant patch because > FreeBSD’s implementation isn’t affected? sys/netinet6/nd6_rtr.c 300 if (nd_ra->nd_ra_curhoplimit) 301 ndi->chlim = nd_ra->nd_ra_curhoplimit; The only "OUT" in that function I see are tests for: Not accepting RA hoplimit on current packet != 255 not link-local No extended ipv6 header Based on previous testing ( early March 2015), and reading of the source, I say that FreeBSD is vulnerable. Regards, D.S. Ljungmark > > Jim > >> On Apr 2, 2015, at 9:15 PM, Eitan Adler wrote: >> >> + FreeBSD lists since I haven't seen any relevant patches (although I >> might have missed them). >> >> -- Forwarded message -- >> From: D.S. Ljungmark >> Date: 2 April 2015 at 10:19 >> Subject: [oss-security] CVE Request : IPv6 Hop limit lowering via RA messages >> To: oss-secur...@lists.openwall.com >> >> >> An unprivileged user on a local network can use IPv6 Neighbour >> Discovery ICMP to broadcast a non-route with a low hop limit, this >> causing machines to lower the hop limit on existing IPv6 routes. >> >> Linux Patch: http://www.spinics.net/lists/netdev/msg322361.html >> Redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1203712 >> >> Projects impacted: Linux kernel, NetworkManager, FreeBSD Kernel >> >> >> Regards, >> D.S. Ljungmark >> >> >> -- >> Eitan Adler >> ___ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [oss-security] CVE Request : IPv6 Hop limit lowering via RA messages
On Fri, Apr 3, 2015 at 1:54 PM, D.S. Ljungmark wrote: > On Fri, Apr 3, 2015 at 6:06 AM, Jim Thompson wrote: >> have you considered that there might not be a relevant patch because >> FreeBSD’s implementation isn’t affected? > > sys/netinet6/nd6_rtr.c > > 300 if (nd_ra->nd_ra_curhoplimit) > 301 ndi->chlim = nd_ra->nd_ra_curhoplimit; > > The only "OUT" in that function I see are tests for: > Not accepting RA > hoplimit on current packet != 255 > not link-local > No extended ipv6 header It is vulnerable. Harrison Grundy and I worked on a patch, and sent it to secteam@. > > > Based on previous testing ( early March 2015), and reading of the > source, I say that FreeBSD is vulnerable. > > > Regards, > D.S. Ljungmark > > >> >> Jim >> >>> On Apr 2, 2015, at 9:15 PM, Eitan Adler wrote: >>> >>> + FreeBSD lists since I haven't seen any relevant patches (although I >>> might have missed them). >>> >>> -- Forwarded message -- >>> From: D.S. Ljungmark >>> Date: 2 April 2015 at 10:19 >>> Subject: [oss-security] CVE Request : IPv6 Hop limit lowering via RA >>> messages >>> To: oss-secur...@lists.openwall.com >>> >>> >>> An unprivileged user on a local network can use IPv6 Neighbour >>> Discovery ICMP to broadcast a non-route with a low hop limit, this >>> causing machines to lower the hop limit on existing IPv6 routes. >>> >>> Linux Patch: http://www.spinics.net/lists/netdev/msg322361.html >>> Redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1203712 >>> >>> Projects impacted: Linux kernel, NetworkManager, FreeBSD Kernel >>> >>> >>> Regards, >>> D.S. Ljungmark >>> >>> >>> -- >>> Eitan Adler >>> ___ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: opaque ifnet progress
Anuranjan, On Fri, Apr 03, 2015 at 01:42:49AM +, Anuranjan Shukla wrote: A> Hello Gleb, A> Thanks for sharing the details. A> From looking at the wiki page it's not exactly clear what your plan is A> regarding the accessor functions as they stand today (if_get*/if_set* A> after drvapi change was made). I briefly glanced through some of the code A> changes but that takes time so it'd be good to know sort of the overall A> plan in that area if you foresee major rework. The plan is that they go away. They were a quick solution, that allow to avoid recompilation of a driver when struct ifnet change, but they still dictate the layout of the structure and don't give enough flexibility for the stacj to change in future. Also, new world order dictates that all change to flags/capenable/etc go directly through if_ioctl, so that we have one place to catch all events. Field accessor functions violate this rule. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ng_netgraph and BGP
On Wed, Apr 01, 2015 at 11:50:48AM +0100, William Waites wrote: W> I run a small network composed of even smaller networks each W> encapsulated in an autonomous system. I'd like to do traffic W> accounting using netflow aggregated by ASN. My border routers run W> FreeBSD and BIRD. W> W> Right now, and this is mentioned in ng_netflow(4), we do not fill in W> the source and destination ASN because there is no information to get W> this from the routing daemon's RIB. Probably if we come up with such a W> way it should be generic so it could be used by Quagga, BIRD or W> OpenBGPD. W> W> I've done a little bit of thinking about how this could be done, and W> come up with two main strategies: W> W> 1. A new kind of netgraph node inserted before ng_netflow knows how W> to query the routing daemon and decorates the packet with the W> result, which ng_netflow then puts into the flow packet if W> present. This entails either a copy (tee) or putting the lookup W> in the data path which may be suboptimal. W> W> 2. A new hook added to the ng_netflow node that allows it to query W> the routing daemon through a different new kind of netgraph W> node. This is probably better but may be slightly more W> complicated to implement. W> W> Is anyone working on this or has given this though? I wasn't able to W> find much by searching the list archives. It may be that I will soon W> have some students that I can set on this task but would not like to W> unnecessarily duplicate effort. The issue is open since I've written the ng_netflow node. You would agree that keeping the ASN information in kernel, just for the sake of exporting it out, is rather strange. Anyway, in 2004 I've written a patch to ng_netflow, rtsock and quagga to do that. But it didn't went into FreeBSD for the above reasons. Also, it required changing the rtsock API. You may try to search for the patch in internet archives. But the proper solution, I think, is to do prefix -> ASN matching at the collector. Or, if you cannot modify the collector, you can create a proxy collector that is feeded data from ng_netflow and resends it to collector with ASN filled in. You can put the proxy on the machine that runs either ng_netflow, or the collector. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Programmatically Creating VLAN in the Kernel
On Mon, Mar 30, 2015 at 09:49:56AM -0400, Juan Mojica wrote: J> I'm trying to programmatically create a VLAN in the kernel via ifioctl, but J> I'm hitting a "copyin" in the ioctl path, and since the address I'm passing J> in is a kernel address and not a user space address, the copyin is failing. J> J> Calling the ioctl from user space is a non-starter at this point, and I J> believe there will be other ioctls that will have to be called from the J> kernel which will hit the same issue. J> J> Any suggestions? J> J> So far I've thought about marking the ifreq flags to indicate the request J> came from the kernel and essentially bypass the copyin. Another option J> would be to make the create functions globally available, but this would J> violate the modularity of the VLAN module. If you really want to do that you need to export the vlan_cloner and its methods, then call vlan_clone_create directly. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Full 32bit flowid from igb(4)
On 03/31/15 at 11:15P, Adrian Chadd wrote: > Yeah, I think the right thing to do is: > > * If the descriptor says it's RSS, then use the flowid + rss type So, if we have multiqueue, we do everything needed to get RSS flowid/type. That means, with num_queues > 1 we can just expose those. > * else, set it to queue id and set the type to opaque. This part becomes irrelevant as it's a single queue case. Do we care about setting flowid value/type in case of single queue? cheers, Hiren pgpNRHMywGhNK.pgp Description: PGP signature
Re: Full 32bit flowid from igb(4)
On 3 April 2015 at 09:54, hiren panchasara wrote: > On 03/31/15 at 11:15P, Adrian Chadd wrote: >> Yeah, I think the right thing to do is: >> >> * If the descriptor says it's RSS, then use the flowid + rss type > So, if we have multiqueue, we do everything needed to get RSS > flowid/type. That means, with num_queues > 1 we can just expose those. > >> * else, set it to queue id and set the type to opaque. > > This part becomes irrelevant as it's a single queue case. Do we care > about setting flowid value/type in case of single queue? My whole point with not always setting it is that people may do things to /other/ parts of the driver and suddenly the RSS field isn't the RSS field anymore. Doubly so if you start playing with multiqueue + flowdirector on ixgbe. :) So I'd rather the driver be right and correct - checking if the field /is/ RSS and only setting the flowid+flowtype /if/ the value in that register is an RSS flowid, rather than setting it to whatever's there and hoping it's an RSS value. :) -adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Full 32bit flowid from igb(4)
On 04/03/15 at 10:00P, Adrian Chadd wrote: > On 3 April 2015 at 09:54, hiren panchasara wrote: > > On 03/31/15 at 11:15P, Adrian Chadd wrote: > >> Yeah, I think the right thing to do is: > >> > >> * If the descriptor says it's RSS, then use the flowid + rss type > > So, if we have multiqueue, we do everything needed to get RSS > > flowid/type. That means, with num_queues > 1 we can just expose those. > > > >> * else, set it to queue id and set the type to opaque. > > > > This part becomes irrelevant as it's a single queue case. Do we care > > about setting flowid value/type in case of single queue? > > My whole point with not always setting it is that people may do things > to /other/ parts of the driver and suddenly the RSS field isn't the > RSS field anymore. > > Doubly so if you start playing with multiqueue + flowdirector on ixgbe. :) > > So I'd rather the driver be right and correct - checking if the field > /is/ RSS and only setting the flowid+flowtype /if/ the value in that > register is an RSS flowid, rather than setting it to whatever's there > and hoping it's an RSS value. :) Okay, I guess it doesn't hurt to read those registers again at the time of actually assigning flowid/type. I'll do that and post a review on phabricator. Cheers, Hiren pgp2yAuVBPKk0.pgp Description: PGP signature
Re: Full 32bit flowid from igb(4)
On 3 April 2015 at 10:02, hiren panchasara wrote: > On 04/03/15 at 10:00P, Adrian Chadd wrote: >> On 3 April 2015 at 09:54, hiren panchasara >> wrote: >> > On 03/31/15 at 11:15P, Adrian Chadd wrote: >> >> Yeah, I think the right thing to do is: >> >> >> >> * If the descriptor says it's RSS, then use the flowid + rss type >> > So, if we have multiqueue, we do everything needed to get RSS >> > flowid/type. That means, with num_queues > 1 we can just expose those. >> > >> >> * else, set it to queue id and set the type to opaque. >> > >> > This part becomes irrelevant as it's a single queue case. Do we care >> > about setting flowid value/type in case of single queue? >> >> My whole point with not always setting it is that people may do things >> to /other/ parts of the driver and suddenly the RSS field isn't the >> RSS field anymore. >> >> Doubly so if you start playing with multiqueue + flowdirector on ixgbe. :) >> >> So I'd rather the driver be right and correct - checking if the field >> /is/ RSS and only setting the flowid+flowtype /if/ the value in that >> register is an RSS flowid, rather than setting it to whatever's there >> and hoping it's an RSS value. :) > > Okay, I guess it doesn't hurt to read those registers again at the time > of actually assigning flowid/type. I'll do that and post a review on > phabricator. Well, the "Is this RSS flowid" bits are in the RX descriptor, so you don't have to worry about reading registers. :) -adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Patch to reduce use of global IP ID value(s) to avoid leaking information
Hi, Moving this discussion away from the committers list, like requested by Gorge N. On 04/03/15 17:14, Gleb Smirnoff wrote:>Hans, > > What the hell? At Fri, 3 Apr 2015 15:41:21 +0300 (MSK) you ask: An expression like that requires a good answer. I've pulled together some parts and pieces from some existing code to make a test application showing the problem. Maybe when you hear the problem with your own ears, you will get it. Setup: I'm running 11-current prior to Gleb's IP ID commits. Possibly Gleb's IP ID commits won't change much. This little crude application I've called "pingphone" almost allows you to speak PCM audio through ICMP packets with zero payload. You need a computer with a sound card that can handle 8KHz PCM which plays through the default /dev/dsp ! Set the default audio adapter using: sysctl hw.snd.default_unit=XXX Also make sure that "kern.hz" is set to 1000 or 8000 and not 100. Else change it and reboot. fetch http://home.selasky.org:8192/privat/pingphone/pingphone.c Or try this if the above fails: fetch http://home.selasky.org/privat/pingphone/pingphone.c Compile it: cc -Wall pingphone.c Let me know if it doesn't compile. Start the ping recorder on localhost (IPv4): ./a.out -m 1 -T 127.0.0.1 Start audio producer on localhost: ./a.out -m 0 -T 127.0.0.1 Stop audio producer on localhost. Start the audio producer from another box so that the traffic goes accross a real network. Maybe inside a jail too? ./a.out -m 0 -T 192.168.x.x Still don't understand what the problem is? Should I make it play some Beethoven piece perhaps ;-) When you're done you maybe want to restore the ICMP limit back to the default: sysctl net.inet.icmp.icmplim=200 What's stated in: https://svnweb.freebsd.org/changeset/base/281024 Is correct. I see no technical reason to pull that out. For the future I've made a new project branch called "hps_head" where I will do development for sys/net/ sys/netinet and sys/netinet6 if I need. Gleb and Robert: You will have -current all to yourself and I hope to not receive any further angry comments from you regarding the issues that appeared this easter. Thank you for the attention. --HPS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Patch to reduce use of global IP ID value(s) to avoid leaking information
Hans, On Fri, Apr 03, 2015 at 11:16:58PM +0200, Hans Petter Selasky wrote: H> > What the hell? At Fri, 3 Apr 2015 15:41:21 +0300 (MSK) you ask: H> H> An expression like that requires a good answer. I've pulled together H> some parts and pieces from some existing code to make a test application H> showing the problem. Maybe when you hear the problem with your own ears, H> you will get it. H> H> Setup: H> H> I'm running 11-current prior to Gleb's IP ID commits. Possibly Gleb's IP H> ID commits won't change much. H> H> This little crude application I've called "pingphone" almost allows you H> to speak PCM audio through ICMP packets with zero payload. ... Thanks for a nice hack, I'll look at it :) H> What's stated in: H> H> https://svnweb.freebsd.org/changeset/base/281024 H> H> Is correct. I see no technical reason to pull that out. Hans, no one argued with you, that there is a covert channel. Yes there is one! And there are dozens of other covert channels in TCP/IP. But our manual pages are not an essays on hacking the Internet, however. The point of the manual pages is to provide documentation on knobs and switches. The point of the manual pages is not to describe funny stuff you can achieve turning the knobs on or off. The documentation on net.inet.ip.random_id is solid and doesn't need the text from your commit. If you don't agree with me, let's ask opinion of Mike Silbersack, the author of the random IP ID code. What does he things on manual page diff? P.S. Let me notice again, that you give 1 hour and 40 minutes for review. Why so impatient? The paragraph was sitting there without modification for a decade. Can it wait for at least a day? -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Patch to reduce use of global IP ID value(s) to avoid leaking information
On 04/03/15 23:36, Gleb Smirnoff wrote: If you don't agree with me, let's ask opinion of Mike Silbersack, the author of the random IP ID code. What does he things on manual page diff? Hi Gleb, Feel free to modify or update that text. Sure we could ask Mike Silbersack for advice about this one. P.S. Let me notice again, that you give 1 hour and 40 minutes for review. Why so impatient? The paragraph was sitting there without modification for a decade. Can it wait for at least a day? Let's talk this over at the coming BSD conference(s) face to face. I'm fine using "hps_head" for committing stuff that is not directly USB related. --HPS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
