Re: [take19 0/4] kevent: Generic event handling mechanism.
On 9/22/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: The only two things missed in patchset after his suggestions are new POSIX-like interface, which I personally consider as very unconvenient, This means you really do not know at all what this is about. We already have these interfaces. Several of them and there will likely be more. These are interfaces for functionality which needs the new event notification. There is *NO* reason whatsoever to not make this - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take19 0/4] kevent: Generic event handling mechanism.
[Bah, sent too eaqrly] On 9/22/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: The only two things missed in patchset after his suggestions are new POSIX-like interface, which I personally consider as very unconvenient, This means you really do not know at all what this is about. We already have these interfaces. Several of them and there will likely be more. These are interfaces for functionality which needs the new event notification. There is *NO* reason whatsoever to not make add this extension and instead invent new interfaces to have notification sent to the event queue. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take19 0/4] kevent: Generic event handling mechanism.
On Tue, Oct 03, 2006 at 11:09:15PM -0700, Ulrich Drepper ([EMAIL PROTECTED]) wrote: On 9/22/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: The only two things missed in patchset after his suggestions are new POSIX-like interface, which I personally consider as very unconvenient, This means you really do not know at all what this is about. We already have these interfaces. Several of them and there will likely be more. These are interfaces for functionality which needs the new event notification. There is *NO* reason whatsoever to not make this It looks I'm a bit puzzled... Let me clarify my position about it. Kevent as a generic event handling mechanism should not knwo about how events were added. It was designed to be quite flexible, so one could add events from essentially any possible situation. One of the most common situations is userspace requests - they are added through set of created syscalls. There can exists tons of quadrillions of any other interfaces, I even specially created helper function for kernel subsystems (existing and new ones) which might want to create events using own syscalls and parameters. For example network AIO work that way - it has own syscalls, which parses parameters, creates ukevent structure and pass them into kevent core, which in turn calls appropriate callbacks back to network AIO. Everyone can add new interfaces in any way he likes, it would quite silly to created new subsystem which would required strick API and failed to work with different set of interfaces. So from my point of view, problem is not in case that 'we need only this API', but 'why new API is better that old one'. It is possible to create new API, which will add events from _existing_ syscalls, it is just one function call from given syscall, I completely agree with it. I'm just objecting against removing existing interface in favour of new one. People who need POSIX timer API - feel free to call kevent_user_add_ukevent() from your favorite posix_timer_create(). Who needs signal queueing can do it even in signal() syscall - kevent callback for that subsystem for example can update process' signal mask and add kevents. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take19 0/4] kevent: Generic event handling mechanism.
On Tue, Oct 03, 2006 at 11:10:51PM -0700, Ulrich Drepper ([EMAIL PROTECTED]) wrote: [Bah, sent too eaqrly] On 9/22/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: The only two things missed in patchset after his suggestions are new POSIX-like interface, which I personally consider as very unconvenient, This means you really do not know at all what this is about. We already have these interfaces. Several of them and there will likely be more. These are interfaces for functionality which needs the new event notification. There is *NO* reason whatsoever to not make add this extension and instead invent new interfaces to have notification sent to the event queue. As I described in previous e-mail, there are completely _no_ limitations on iterfaces - it is possible to queue events from any place, not matter if it is new interface (which I prefer to use) or any old one, which is more convenient for someone. There is special herlper function for that. One can check network AIO implementation to see how it was done in practice - network AIO has own syscalls (aio_send(), aio_recv() and aio_sendfile(), which create kevent queue and put there own events, it is completely transparent for userspace which does not even know that network AIO is based on kevent). -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take19 1/4] kevent: Core files.
On 9/20/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: This patch includes core kevent files: [...] I tried to look at the example programs before and failed. I tried again. Where can I find up-to-date example code? Some other points: - I really would prefer not to rush all this into the upstream kernel. The main problem is that the ring buffer interface is a shared data structure. These are always tricky. We need to find the right combination between size (as small as possible) and supporting all the interfaces. - so far only the timer and aio notification is speced out. What about the rest? Are we sure all aspects can be expressed? I am not yet. - we need an interface to add an event from userlevel. I.e., we need to be able to synthesize events. There are events (like, for instance the async DNS functionality) which come from userlevel code. I would very much prefer we look at the other events before setting the data structures in stone. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take19 1/4] kevent: Core files.
On Tue, Oct 03, 2006 at 11:34:02PM -0700, Ulrich Drepper ([EMAIL PROTECTED]) wrote: On 9/20/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: This patch includes core kevent files: [...] I tried to look at the example programs before and failed. I tried again. Where can I find up-to-date example code? http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c http://tservice.net.ru/~s0mbre/archive/kevent/evtest.c Structures were not changed from the beginning of kevent project. Some other points: - I really would prefer not to rush all this into the upstream kernel. The main problem is that the ring buffer interface is a shared data structure. These are always tricky. We need to find the right combination between size (as small as possible) and supporting all the interfaces. mmap interface itself is in question, since it allows to create dos since there are no rlimits for pinned memory. - so far only the timer and aio notification is speced out. What about the rest? Are we sure all aspects can be expressed? I am not yet. AIO was removed from patchset by request of Cristoph. Timers, network AIO, fs AIO, socket nortifications and poll/select events work well with existing structures. - we need an interface to add an event from userlevel. I.e., we need to be able to synthesize events. There are events (like, for instance the async DNS functionality) which come from userlevel code. I would very much prefer we look at the other events before setting the data structures in stone. Signals and userspace events (hello solaris) easily fits into existing structures. It is even possible to create variable sized kevents - each kevent contain pointer to user's data, which can be considered as pointer to additional area (it's size kernel implementation for given kevent type can determine from other parameters or use predefined one and fetch additional data in -enqueue() callback). -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XFRM BEET mode and 2.6.19 kernel
From: Miika Komu [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 10:19:06 +0300 (EEST) Hi folks, I hope you will consider the BEET mode IPsec patch for the 2.6.19 kernel: http://www.mail-archive.com/netdev@vger.kernel.org/msg22333.html We have refactored the patch several times according to feedback from Herbert Xu during the past year. I've applied this and will push it along. Thanks a lot. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Customizable TCP backoff patch
From: Ben Woodard [EMAIL PROTECTED]
Date: Tue, 03 Oct 2006 11:14:38 -0700
Other issues:
1) 2 u32 in the tcp_sock is a lot of space to devote to this
new state. If it can fit in 2 u16's or even less space,
please use that.
2) the expression (tp-foo ? : sysctl_foo) is repeated many times
in the patch, please encapsulate it into an inline function
or similar
How does this look to you for answering your two complaints above.
It looks a lot better. I'd like you to take #2 further,
put the inline function into net/tcp.h and use it in the
tcp.c instances too.
Also, please don't format code like this:
+static inline __u16 rto_max(struct tcp_sock *tp){
+return tp-rto_max ? : sysctl_tcp_rto_max;
+}
+
+static inline __u16 rto_init(struct tcp_sock *tp){
+return tp-rto_init ? : sysctl_tcp_rto_init;
+}
The openning brace of each functions belongs on a line by itself,
thanks.
Finally, I'm not so sure seconds is the best unit for the
socket option. In fact you use seconds as the unit for
the socket option and the sysctl is raw jiffies. That's
inconsistency is really problematic.
At the very least, seconds might not be fine enough granularity
for some circumstances. Heck, the default RTO_MIN is 1/5 of a
second. :-)
I also understand that going to milliseconds or microseconds would
make the size of the in-socket struct members an issue again. These
things are never easy are they? :-/
Any better ideas?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] cfg80211 and nl80211
On Mon, 2006-10-02 at 12:15 -0400, Dan Williams wrote: I'm not sure what you mean here. Do you really mean grab the current _cmdlist_? Because I'm not sure how grabbing the current configuration (using GET_CONFIG) would necessarily return the right set of options for the device. Also, what do you mean by is supposed to be complete then? Yeah, I was thinking GET_CONFIG would fill in all values that you can also set. But then again, if no SSID was ever set it can't fill in an SSID, so that's bogus. We'll need to add a command to return a bitmask of what parameters a card supports. On large problem we had with WPA was that there was _no_ way to tell whether or not a driver supported it. Trying a WPA-related ioctl() and hoping for the best is broken. On the one hand, there were users screaming that yes, Madwifi did in fact support WPA, but of course, there was no standard way of figuring that out and present it to the user in a sane manner. We need to have an _explicit_ list of stuff that driver does and does not support so that intelligent decisions can be made before and/or without touching stuff that might turn the radio on or mess up an existing configuration set by somebody else. Right. Though with WPA, that's likely going to be in a few special commands, so checking if the driver supports those commands (by getting the command list) ought to be enough, no? Does parameters here mean CMD or ATTR? ATTR. Unknown commands are rejected anyway right in the genetlink layer (afaik), the question was just whether to ignore or reject attributes we don't understand. In any case, there's a good case to be made for rejecting unsupported CMDs ATTRs. If the user, for example, wishes to restrict the roaming to a set of BSSIDs for security measures, for example (even if an insecure one), but the driver doesn't support that, should nl80211 just blindly pretend that it worked? This might also get people to fix up their drivers and userspace programs too. Good point. However, I'd think that such a feature could well have a new command like CMD_SET_RESTRICTED_BSSID_LIST with a BSSID_LIST attribute, and then the whole problem doesn't really happen since userspace will see when that command is not supported. I do realize there's an API extensibility benefit to ignoring stuff you don't handle though (like 802.11 information element handling). But if we're talking about an explicit request by a user for an option, if the driver doesn't support it, they should get an error. Yeah, though the whole stuff a bunch of options into SET_CONFIG isn't really where I'd like to be ideally, it's more that it is necessary to be able to restart firmware less. Hence, I think set_config is not very likely to be extended further, and new stuff gets new commands. That sounds like a good idea. Putting 802.11d handling stuff into the kernel would essentially be duplicating the code and function of the userspace regulatory daemon, right? That seems pointless. Probably. But also see James's answers and the short thread resulting from that. Another questions; I didn't see anything for encryption and auth and stuff yet. Are you just trying to get the basics down before going on to that stuff? Yes, I'm not that far yet. What do you still have on your ToDo list for nl80211 before you'd consider ready to take over real configuration functions? I don't really have an explicit ToDo list, but here are a few points that come to mind * notification support when parameters change multicast a netlink message to all subscribers of that group * transmit status notification support for packet injection (sort of ties in with the first point) * scan results (also somewhat related to the first point) * crypto and auth support + /* unconditionally allow some common commands we handle centrally */ + NLA_PUT_FLAG(msg, NL80211_CMD_GET_CMDLIST); + NLA_PUT_FLAG(msg, NL80211_CMD_GET_WIPHYS); + NLA_PUT_FLAG(msg, NL80211_CMD_GET_INTERFACES); + + CHECK_CMD(list_interfaces, GET_INTERFACES); Don't these two do exactly the same thing? The first one adds GET_INTERFACES unconditionally, the next adds it (again!) if the interface supports it. Either we add it unconditionally or we add it conditionally, but not both :) Heh, yeah, it should be added unconditionally since it's one of the very few calls that all operation structs must have assigned. Not that it hurts to have it in there twice ;) I think we need a GET_SCAN here as well. INITIATE_SCAN should definitely be CAP_NET_ADMIN-only or whatever, but GET_SCAN can be user-accessible. Non-root stuff should still be able to get scan results even if they can't initiate one. Yeah, we'll want that, but I haven't really thought about how we pass scan results to userspace. We could be passing them out whenever we see a change by way of some UPDATE_SCAN_RESULT command that is multicast to all subscribers of a scan results group,
Re: [take19 0/4] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: When we enter sys_ppoll() we specify needed signals as syscall parameter, with kevents we will add them into the queue. No, this is not sufficient as I said in the last mail. Why do you completely ignore what others say. The code which depends on the signal does not have to have access to the event queue. If a library sets up an interrupt handler then it expect the signal to be delivered this way. In such situations ppoll etc allow the signal to be generally blocked and enabled only and *ATOMICALLY* around the delays. This is not possible with the current wait interface. We need this signal mask interfaces and the appropriate setup code. Being able to get signal notifications does not mean this is always the way it can and must happen. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: [take19 0/4] kevent: Generic event handling mechanism.
On Wed, Oct 04, 2006 at 12:33:25AM -0700, Ulrich Drepper ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov wrote: When we enter sys_ppoll() we specify needed signals as syscall parameter, with kevents we will add them into the queue. No, this is not sufficient as I said in the last mail. Why do you completely ignore what others say. The code which depends on the signal does not have to have access to the event queue. If a library sets up an interrupt handler then it expect the signal to be delivered this way. In such situations ppoll etc allow the signal to be generally blocked and enabled only and *ATOMICALLY* around the delays. This is not possible with the current wait interface. We need this signal mask interfaces and the appropriate setup code. Being able to get signal notifications does not mean this is always the way it can and must happen. It is completely possible to do what you describe without special syscall parameters. Just add interesting signals to the queue (and optionally block them globally) and wait on that queue. When signal's event is generated and appropriate kevent is removed, that signal will be restored in global signal mask (there are appropriate enqueue/dequeue callbacks which can perform operations on signal mask for given process). My main consern is to not add special cases for something in generic code, especially when gneric code can easily handle that situations. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
are all protocol headers in the linear part of a sk_buff?
When a skb reaches a device driver for tx, can the driver assumes that all protocol headers (up to the tcp layer and including tcp options) are in the linear part of the skb, thus it can access them via skb-h.th? Or the answer depends on the linux kernel version? Thanks Ronghua - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wext
On Mon, 2006-10-02 at 19:55 +0200, [EMAIL PROTECTED] wrote: This patch (wext-patch) is a proposal. It adds two new defines for the SIOCSIWMLME to cover all kinds MLMEs (well, except REASSOC) through a ioctl. (it would be nice to have them, so that I can post the hostapd code for the prism54 card!) NACK from me. Please help me work on nl80211 instead :) johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Customizable TCP backoff patch
David Miller wrote: At the very least, seconds might not be fine enough granularity for some circumstances. Heck, the default RTO_MIN is 1/5 of a second. :-) I also understand that going to milliseconds or microseconds would make the size of the in-socket struct members an issue again. These things are never easy are they? :-/ Would be, if floating point values would be allowed. Single precision would be enough in this case and its just 32 bits IIRC. I mean floating point values just for the user-kernel ABI and NOT for the internal timer representation. Regards Ingo Oeser - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Customizable TCP backoff patch
From: Ingo Oeser [EMAIL PROTECTED] Date: Wed, 4 Oct 2006 10:56:12 +0200 David Miller wrote: At the very least, seconds might not be fine enough granularity for some circumstances. Heck, the default RTO_MIN is 1/5 of a second. :-) I also understand that going to milliseconds or microseconds would make the size of the in-socket struct members an issue again. These things are never easy are they? :-/ Would be, if floating point values would be allowed. Single precision would be enough in this case and its just 32 bits IIRC. I mean floating point values just for the user-kernel ABI and NOT for the internal timer representation. We got the struct members down to 16-bits each, the problem is in fact that we'd need to make them 32-bits again. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] network namespaces
Andrey Savochkin wrote: Hi All, I'd like to resurrect our discussion about network namespaces. In our previous discussions it appeared that we have rather polar concepts which seemed hard to reconcile. Now I have an idea how to look at all discussed concepts to enable everyone's usage scenario. Hi Andrey, I have a few questions ... sorry for asking so late ;) 1. The most straightforward concept is complete separation of namespaces, covering device list, routing tables, netfilter tables, socket hashes, and everything else. On input path, each packet is tagged with namespace right from the place where it appears from a device, and is processed by each layer in the context of this namespace. If you have the namespace where is coming the packet, why do you tag the packet instead of switching to the right namespace ? Non-root namespaces communicate with the outside world in two ways: by owning hardware devices, or receiving packets forwarded them by their parent namespace via pass-through device. Do you will do proxy arp and ip forwarding into the root namespace in order to make non-root namespace visible from the outside world ? Regards. -- Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prism54: wpa support for fullmac cards
On Tue, 3 Oct 2006 14:57:33 +0200, [EMAIL PROTECTED] wrote: This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card. I removed all the parts(e.g.: Hostapd Support) which are not relevant for wpa_supplicant (client/managed mode). Are you proposing a patch that removes AP support from the driver or did I understand it wrong? Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wext
On Wed, 2006-10-04 at 10:37, Johannes Berg [EMAIL PROTECTED] wrote: On Mon, 2006-10-02 at 19:55 +0200, [EMAIL PROTECTED] wrote: This patch (wext-patch) is a proposal. It adds two new defines for the SIOCSIWMLME to cover all kinds MLMEs (well, except REASSOC) through a ioctl. (it would be nice to have them, so that I can post the hostapd code for the prism54 card!) NACK from me. Please help me work on nl80211 instead :) johannes hmm... another month of fun. ;) no really, the problem is that my hardware (aka: prism54 fullmac) does all the mac-management, encryption/decryption, AP-Management,... in the firmware. And all management operation are wrapped into a simple unique 4-byte Operation ID... That's why the WEXT would be better for that thing... (Or, do I mix everything up and nl80211 has nothing to do with devicescape's networkstack d80211?) Chr - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wext
On Wed, 2006-10-04 at 12:56 +0200, [EMAIL PROTECTED] wrote: no really, the problem is that my hardware (aka: prism54 fullmac) does all the mac-management, encryption/decryption, AP-Management,... in the firmware. And all management operation are wrapped into a simple unique 4-byte Operation ID... That's why the WEXT would be better for that thing... (Or, do I mix everything up and nl80211 has nothing to do with devicescape's networkstack d80211?) Yes, nl80211 is not tied to d80211, it simply provides a new way of doing configuration. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prism54: wpa support for fullmac cards
On Wed, 2006-10-04 at 12:38 +0200, Jiri Benc wrote: On Tue, 3 Oct 2006 14:57:33 +0200, [EMAIL PROTECTED] wrote: This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card. I removed all the parts(e.g.: Hostapd Support) which are not relevant for wpa_supplicant (client/managed mode). Are you proposing a patch that removes AP support from the driver or did I understand it wrong? I believe it adds the support back in, just using standard WE ioctls like ENCODEEXT and AUTH rather than the custom HostAP ones... which brings up the question whether the hostapd driver for wext (is there such a thing?) works well enough. Dan Thanks, Jiri - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
On Wed, 4 Oct 2006, Evgeniy Polyakov wrote:
Linux kano 2.6.18 #5 SMP Mon Oct 2 18:44:30 MSD 2006 i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-2.3.17-2
I get only this messages in audit.log when remote racoon tries to
connect to system with selinux enabled in enforcing mode:
I think the policy has just not been written for racoon, and it's being
denied by deault (cd'd Dan Walsh).
type=AVC msg=audit(1159938297.845:625): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association
type=AVC msg=audit(1159938297.845:626): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938307.837:627): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938317.838:628): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938327.839:629): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
It is with your patch applied.
Should I try Venkat's or it is unrelated problem?
--
James Morris
[EMAIL PROTECTED]
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
On Tue, Oct 03, 2006 at 04:18:07PM -0700, David Miller wrote:
As I review this patch I realize there is a question of
semantics and prioritization here.
Indeed. Unfortunately I was doing other things at the time
sub-policies were introduced so I didn't pay attention to it.
After a quick look, it seems that the intention is to perform
some sort of recursive lookup (restricted to 2 levels only).
If that is the intention, perhaps we should try to come up
with a better mechansim because hard-coding a single level
of recursion for mobility is probably not the best solution
as this is just a special case of the general nested tunnel
problem.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
Evegeniy,
Please start with my patch which should actually address the issue
you were originally running into. I doubt that you were running into
the kind of errors that James' patch (which will need to be modified
to not treat -EACCES as an error to be propagated up the chain) would
handle.
Thanks,
venkat
-Original Message-
From: James Morris [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 8:00 AM
To: Evgeniy Polyakov
Cc: David S. Miller; Herbert Xu; netdev@vger.kernel.org; Stephen
Smalley; Venkat Yekkirala; Paul Moore; Daniel J Walsh
Subject: Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
On Wed, 4 Oct 2006, Evgeniy Polyakov wrote:
Linux kano 2.6.18 #5 SMP Mon Oct 2 18:44:30 MSD 2006 i686
i686 i386 GNU/Linux
[EMAIL PROTECTED] ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-2.3.17-2
I get only this messages in audit.log when remote racoon tries to
connect to system with selinux enabled in enforcing mode:
I think the policy has just not been written for racoon, and
it's being
denied by deault (cd'd Dan Walsh).
type=AVC msg=audit(1159938297.845:625): avc: denied {
polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association
type=AVC msg=audit(1159938297.845:626): avc: denied {
polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938307.837:627): avc: denied {
polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938317.838:628): avc: denied {
polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938327.839:629): avc: denied {
polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
It is with your patch applied.
Should I try Venkat's or it is unrelated problem?
--
James Morris
[EMAIL PROTECTED]
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prism54: wpa support for fullmac cards
On Wed, 4 Oct 2006 13:40 +0200 [EMAIL PROTECTED] wrote: On Wed, 2006-10-04 at 12:38 +0200, Jiri Benc wrote: On Tue, 3 Oct 2006 14:57:33 +0200, [EMAIL PROTECTED] wrote: This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card. I removed all the parts(e.g.: Hostapd Support) which are not relevant for wpa_supplicant (client/managed mode). Are you proposing a patch that removes AP support from the driver or did I understand it wrong? I believe it adds the support back in, just using standard WE ioctls like ENCODEEXT and AUTH rather than the custom HostAP ones... which brings up the question whether the hostapd driver for wext (is there such a thing?) works well enough. Dan the AP code never worked. And the hostapd-ioctl interface was designed for prism2/2.5/3 cards, but not for fullmac prism54. Because the fullmac prism54 card does everything(mac-, key- and station-management) in the firmware and the hostapd_param struct does neither support the necessary mlme requests/responses (Authentication Association frames) nor a param to handle the EAP filter for the stations. (I wrote a patch HostAPD support, but with it's own firmwareap_param struct and some other hacky things, but it works well. I can post a diff too, but be warned! ;) ) (BTW, hostapd's backend for prism54 uses a proprietary interface - PIMFOR -, which never made it into the kernel.) Chr. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] cfg80211 and nl80211
On Wed, 2006-10-04 at 09:41 +0200, Johannes Berg wrote: I don't really have an explicit ToDo list, but here are a few points that come to mind * notification support when parameters change multicast a netlink message to all subscribers of that group I think we'll want at least two groups here: - scan results - configuration changes can anyone think of more? NM might like to listen for config changes and scan events, but most tools won't be that much concerned about config changes... current wireless events are subsumed here as well. * transmit status notification support for packet injection (sort of ties in with the first point) This should be a matter of saving the socket id of the requesting nl80211 packet in the request structure, and having d80211/the driver keep track of it and pass it back with the tx status structure to an cfg80211_transmit_status(). Maybe a second cookie would be good too if we ever gain packet injection capabilities over something other than netlink. Thoughts? * scan results (also somewhat related to the first point) Should cfg80211 do the chore of keeping track of the whole scan results? On the other hand, that doesn't seem to be doable with legacy hardware that does all the scanning. So probably one call for cfg80211_notify_scan() that takes a new scan result structure (taking a single BSSID etc.) and notifies all listeners. The same structure is used for get_scan() from the wiphy ops in an iterator interface like some other calls. * crypto and auth support I really need someone to help me out with this one. So far I've seen that we have commands for * getting crypto capabilities (several orthogonal issues, crypto algorithms as well as auth algorithms as well as key management?) * setting keys for both rx and tx - up to 4 default keys - setting WPA key(s?) - setting sta pairwise key (AP) - setting group key (AP, same as for STA?) * setting the WPA IE(s) * authentication (WE sticks so much into that call that I can't pull it apart, what exactly is needed?) looks like it needs (sub)commands for - allowed wpa versions (why is this AUTH??) - setting pairwise and group ciphers (again.. AUTH??) - setting key management (again.. AUTH??) - authentication algorithm (whew, something that really is auth) - roaming control (haha, already covered) * more? johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] secid reconcialiation: Replace unlabeled_t with the network_t
Venkat Yekkirala wrote: The following replaces unlabeled_t with network_t for better characterization of the flow out/in checks in SELinux, as well as to allow for mls packets to flow out/in from the network since network_t would allow the full range of MLS labels, as opposed to the unlabeled init sid that only allows system-hi. Signed-off-by: Venkat Yekkirala [EMAIL PROTECTED] --- This is an incremental patch the secid-reconcilation v4 patchset. --- net-2.6.sid3/security/selinux/hooks.c 2006-10-01 15:43:12.0 -0500 +++ net-2.6/security/selinux/hooks.c 2006-10-03 16:43:21.0 -0500 @@ -3703,7 +3703,8 @@ static int selinux_skb_flow_in(struct sk err = selinux_xfrm_decode_session(skb, xfrm_sid, 0); BUG_ON(err); - err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET, + err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG, + SECCLASS_PACKET, PACKET__FLOW_IN, NULL); if (err) goto out; @@ -3900,7 +3901,7 @@ static unsigned int selinux_ip_postroute skb-secmark = sksec-sid; } } - err = avc_has_perm(skb-secmark, SECINITSID_UNLABELED, + err = avc_has_perm(skb-secmark, SECINITSID_NETMSG, SECCLASS_PACKET, PACKET__FLOW_OUT, ad); } out: Considering the above change, I wonder if it would also make sense to update the secmark to SECINITSID_UNLABELED in the abscence of any external labeling (labeled IPsec or NetLabel)? -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] secid reconcialiation: Replace unlabeled_t with the network_t
Paul Moore wrote: Venkat Yekkirala wrote: The following replaces unlabeled_t with network_t for better characterization of the flow out/in checks in SELinux, as well as to allow for mls packets to flow out/in from the network since network_t would allow the full range of MLS labels, as opposed to the unlabeled init sid that only allows system-hi. Signed-off-by: Venkat Yekkirala [EMAIL PROTECTED] --- This is an incremental patch the secid-reconcilation v4 patchset. --- net-2.6.sid3/security/selinux/hooks.c 2006-10-01 15:43:12.0 -0500 +++ net-2.6/security/selinux/hooks.c 2006-10-03 16:43:21.0 -0500 @@ -3703,7 +3703,8 @@ static int selinux_skb_flow_in(struct sk err = selinux_xfrm_decode_session(skb, xfrm_sid, 0); BUG_ON(err); - err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET, + err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG, + SECCLASS_PACKET, PACKET__FLOW_IN, NULL); if (err) goto out; @@ -3900,7 +3901,7 @@ static unsigned int selinux_ip_postroute skb-secmark = sksec-sid; } } - err = avc_has_perm(skb-secmark, SECINITSID_UNLABELED, + err = avc_has_perm(skb-secmark, SECINITSID_NETMSG, SECCLASS_PACKET, PACKET__FLOW_OUT, ad); } out: Considering the above change, I wonder if it would also make sense to update the secmark to SECINITSID_UNLABELED in the abscence of any external labeling (labeled IPsec or NetLabel)? Ungh, my apologies ... I meant to say SECINITSID_NETMSG *not* SECINITSID_UNLABELED. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] secid reconcialiation: Replace unlabeled_t with the network_t
On Wed, 2006-10-04 at 10:33 -0400, Paul Moore wrote: Venkat Yekkirala wrote: The following replaces unlabeled_t with network_t for better characterization of the flow out/in checks in SELinux, as well as to allow for mls packets to flow out/in from the network since network_t would allow the full range of MLS labels, as opposed to the unlabeled init sid that only allows system-hi. Signed-off-by: Venkat Yekkirala [EMAIL PROTECTED] --- This is an incremental patch the secid-reconcilation v4 patchset. --- net-2.6.sid3/security/selinux/hooks.c 2006-10-01 15:43:12.0 -0500 +++ net-2.6/security/selinux/hooks.c2006-10-03 16:43:21.0 -0500 @@ -3703,7 +3703,8 @@ static int selinux_skb_flow_in(struct sk err = selinux_xfrm_decode_session(skb, xfrm_sid, 0); BUG_ON(err); - err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET, + err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG, + SECCLASS_PACKET, PACKET__FLOW_IN, NULL); if (err) goto out; @@ -3900,7 +3901,7 @@ static unsigned int selinux_ip_postroute skb-secmark = sksec-sid; } } - err = avc_has_perm(skb-secmark, SECINITSID_UNLABELED, + err = avc_has_perm(skb-secmark, SECINITSID_NETMSG, SECCLASS_PACKET, PACKET__FLOW_OUT, ad); } out: Considering the above change, I wonder if it would also make sense to update the secmark to SECINITSID_UNLABELED in the abscence of any external labeling (labeled IPsec or NetLabel)? Wouldn't that make secmark useless in the non labeled networking case? -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] secid reconcialiation: Replace unlabeled_t with t he network_t
Considering the above change, I wonder if it would also make sense to update the secmark to SECINITSID_UNLABELED in the abscence of any external labeling (labeled IPsec or NetLabel)? Ungh, my apologies ... I meant to say SECINITSID_NETMSG *not* SECINITSID_UNLABELED. In the xfrm/NetLabel/semark case, you have configured (domain) labels that are meant to be carried by the skb. Whereas that's not the case with network_t. So, just a flow_in check was in order here. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] secid reconcialiation: Replace unlabeled_t with the network_t
Christopher J. PeBenito wrote: On Wed, 2006-10-04 at 10:33 -0400, Paul Moore wrote: Venkat Yekkirala wrote: The following replaces unlabeled_t with network_t for better characterization of the flow out/in checks in SELinux, as well as to allow for mls packets to flow out/in from the network since network_t would allow the full range of MLS labels, as opposed to the unlabeled init sid that only allows system-hi. Signed-off-by: Venkat Yekkirala [EMAIL PROTECTED] --- This is an incremental patch the secid-reconcilation v4 patchset. --- net-2.6.sid3/security/selinux/hooks.c2006-10-01 15:43:12.0 -0500 +++ net-2.6/security/selinux/hooks.c 2006-10-03 16:43:21.0 -0500 @@ -3703,7 +3703,8 @@ static int selinux_skb_flow_in(struct sk err = selinux_xfrm_decode_session(skb, xfrm_sid, 0); BUG_ON(err); -err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET, +err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG, +SECCLASS_PACKET, PACKET__FLOW_IN, NULL); if (err) goto out; @@ -3900,7 +3901,7 @@ static unsigned int selinux_ip_postroute skb-secmark = sksec-sid; } } -err = avc_has_perm(skb-secmark, SECINITSID_UNLABELED, +err = avc_has_perm(skb-secmark, SECINITSID_NETMSG, SECCLASS_PACKET, PACKET__FLOW_OUT, ad); } out: Considering the above change, I wonder if it would also make sense to update the secmark to SECINITSID_UNLABELED in the abscence of any external labeling (labeled IPsec or NetLabel)? Wouldn't that make secmark useless in the non labeled networking case? Sorry, I didn't do a very good job explaining things in my first email so let me try it again ... If there is no external labeling, i.e. labeled IPsec or NetLabel, *and* the secmark is equal to zero/SECSID_NULL I think it might be a good idea to set the secmark to SECINITSID_NETMSG. This not affect either local or external labels if they are present, but if both are not it would give the secmark some meaningful value. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Thu, 2006-09-28 at 14:01 -0700, Andrew Morton wrote:
On Thu, 28 Sep 2006 17:50:31 + (UTC)
Steve Fox [EMAIL PROTECTED] wrote:
On Thu, 28 Sep 2006 01:46:23 -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm2/
Panic on boot. This machine booted 2.6.18-mm1 fine. em64t machine.
TCP bic registered
TCP westwood registered
TCP htcp registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Unable to handle kernel paging request at RIP:
[8047ef93] packet_notifier+0x163/0x1a0
PGD 203027 PUD 2b031067 PMD 0
Oops: [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.18-mm2-autokern1 #1
RIP: 0010:[8047ef93] [8047ef93]
packet_notifier+0x163/0x1a0
RSP: :810bffcbde90 EFLAGS: 00010286
RAX: RBX: 810bff4a1000 RCX:
RDX: 810bff4a1000 RSI: 0005 RDI: 8055f5e0
RBP: R08: 7616 R09: 000e
R10: 0006 R11: 803373f0 R12:
R13: 0005 R14: 810bff4a1000 R15:
FS: () GS:805d8000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: CR3: 00201000 CR4: 06e0
Process swapper (pid: 1, threadinfo 810bffcbc000, task 810bffcbb510)
Stack: 810bff4a1000 8055f4c0 810bffcbdef0
8042736e
8061c68d 806260f0 80207182
Call Trace:
[8042736e] register_netdevice_notifier+0x3e/0x70
[8061c68d] packet_init+0x2d/0x53
[80207182] init+0x162/0x330
[8020a9d8] child_rip+0xa/0x12
[8033c2a2] acpi_ds_init_one_object+0x0/0x82
[80207020] init+0x0/0x330
[8020a9ce] child_rip+0x0/0x12
Code: 48 8b 45 00 0f 18 08 49 83 fd 02 4c 8d 65 f8 0f 84 f8 fe ff
RIP [8047ef93] packet_notifier+0x163/0x1a0
RSP 810bffcbde90
CR2:
0Kernel panic - not syncing: Attempted to kill init!
I'm really struggling to work out what went wrong there. Comparing your
miserable 20 bytes of code to my object code makes me think that this:
struct packet_sock *po = pkt_sk(sk);
returned -1, perhaps in %ebp. But it's all very crude.
Perhaps you could compile that kernel with CONFIG_DEBUG_INFO, rerun it (the
addresses might change) then have a poke around with `gdb vmlinux' (or
maybe just addr2line) to work out where it's really oopsing?
I don't see much which has changed in that area recently.
Sorry for the delay. I was finally able to perform a bisect on this. It
turns out the patch that causes this is
x86_64-mm-re-positioning-the-bss-segment.patch, which seems like a
strange candidate, but sure enough I can boot to login: right up until
that patch is applied.
P.S. I had to comment usb-hubc-build-fix.patch out of the series file
because it would not apply cleanly and caused quilt (0.45) to simply
abort its 'push' operation.
--
Steve Fox
IBM Linux Technology Center
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices
Jay Vosburgh wrote:
Or Gerlitz [EMAIL PROTECTED] wrote:
Sorry, but I don't follow... by saying would be ideal to do ***it*** this
way in all cases what exactly is the it you are referring to?
It refers to:
You almost want to have some kind of call to induce a reload
from scratch of the multicast filter settings (along with whatever else
might be necessary to alter the hardware type on the fly), to be called
by bonding at the time the first slave is added (since slave adds happen
in user context, and can therefore hold rtnl as required by most of the
multicast address handling code). That seems less hassle than having to
specify the hardware type and address length at module load time.
Having this would eliminate the need to specify the hardware
type at load time, and would allow changing of the hardware type at
enslave time, rather than at device up time. This requires fewer
changes to other things, like the initscripts or ifenslave.
The ideal would be to allow changing of hardware type at
literally any time, allowing failover across dissimilar hardware types.
That's a lot more complicated, and has a smaller pool of potential uses.
Thanks for the clarification. I would prefer first trying to go in the
direction you suggest below of changing the ifenslave program and the
kernel bonding code to allow for enslaving while the bonding device is
not UP.
1st, your current recommendation to solve the link layer address
computation of multicast groups joined by the stack before any enslavement
actually takes place, is to instrument the bonding code such that it would
be possible to enslave devices when the bonding device is not up yet.
2nd, the change need to be worked out in the bonding sysfs code, the
ifenslave program but ***also*** in packages such as /sbin/ifup and
friends.
Correct. The necessary changes to initscript and sysconfig are
probably the most complex piece to organize (not necessarily the hardest
to implement, but rather the most troublesome to deploy, as it
introduces an API change).
Looking on the sysconfig package, some tools eg /sbin/if{up,down,status}
use ifenslave which is in turn provided by the iputils package.
My understanding is that changing ifenslave and the bonding kernel code
to allow for enslaving while master is not up is enough, so actually no
change is needed to the sysconfig tools, correct?
I have now removed the two assertions in the bonding code on enslaving
while master is not up and manage to work fine with IPoIB slave devices
and ***without*** the two module params!
When you have the most troublesome to deploy, the troubles you refer to
is make sure that the distros would include ***both*** the bonding
kernel changes and use an iputils package which has the ifenslave changes?
Yes, ifenslave is still supported. It probably will be
obsoleted some day (or replaced with a script that uses sysfs), but not
anytime soon. As far as I know, all current distros use ifenslave to
configure bonding.
Cool, thanks for bringing this into my attention... I understand now my
patch set should also handle the ifenslave.c source that comes with the
kernel (eg to allow for not setting the hw address etc)
Or.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] NetLabel: secid reconciliation support
This patch provides the missing NetLabel support to the secid reconciliation
patchset.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
security/selinux/hooks.c| 104 +--
security/selinux/include/objsec.h |1
security/selinux/include/selinux_netlabel.h | 28 +++
security/selinux/ss/services.c | 106 ++--
4 files changed, 121 insertions(+), 118 deletions(-)
Index: net-2.6/security/selinux/hooks.c
===
--- net-2.6.orig/security/selinux/hooks.c
+++ net-2.6/security/selinux/hooks.c
@@ -3465,6 +3465,10 @@ static int selinux_sock_rcv_skb_compat(s
goto out;
}
+ err = selinux_netlbl_sock_rcv_skb(sock_sid, sock_class, skb, ad);
+ if (err)
+ goto out;
+
err = selinux_xfrm_sock_rcv_skb(sock_sid, skb, ad);
out:
@@ -3501,10 +3505,7 @@ static int selinux_socket_sock_rcv_skb(s
else
err = avc_has_perm(sksec-sid, skb-secmark, SECCLASS_PACKET,
PACKET__RECV, ad);
- if (err)
- goto out;
- err = selinux_netlbl_sock_rcv_skb(sksec, skb, ad);
out:
return err;
}
@@ -3527,11 +3528,8 @@ static int selinux_socket_getpeersec_str
peer_sid = ssec-peer_sid;
}
else if (isec-sclass == SECCLASS_TCP_SOCKET) {
- peer_sid = selinux_netlbl_socket_getpeersec_stream(sock);
- if (peer_sid == SECSID_NULL) {
- ssec = sock-sk-sk_security;
- peer_sid = ssec-peer_sid;
- }
+ ssec = sock-sk-sk_security;
+ peer_sid = ssec-peer_sid;
if (peer_sid == SECSID_NULL) {
err = -ENOPROTOOPT;
goto out;
@@ -3573,13 +3571,13 @@ static int selinux_socket_getpeersec_dgr
if (sock (sock-sk-sk_family == PF_UNIX))
selinux_get_inode_sid(SOCK_INODE(sock), peer_secid);
else if (skb) {
- peer_secid = selinux_netlbl_socket_getpeersec_dgram(skb);
- if (peer_secid == SECSID_NULL) {
- if (selinux_compat_net)
+ if (selinux_compat_net) {
+ peer_secid = selinux_netlbl_socket_getpeersec_dgram(
+ skb);
+ if (peer_secid == SECSID_NULL)
peer_secid = selinux_socket_getpeer_dgram(skb);
- else
- peer_secid = skb-secmark;
- }
+ } else
+ peer_secid = skb-secmark;
}
if (peer_secid == SECSID_NULL)
@@ -3641,13 +3639,11 @@ static int selinux_inet_conn_request(str
u32 newsid;
u32 peersid;
- newsid = selinux_netlbl_inet_conn_request(skb, sksec-sid);
- if (newsid != SECSID_NULL) {
- req-secid = newsid;
- return 0;
- }
-
if (selinux_compat_net) {
+ err = selinux_netlbl_skb_sid(skb, sksec-sid, peersid);
+ if (err == 0 peersid != SECSID_NULL)
+ goto out;
+
err = selinux_xfrm_decode_session(skb, peersid, 0);
BUG_ON(err);
@@ -3659,6 +3655,7 @@ static int selinux_inet_conn_request(str
} else
peersid = skb-secmark;
+out:
err = security_sid_mls_copy(sksec-sid, peersid, newsid);
if (err)
return err;
@@ -3700,6 +3697,9 @@ static void selinux_req_classify_flow(co
static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
{
u32 xfrm_sid;
+ u32 nlbl_sid;
+ u32 ext_sid;
+ u32 loc_sid;
int err;
if (selinux_compat_net)
@@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk
if (skb-dev == loopback_dev)
return 1;
+ if (skb-secmark)
+ loc_sid = skb-secmark;
+ else
+ loc_sid = SECINITSID_NETMSG;
+
err = selinux_xfrm_decode_session(skb, xfrm_sid, 0);
BUG_ON(err);
-
- err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG,
- SECCLASS_PACKET,
- PACKET__FLOW_IN, NULL);
+ err = selinux_netlbl_skb_sid(skb,
+xfrm_sid ? xfrm_sid : loc_sid,
+nlbl_sid);
if (err)
goto out;
- if (xfrm_sid)
- skb-secmark = xfrm_sid;
+ if (nlbl_sid)
+ ext_sid = nlbl_sid;
+ else
+ ext_sid = xfrm_sid;
+
+ err = avc_has_perm(ext_sid,
+ loc_sid,
+ SECCLASS_PACKET,
+ PACKET__FLOW_IN,
+
[PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix
This patchset includes an update to the NetLabel/secid-reconciliation patch, replacing my v3 patch from earlier this week, and a bugfix patch to cure a race condition found during testing this week. The bugfix patch does not rely on the secid patches and should be merged regardless as it fixes a bug which has been around since the very first NetLabel patches (not sure why I didn't see this sooner). -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] NetLabel: fix a cache race condition
Testing revealed a problem with the NetLabel cache where a cached entry could
be freed while in use by the LSM layer causing an oops and other problems.
This patch fixes that problem by introducing a reference counter to the cache
entry so that it is only freed when it is no longer in use.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
include/net/netlabel.h | 62 +++--
net/ipv4/cipso_ipv4.c | 18 ++-
net/netlabel/netlabel_kapi.c |2 -
security/selinux/ss/services.c | 37 +---
4 files changed, 79 insertions(+), 40 deletions(-)
Index: net-2.6/include/net/netlabel.h
===
--- net-2.6.orig/include/net/netlabel.h
+++ net-2.6/include/net/netlabel.h
@@ -34,6 +34,7 @@
#include linux/net.h
#include linux/skbuff.h
#include net/netlink.h
+#include asm/atomic.h
/*
* NetLabel - A management interface for maintaining network packet label
@@ -106,6 +107,7 @@ int netlbl_domhsh_remove(const char *dom
/* LSM security attributes */
struct netlbl_lsm_cache {
+ atomic_t refcount;
void (*free) (const void *data);
void *data;
};
@@ -117,7 +119,7 @@ struct netlbl_lsm_secattr {
unsigned char *mls_cat;
size_t mls_cat_len;
- struct netlbl_lsm_cache cache;
+ struct netlbl_lsm_cache *cache;
};
/*
@@ -126,6 +128,43 @@ struct netlbl_lsm_secattr {
/**
+ * netlbl_secattr_cache_alloc - Allocate and initialize a secattr cache
+ * @flags: the memory allocation flags
+ *
+ * Description:
+ * Allocate and initialize a netlbl_lsm_cache structure. Returns a pointer
+ * on success, NULL on failure.
+ *
+ */
+static inline struct netlbl_lsm_cache *netlbl_secattr_cache_alloc(int flags)
+{
+ struct netlbl_lsm_cache *cache;
+
+ cache = kzalloc(sizeof(*cache), flags);
+ if (cache)
+ atomic_set(cache-refcount, 1);
+ return cache;
+}
+
+/**
+ * netlbl_secattr_cache_free - Frees a netlbl_lsm_cache struct
+ * @cache: the struct to free
+ *
+ * Description:
+ * Frees @secattr including all of the internal buffers.
+ *
+ */
+static inline void netlbl_secattr_cache_free(struct netlbl_lsm_cache *cache)
+{
+ if (!atomic_dec_and_test(cache-refcount))
+ return;
+
+ if (cache-free)
+ cache-free(cache-data);
+ kfree(cache);
+}
+
+/**
* netlbl_secattr_init - Initialize a netlbl_lsm_secattr struct
* @secattr: the struct to initialize
*
@@ -143,20 +182,16 @@ static inline int netlbl_secattr_init(st
/**
* netlbl_secattr_destroy - Clears a netlbl_lsm_secattr struct
* @secattr: the struct to clear
- * @clear_cache: cache clear flag
*
* Description:
* Destroys the @secattr struct, including freeing all of the internal buffers.
- * If @clear_cache is true then free the cache fields, otherwise leave them
- * intact. The struct must be reset with a call to netlbl_secattr_init()
- * before reuse.
+ * The struct must be reset with a call to netlbl_secattr_init() before reuse.
*
*/
-static inline void netlbl_secattr_destroy(struct netlbl_lsm_secattr *secattr,
- u32 clear_cache)
+static inline void netlbl_secattr_destroy(struct netlbl_lsm_secattr *secattr)
{
- if (clear_cache secattr-cache.data != NULL secattr-cache.free)
- secattr-cache.free(secattr-cache.data);
+ if (secattr-cache)
+ netlbl_secattr_cache_free(secattr-cache);
kfree(secattr-domain);
kfree(secattr-mls_cat);
}
@@ -178,17 +213,14 @@ static inline struct netlbl_lsm_secattr
/**
* netlbl_secattr_free - Frees a netlbl_lsm_secattr struct
* @secattr: the struct to free
- * @clear_cache: cache clear flag
*
* Description:
- * Frees @secattr including all of the internal buffers. If @clear_cache is
- * true then free the cache fields, otherwise leave them intact.
+ * Frees @secattr including all of the internal buffers.
*
*/
-static inline void netlbl_secattr_free(struct netlbl_lsm_secattr *secattr,
- u32 clear_cache)
+static inline void netlbl_secattr_free(struct netlbl_lsm_secattr *secattr)
{
- netlbl_secattr_destroy(secattr, clear_cache);
+ netlbl_secattr_destroy(secattr);
kfree(secattr);
}
Index: net-2.6/net/ipv4/cipso_ipv4.c
===
--- net-2.6.orig/net/ipv4/cipso_ipv4.c
+++ net-2.6/net/ipv4/cipso_ipv4.c
@@ -43,6 +43,7 @@
#include net/tcp.h
#include net/netlabel.h
#include net/cipso_ipv4.h
+#include asm/atomic.h
#include asm/bug.h
struct cipso_v4_domhsh_entry {
@@ -79,7 +80,7 @@ struct cipso_v4_map_cache_entry {
unsigned char *key;
size_t key_len;
- struct netlbl_lsm_cache lsm_data;
+ struct netlbl_lsm_cache *lsm_data;
u32 activity;
struct list_head list;
@@ -188,13 +189,14 @@ static void
d80211: ieee80211_hw handlers in atomic context
Hello Jiri, Ivo suggested to bring this issue to a broader audience, specifically to the stack maintainer. Trying to run my Asus WL167G with rt2500usb I faced the following: BUG: scheduling while atomic: swapper/0x0102/0 c0103055 show_trace+0x12/0x14 c01035e0 dump_stack+0x1c/0x1e c025fad1 schedule+0x5f/0x652 c0260324 wait_for_completion+0xb8/0x134 d0988fa1 usb_start_wait_urb+0x89/0xcb [usbcore] d0989192 usb_control_msg+0xb2/0xcc [usbcore] d089d127 rt2x00_vendor_request+0x85/0xbb [rt2500usb] d08a1350 rt2500usb_config+0x5e/0x3d7 [rt2500usb] d0823496 ieee80211_hw_config+0x2c/0x93 [80211] d0829950 ieee80211_ioctl_siwfreq+0x132/0x141 [80211] d082ee8b ieee80211_sta_join_ibss+0xcc/0x5af [80211] d082f698 ieee80211_sta_find_ibss+0x32a/0x374 [80211] d08317f8 ieee80211_sta_timer+0x81/0x1b4 [80211] c011ac50 run_timer_softirq+0x171/0x205 c0117536 __do_softirq+0x41/0x90 c01175bc do_softirq+0x37/0x4a c01176b7 irq_exit+0x2d/0x45 c0104316 do_IRQ+0x53/0x5f The reason is the invocation of rt2500usb's config handler in atomic context (timer handler). But this service requires schedulable context to submit and wait for some URBs. That raises the question how to resolve the conflict best, at stack level by pushing such work into thread context (workqueues?) or at driver level by deferring these requests (if feasible at all without breaking the stack's timing)? What other callback handlers in ieee80211_hw can currently be called in atomic context? Given that all USB WLAN adapters will have to cope with this issue in some way, it may be wise to find a common solution. Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking for work, at best I would just enjoy to use it. ;) Jan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: ieee80211_hw handlers in atomic context
Hi, Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking for work, at best I would just enjoy to use it. ;) I have found the actual patch: [PATCH 1/5] d80211: make sleeping in hw-config possible And was send on august 1st by Jiri to the netdev list. It was based on a patch by Michael Buesch. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: ieee80211_hw handlers in atomic context
On Wed, 04 Oct 2006 17:59:57 +0200, Jan Kiszka wrote: The reason is the invocation of rt2500usb's config handler in atomic context (timer handler). But this service requires schedulable context to submit and wait for some URBs. Hm, I thought it had been fixed (http://kernel.org/git/?p=linux/kernel/git/linville/wireless-dev.git;a=commit;h=d0d2b7a8ddc378ddea499f1537f6aea83d96d003). We'll need to make something similar with sta_timer. That raises the question how to resolve the conflict best, at stack level by pushing such work into thread context (workqueues?) or at driver level by deferring these requests (if feasible at all without breaking the stack's timing)? What other callback handlers in ieee80211_hw can currently be called in atomic context? Given that all USB WLAN adapters will have to cope with this issue in some way, it may be wise to find a common solution. It needs to be solved in the stack. ieee80211_hw-config callback should return proper error code in a case of problems and this is not possible when the work is deferred in the driver. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: ieee80211_hw handlers in atomic context
Ivo van Doorn wrote: Hi, Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking for work, at best I would just enjoy to use it. ;) I have found the actual patch: [PATCH 1/5] d80211: make sleeping in hw-config possible And was send on august 1st by Jiri to the netdev list. It was based on a patch by Michael Buesch. Ah, looks like I didn't dug thoroughly enough. Anyway, this means my BUG proved the patch's claim wrong :o), at least one atomic gremlin is left: ieee80211_sta_timer - ieee80211_sta_find_ibss - ieee80211_sta_join_ibss - ieee80211_ioctl_siwfreq - ieee80211_hw_config Anyone already an idea how to fix it? Jan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 5/5] d80211: allow wireless vlan interface to have same MAC an AP interface
All patches have been applied to my tree, thanks! Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: ieee80211_hw handlers in atomic context
On Wed, 4 Oct 2006 18:34:57 +0200, Ivo van Doorn wrote: You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :) Yes, the timing isn't required to be precise here. Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: ieee80211_hw handlers in atomic context
On Wednesday 04 October 2006 18:31, Jan Kiszka wrote: Ivo van Doorn wrote: Hi, Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking for work, at best I would just enjoy to use it. ;) I have found the actual patch: [PATCH 1/5] d80211: make sleeping in hw-config possible And was send on august 1st by Jiri to the netdev list. It was based on a patch by Michael Buesch. Ah, looks like I didn't dug thoroughly enough. Anyway, this means my BUG proved the patch's claim wrong :o), at least one atomic gremlin is left: ieee80211_sta_timer - ieee80211_sta_find_ibss - ieee80211_sta_join_ibss - ieee80211_ioctl_siwfreq - ieee80211_hw_config Anyone already an idea how to fix it? You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :) Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: ieee80211_hw handlers in atomic context
Jiri Benc wrote: On Wed, 4 Oct 2006 18:34:57 +0200, Ivo van Doorn wrote: You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :) Yes, the timing isn't required to be precise here. Ok, I'm not promising success and I'm going to duck immediately if someone else feels like working on it, but I could try to patch in this direction. Now there just remains my precautious question if there are other services in the ieee_80211_hw interface that may conflict with sleeping USB drivers. What about specifying the possible contexts in include/net/d80211.h? Jan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/2] NetLabel: secid reconciliation support
@@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk if (skb-dev == loopback_dev) return 1; + if (skb-secmark) + loc_sid = skb-secmark; + else + loc_sid = SECINITSID_NETMSG; + err = selinux_xfrm_decode_session(skb, xfrm_sid, 0); BUG_ON(err); - - err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG, - SECCLASS_PACKET, - PACKET__FLOW_IN, NULL); + err = selinux_netlbl_skb_sid(skb, + xfrm_sid ? xfrm_sid : loc_sid, + nlbl_sid); if (err) goto out; - if (xfrm_sid) - skb-secmark = xfrm_sid; + if (nlbl_sid) + ext_sid = nlbl_sid; + else + ext_sid = xfrm_sid; There's a problem here in that it would require 2 different policies depending on whether one is using netlabel or xfrm. Specifically, in the absence of matching iptables contexts (secmark), the skb here will get: - 0 (xfrm case) - network_t (netlabel) This has implications for getpeercon() where it would - fail with ENOPROTOOPT (xfrm case) - returns network_t (netlabel) I would still argue that the nature of the domain being carried by the packet is still unlabeled_t as implied by the null secmark. While I view secmark/point as specifying BOTH a flow control point and a default domain (incidentally using the same label more because of implementation constrainst), I view network_t as purely a flow control point. But I also realize there can be equally forceful arguments for what this patch does. What does the community think? We need to resolve it one way or the other unless the above differences in behavior are desired or somehow accounted for in policy and apps. + + err = avc_has_perm(ext_sid, +loc_sid, +SECCLASS_PACKET, +PACKET__FLOW_IN, +NULL); + if (err) + goto out; - /* See if NetLabel can flow in thru the current secmark here */ + if (ext_sid) + skb-secmark = ext_sid; out: return err ? 0 : 1; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/2] NetLabel: secid reconciliation support
@@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk if (skb-dev == loopback_dev) return 1; + if (skb-secmark) + loc_sid = skb-secmark; + else + loc_sid = SECINITSID_NETMSG; + err = selinux_xfrm_decode_session(skb, xfrm_sid, 0); BUG_ON(err); - - err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG, - SECCLASS_PACKET, - PACKET__FLOW_IN, NULL); + err = selinux_netlbl_skb_sid(skb, +xfrm_sid ? xfrm_sid : loc_sid, +nlbl_sid); if (err) goto out; - if (xfrm_sid) - skb-secmark = xfrm_sid; + if (nlbl_sid) + ext_sid = nlbl_sid; + else + ext_sid = xfrm_sid; There's a problem here in that it would require 2 different policies depending on whether one is using netlabel or xfrm. Specifically, in the absence of matching iptables contexts (secmark), as well as any external labeling via ipsec/NetLabel, the skb here will get: - 0 (xfrm case) - network_t (netlabel) This has implications for getpeercon() where it would - fail with ENOPROTOOPT (xfrm case) - returns network_t (netlabel) I would still argue that the nature of the domain being carried by the packet is still unlabeled_t as implied by the null secmark. While I view secmark/point as specifying BOTH a flow control point and a default domain (incidentally using the same label more because of implementation constrainst), I view network_t as purely a flow control point. But I also realize there can be equally forceful arguments for what this patch does. What does the community think? We need to resolve it one way or the other unless the above differences in behavior are desired or somehow accounted for in policy and apps. + + err = avc_has_perm(ext_sid, + loc_sid, + SECCLASS_PACKET, + PACKET__FLOW_IN, + NULL); + if (err) + goto out; - /* See if NetLabel can flow in thru the current secmark here */ + if (ext_sid) + skb-secmark = ext_sid; out: return err ? 0 : 1; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Customizable TCP backoff patch
On Wed, 04 Oct 2006 00:07:22 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Ben Woodard [EMAIL PROTECTED]
Date: Tue, 03 Oct 2006 11:14:38 -0700
Other issues:
1) 2 u32 in the tcp_sock is a lot of space to devote to this
new state. If it can fit in 2 u16's or even less space,
please use that.
2) the expression (tp-foo ? : sysctl_foo) is repeated many times
in the patch, please encapsulate it into an inline function
or similar
How does this look to you for answering your two complaints above.
It looks a lot better. I'd like you to take #2 further,
put the inline function into net/tcp.h and use it in the
tcp.c instances too.
Also, please don't format code like this:
+static inline __u16 rto_max(struct tcp_sock *tp){
+return tp-rto_max ? : sysctl_tcp_rto_max;
+}
+
+static inline __u16 rto_init(struct tcp_sock *tp){
+return tp-rto_init ? : sysctl_tcp_rto_init;
+}
The openning brace of each functions belongs on a line by itself,
thanks.
Finally, I'm not so sure seconds is the best unit for the
socket option. In fact you use seconds as the unit for
the socket option and the sysctl is raw jiffies. That's
inconsistency is really problematic.
At the very least, seconds might not be fine enough granularity
for some circumstances. Heck, the default RTO_MIN is 1/5 of a
second. :-)
I also understand that going to milliseconds or microseconds would
make the size of the in-socket struct members an issue again. These
things are never easy are they? :-/
Any better ideas?
If you are willing to do a little more work, the sysctl value can be
in milliseconds, and the internal socket member in some other unit
like jiffies. It does require writing your own in/out translation
instead of using proc_dointvec
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: ieee80211_hw handlers in atomic context
Hi, On Wed, 4 Oct 2006 18:34:57 +0200, Ivo van Doorn wrote: You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :) Yes, the timing isn't required to be precise here. Ok, I'm not promising success and I'm going to duck immediately if someone else feels like working on it, but I could try to patch in this direction. If you need testing of the patch for a slightly larger audience, you can send it to me and I'll place it in the rt2x00 CVS tree which contains a copy of the current dscape stack for backwards compatibility with older kernels. Now there just remains my precautious question if there are other services in the ieee_80211_hw interface that may conflict with sleeping USB drivers. What about specifying the possible contexts in include/net/d80211.h? Well another point of concern for me is the TSF handling, those handlers are called from interrupt context as well, and also deliver problems for the USB drivers in case of adhoc mode. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices
Or Gerlitz [EMAIL PROTECTED] wrote:
[...]
Looking on the sysconfig package, some tools eg /sbin/if{up,down,status}
use ifenslave which is in turn provided by the iputils package.
My understanding is that changing ifenslave and the bonding kernel code to
allow for enslaving while master is not up is enough, so actually no
change is needed to the sysconfig tools, correct?
Incorrect. The /sbin/ifup included with sysconfig (I'm looking
at version 0.31-0-15.51) has logic to set the bonding master device up
prior to adding any slaves. E.g.,
# get up the bonding device before enslaving
# if ! is_iface_up $INTERFACE; then
ip link set $INTERFACE up 21
# fi
# enslave available slave devices; if there is none - hard
break and log
MESSAGE=`/sbin/ifenslave $BONDING_OPTIONS $INTERFACE
$BSINTERFACES 21`
For your purposes, this would cause it to register as an
ethernet hardware type, not an IB type. The /sbin/ifup included with
initscripts operates a little differently, but also sets the bonding
master up prior to adding any slaves.
I have now removed the two assertions in the bonding code on enslaving
while master is not up and manage to work fine with IPoIB slave devices
and ***without*** the two module params!
When you have the most troublesome to deploy, the troubles you refer to is
make sure that the distros would include ***both*** the bonding kernel
changes and use an iputils package which has the ifenslave changes?
Yes. Part of the difficulty is that the changes to the
initscripts and sysconfig packages won't be compatible with versions of
bonding prior to the bonding kernel changes (because older versions of
bonding will refuse to add slaves if the master is down). It might
require adding another API version to bonding, and modifying ifenslave
to work both ways (i.e., with the current enslave with master up API,
as well as the new enslave with master down API).
Yes, ifenslave is still supported. It probably will be
obsoleted some day (or replaced with a script that uses sysfs), but not
anytime soon. As far as I know, all current distros use ifenslave to
configure bonding.
Cool, thanks for bringing this into my attention... I understand now my
patch set should also handle the ifenslave.c source that comes with the
kernel (eg to allow for not setting the hw address etc)
An alternate approach would be to undertake the more substantial
task of converting the initscripts and sysconfig code to use sysfs to
configure bonding. This would permit changing the logic (to add slaves
while the bonding master is down, then set it up), as well as remove the
current hacks (present only in sysconfig) to load the bonding module
once per configured bonding interface. The initscripts currently don't
do this (as far as I know), so it's generally only possible to have one
bonding interface under initscripts control.
In this case, ifenslave would continue to work as it does now,
and would simply not be supported for the new hardware.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Wed, 04 Oct 2006 08:42:28 -0500 Steve Fox [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 14:01 -0700, Andrew Morton wrote: On Thu, 28 Sep 2006 17:50:31 + (UTC) Steve Fox [EMAIL PROTECTED] wrote: On Thu, 28 Sep 2006 01:46:23 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm2/ Panic on boot. This machine booted 2.6.18-mm1 fine. em64t machine. TCP bic registered TCP westwood registered TCP htcp registered NET: Registered protocol family 1 NET: Registered protocol family 17 Unable to handle kernel paging request at RIP: [8047ef93] packet_notifier+0x163/0x1a0 PGD 203027 PUD 2b031067 PMD 0 Oops: [1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.18-mm2-autokern1 #1 RIP: 0010:[8047ef93] [8047ef93] packet_notifier+0x163/0x1a0 RSP: :810bffcbde90 EFLAGS: 00010286 RAX: RBX: 810bff4a1000 RCX: RDX: 810bff4a1000 RSI: 0005 RDI: 8055f5e0 RBP: R08: 7616 R09: 000e R10: 0006 R11: 803373f0 R12: R13: 0005 R14: 810bff4a1000 R15: FS: () GS:805d8000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: CR3: 00201000 CR4: 06e0 Process swapper (pid: 1, threadinfo 810bffcbc000, task 810bffcbb510) Stack: 810bff4a1000 8055f4c0 810bffcbdef0 8042736e 8061c68d 806260f0 80207182 Call Trace: [8042736e] register_netdevice_notifier+0x3e/0x70 [8061c68d] packet_init+0x2d/0x53 [80207182] init+0x162/0x330 [8020a9d8] child_rip+0xa/0x12 [8033c2a2] acpi_ds_init_one_object+0x0/0x82 [80207020] init+0x0/0x330 [8020a9ce] child_rip+0x0/0x12 Code: 48 8b 45 00 0f 18 08 49 83 fd 02 4c 8d 65 f8 0f 84 f8 fe ff RIP [8047ef93] packet_notifier+0x163/0x1a0 RSP 810bffcbde90 CR2: 0Kernel panic - not syncing: Attempted to kill init! I'm really struggling to work out what went wrong there. Comparing your miserable 20 bytes of code to my object code makes me think that this: struct packet_sock *po = pkt_sk(sk); returned -1, perhaps in %ebp. But it's all very crude. Perhaps you could compile that kernel with CONFIG_DEBUG_INFO, rerun it (the addresses might change) then have a poke around with `gdb vmlinux' (or maybe just addr2line) to work out where it's really oopsing? I don't see much which has changed in that area recently. Sorry for the delay. I was finally able to perform a bisect on this. It turns out the patch that causes this is x86_64-mm-re-positioning-the-bss-segment.patch, which seems like a strange candidate, but sure enough I can boot to login: right up until that patch is applied. hm, that patch was merged into mainline September 29. Does mainline work? P.S. I had to comment usb-hubc-build-fix.patch out of the series file because it would not apply cleanly and caused quilt (0.45) to simply abort its 'push' operation. Sorry about that. If mainline _does_ work then perhaps it's an interaction between that patch and something else in the -mm2 lineup (and at that point in the bisection, it'll be one of the git trees or something else in the x86_64 tree). Could be that the problem remains in -mm3. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Wednesday 04 October 2006 17:45, Andrew Morton wrote: On Wed, 04 Oct 2006 08:42:28 -0500 Steve Fox [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 14:01 -0700, Andrew Morton wrote: On Thu, 28 Sep 2006 17:50:31 + (UTC) Steve Fox [EMAIL PROTECTED] wrote: On Thu, 28 Sep 2006 01:46:23 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm2/ Panic on boot. This machine booted 2.6.18-mm1 fine. em64t machine. TCP bic registered TCP westwood registered TCP htcp registered NET: Registered protocol family 1 NET: Registered protocol family 17 Unable to handle kernel paging request at RIP: [8047ef93] packet_notifier+0x163/0x1a0 PGD 203027 PUD 2b031067 PMD 0 Oops: [1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.18-mm2-autokern1 #1 RIP: 0010:[8047ef93] [8047ef93] packet_notifier+0x163/0x1a0 RSP: :810bffcbde90 EFLAGS: 00010286 RAX: RBX: 810bff4a1000 RCX: RDX: 810bff4a1000 RSI: 0005 RDI: 8055f5e0 RBP: R08: 7616 R09: 000e R10: 0006 R11: 803373f0 R12: R13: 0005 R14: 810bff4a1000 R15: FS: () GS:805d8000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: CR3: 00201000 CR4: 06e0 Process swapper (pid: 1, threadinfo 810bffcbc000, task 810bffcbb510) Stack: 810bff4a1000 8055f4c0 810bffcbdef0 8042736e 8061c68d 806260f0 80207182 Call Trace: [8042736e] register_netdevice_notifier+0x3e/0x70 [8061c68d] packet_init+0x2d/0x53 [80207182] init+0x162/0x330 [8020a9d8] child_rip+0xa/0x12 [8033c2a2] acpi_ds_init_one_object+0x0/0x82 [80207020] init+0x0/0x330 [8020a9ce] child_rip+0x0/0x12 Code: 48 8b 45 00 0f 18 08 49 83 fd 02 4c 8d 65 f8 0f 84 f8 fe ff RIP [8047ef93] packet_notifier+0x163/0x1a0 RSP 810bffcbde90 CR2: 0Kernel panic - not syncing: Attempted to kill init! I'm really struggling to work out what went wrong there. Comparing your miserable 20 bytes of code to my object code makes me think that this: struct packet_sock *po = pkt_sk(sk); returned -1, perhaps in %ebp. But it's all very crude. Perhaps you could compile that kernel with CONFIG_DEBUG_INFO, rerun it (the addresses might change) then have a poke around with `gdb vmlinux' (or maybe just addr2line) to work out where it's really oopsing? I don't see much which has changed in that area recently. Sorry for the delay. I was finally able to perform a bisect on this. It turns out the patch that causes this is x86_64-mm-re-positioning-the-bss-segment.patch, which seems like a strange candidate, but sure enough I can boot to login: right up until that patch is applied. hm, that patch was merged into mainline September 29. Does mainline work? Yes we had this earlier already. But without this patch it doesn't compile for some people. So it was readded. And nobody knows why the reposition-bss patch actually breaks things :/ In theory the reposition is ok, so it must be some marginal code somewhere else that just ends up failing over. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Wed, Oct 04, 2006 at 08:45:40AM -0700, Andrew Morton wrote: On Wed, 04 Oct 2006 08:42:28 -0500 Steve Fox [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 14:01 -0700, Andrew Morton wrote: On Thu, 28 Sep 2006 17:50:31 + (UTC) Steve Fox [EMAIL PROTECTED] wrote: On Thu, 28 Sep 2006 01:46:23 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm2/ Panic on boot. This machine booted 2.6.18-mm1 fine. em64t machine. TCP bic registered TCP westwood registered TCP htcp registered NET: Registered protocol family 1 NET: Registered protocol family 17 Unable to handle kernel paging request at RIP: [8047ef93] packet_notifier+0x163/0x1a0 PGD 203027 PUD 2b031067 PMD 0 Oops: [1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.18-mm2-autokern1 #1 RIP: 0010:[8047ef93] [8047ef93] packet_notifier+0x163/0x1a0 RSP: :810bffcbde90 EFLAGS: 00010286 RAX: RBX: 810bff4a1000 RCX: RDX: 810bff4a1000 RSI: 0005 RDI: 8055f5e0 RBP: R08: 7616 R09: 000e R10: 0006 R11: 803373f0 R12: R13: 0005 R14: 810bff4a1000 R15: FS: () GS:805d8000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: CR3: 00201000 CR4: 06e0 Process swapper (pid: 1, threadinfo 810bffcbc000, task 810bffcbb510) Stack: 810bff4a1000 8055f4c0 810bffcbdef0 8042736e 8061c68d 806260f0 80207182 Call Trace: [8042736e] register_netdevice_notifier+0x3e/0x70 [8061c68d] packet_init+0x2d/0x53 [80207182] init+0x162/0x330 [8020a9d8] child_rip+0xa/0x12 [8033c2a2] acpi_ds_init_one_object+0x0/0x82 [80207020] init+0x0/0x330 [8020a9ce] child_rip+0x0/0x12 Code: 48 8b 45 00 0f 18 08 49 83 fd 02 4c 8d 65 f8 0f 84 f8 fe ff RIP [8047ef93] packet_notifier+0x163/0x1a0 RSP 810bffcbde90 CR2: 0Kernel panic - not syncing: Attempted to kill init! I'm really struggling to work out what went wrong there. Comparing your miserable 20 bytes of code to my object code makes me think that this: struct packet_sock *po = pkt_sk(sk); returned -1, perhaps in %ebp. But it's all very crude. Perhaps you could compile that kernel with CONFIG_DEBUG_INFO, rerun it (the addresses might change) then have a poke around with `gdb vmlinux' (or maybe just addr2line) to work out where it's really oopsing? I don't see much which has changed in that area recently. Sorry for the delay. I was finally able to perform a bisect on this. It turns out the patch that causes this is x86_64-mm-re-positioning-the-bss-segment.patch, which seems like a strange candidate, but sure enough I can boot to login: right up until that patch is applied. hm, that patch was merged into mainline September 29. Does mainline work? I thought above patch was dropped because Keith ran into some boot issues on one of the machines. Though there seems to be nothing wrong with the patch as such but it might have triggered some existing bug. At that point of time I looked into the issue but nothing was conclusive. So looks like this patch has come back. I am not sure how. Thanks Vivek - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Wed, 2006-10-04 at 08:45 -0700, Andrew Morton wrote: On Wed, 04 Oct 2006 08:42:28 -0500 Steve Fox [EMAIL PROTECTED] wrote: Sorry for the delay. I was finally able to perform a bisect on this. It turns out the patch that causes this is x86_64-mm-re-positioning-the-bss-segment.patch, which seems like a strange candidate, but sure enough I can boot to login: right up until that patch is applied. hm, that patch was merged into mainline September 29. Does mainline work? -git21 also fails with this same error. -- Steve Fox IBM Linux Technology Center - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm3 oops in xfrm_register_mode
On Wed, 04 Oct 2006 10:14:55 -0500
Steve Fox [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm3/
This is on the same x86_64 box which I reported the -mm2 boot problem. I
have confirmed that CONFIG_DEBUG_INFO was on for the -mm2 oops as well
as this one. I'll begin a bisection on this issue as well and post the
results when finished.
Fusion MPT base driver 3.04.01
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.04.01
Fusion MPT FC Host driver 3.04.01
Fusion MPT misc device (ioctl) driver 3.04.01
mptctl: Registered with Fusion MPT base driver
mptctl: /dev/mptctl @ (major,minor=10,220)
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
Unable to handle kernel NULL pointer dereference at 0807 RIP:
[80471196] xfrm_register_mode+0x36/0x60
PGD 0
Oops: [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.18-mm3 #2
RIP: 0010:[80471196] [80471196]
xfrm_register_mode+0x36/0x60
RSP: :810bffcbded0 EFLAGS: 00010286
RAX: 07ff RBX: 8056a1a0 RCX:
RDX: RSI: 0002 RDI: 8056ae10
RBP: ffef R08: ade70d2e R09:
R10: 810bffcbdcb0 R11: 0154 R12:
R13: 810bffcbdef0 R14: R15:
FS: () GS:805e8000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 0807 CR3: 00201000 CR4: 06e0
Process swapper (pid: 1, threadinfo 810bffcbc000, task 810bffcbb510)
Stack: 806363f0 80207182
0009
Call Trace:
[80207182] init+0x162/0x330
[8020a9d5] child_rip+0xa/0x15
[8033a932] acpi_ds_init_one_object+0x0/0x82
[80207020] init+0x0/0x330
[8020a9cb] child_rip+0x0/0x15
Code: 48 83 78 08 00 75 06 48 89 58 08 31 ed 48 89 d7 e8 e5 fe ff
RIP [80471196] xfrm_register_mode+0x36/0x60
RSP 810bffcbded0
CR2: 0807
0Kernel panic - not syncing: Aiee, killing interrupt handler!
Thanks, Steve.
You might well find this bisection lands you on origin.patch. ie: a
mainline bug. I note that David merged a few more xfrm fixes this morning.
So to confirm that, first test just origin.patch and if that fails, test
git-of-the-moment. If that doesn't fail, they fixed it.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take19 0/4] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: It is completely possible to do what you describe without special syscall parameters. First of all, I don't see how this is efficiently possible. The mask might change from call to call. Second, hasn't it sunk in that inventing new ways to pass parameters is bad? Programmers don't want to learn new ways for every new interface. Reuse is good! This applies to the signal mask here. But there is another parameter falling into that category and I meant to mention it before: the timeout value. All other calls except poll and especially all modern interfaces use a timespec pointer. This is the way times are kept in userland code. Don't try to force people to do something else. Using a timespec also has the advantage that we can add an absolute timeout value mode (optional) instead of the relative timeout value. In this context, we should/must be able to specify which clock the timeout is for (not as part of the wait call, but another control operation perhaps). It's important to distinguish between CLOCK_REALTIME and CLOCK_MONOTONE. Both have their use. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: [RFC] cfg80211 and nl80211
On Wed, 2006-10-04 at 16:19 +0200, Johannes Berg wrote:
On Wed, 2006-10-04 at 09:41 +0200, Johannes Berg wrote:
I don't really have an explicit ToDo list, but here are a few points
that come to mind
* notification support when parameters change multicast a netlink
message to all subscribers of that group
I think we'll want at least two groups here:
- scan results
- configuration changes
can anyone think of more? NM might like to listen for config changes and
scan events, but most tools won't be that much concerned about config
changes... current wireless events are subsumed here as well.
Are we talking about config changes when some other process pushes a new
config to the card, or when something happens over the air, like new
association or deauth?
* transmit status notification support for packet injection (sort of
ties in with the first point)
This should be a matter of saving the socket id of the requesting
nl80211 packet in the request structure, and having d80211/the driver
keep track of it and pass it back with the tx status structure to an
cfg80211_transmit_status(). Maybe a second cookie would be good too if
we ever gain packet injection capabilities over something other than
netlink. Thoughts?
* scan results (also somewhat related to the first point)
Should cfg80211 do the chore of keeping track of the whole scan results?
On the other hand, that doesn't seem to be doable with legacy hardware
that does all the scanning. So probably one call for
cfg80211_notify_scan()
that takes a new scan result structure (taking a single BSSID etc.) and
notifies all listeners.
The same structure is used for get_scan() from the wiphy ops in an
iterator interface like some other calls.
Is it a problem to actually push the _entire_ scan list out to clients
over netlink? The scan list could be quite large, maybe even a few
kilobytes when stuff like Information Elements, ratesets, etc is
available. I've seen 35-item scan lists that are already around 1.5K.
Ideally, we could push the whole scan list to clients, and then we avoid
the race between getting the scan result notification and hitting the
card. That said, as long as the driver does proper locking, the race
condition shouldn't matter at all.
I'd vote for pushing results along with the notification, because one of
the most annoying things in the past was the inconsistency between how
drivers reported results and what BSSID attributes they sent. If we can
_standardize_ the result list and its construction inside
cfg80211/nl80211 that would be a great benefit.
If we can't push results with the notification, at least provide some
functions to build up the GET_SCAN reply message, which you'll likely
have to do anyway once you implement GET_SCAN. We _really_ need drivers
to be consistent here.
* crypto and auth support
I've done a lot of thinking about crypto/auth this morning while beating
the hell out of the libertas 8388 driver to clean up the ENCODE support.
There are several issues here. They can be roughly split by encryption
algorithm. But the big question:
Is there a case for _multiple_ encryption algorithms enabled
on a single virtual interface at one time?
I don't think there is, and I think that just complicates things in
d80211 anyway. If we agree that you can only set one of [none, WEP,
WPA] on a virtual interface at any given time, it makes the crypto
interface for nl80211 a lot easier.
Part of the problem of WE right now is that there's no clear API
separation between the different options. You can pass some WEP options
through when you really want to do WPA (like key indexes). That makes
the driver handling code for ENCODE and ENCODEEXT too complex.
Taking one-at-a-time as a given, and the pseudo-structure
struct cmd_crypto {
enum crypto_alg alg;
union data {
none_data;
wep_data;
wpa_data;
...
};
};
Set alg == whatever, set the options, and the driver will _enable_
that crypto mode with the given options. It makes no sense at all to,
say, set the WEP transmit key index or WEP key when the card is in WPA
mode or no-crypto mode.
It's important to note that some options are independent of the initial
operation that enabled the crypto, and need to be set later without
triggering deauth and such. Setting non-TX-index WEP key is one such
operation. I should be able to set WEP keys at indexes other than the
transmit key index without affecting operation of the card (unless some
hardware/firmware issue prevents this).
- No crypto
- WEP encryption (following ops are independent of each other):
- Set TX key index
- Set privacy invoked
- Set exclude unencrypted packets
- Set authentication mode (open, shared-key, or both)
- Set (or clear) WEP key 1, 2, 3, or 4
- WPA/WPA2/IEEE8021X
- Jouni/others would know better and my brain is fried right now
All
Re: [PATCH v4 1/2] NetLabel: secid reconciliation support
Venkat Yekkirala wrote: @@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk if (skb-dev == loopback_dev) return 1; + if (skb-secmark) + loc_sid = skb-secmark; + else + loc_sid = SECINITSID_NETMSG; + err = selinux_xfrm_decode_session(skb, xfrm_sid, 0); BUG_ON(err); - - err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG, - SECCLASS_PACKET, - PACKET__FLOW_IN, NULL); + err = selinux_netlbl_skb_sid(skb, + xfrm_sid ? xfrm_sid : loc_sid, + nlbl_sid); if (err) goto out; - if (xfrm_sid) - skb-secmark = xfrm_sid; + if (nlbl_sid) + ext_sid = nlbl_sid; + else + ext_sid = xfrm_sid; There's a problem here in that it would require 2 different policies depending on whether one is using netlabel or xfrm. Specifically, in the absence of matching iptables contexts (secmark), the skb here will get: - 0 (xfrm case) - network_t (netlabel) Perhaps I'm reading it the wrong way, but I didn't quite follow your comment. In an effort to bring some clarity to all of this here are all of the possibile combinations that I can see using the code above (feel free to correct me if I made a mistake): * SECMARK, XFRM, NetLabel present xfrm_sid = full context from xfrm loc_sid = full context from secmark nlbl_sid = xfrm_sid te ctx, netlabel mls ctx ext_sid = nlbl_sid final skb-secmark = avc_ok : ext_sid ? unchanged * SECMARK, XFRM present xfrm_sid = full context from xfrm loc_sid = full context from secmark nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged * SECMARK, NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = full context from secmark nlbl_sid = secmark te ctx, netlabel mls ctx ext_sid = nlbl_sid final skb-secmark = avc_ok : ext_sid ? unchanged * XFRM, NetLabel present xfrm_sid = full context from xfrm loc_sid = SECINITSID_NETMSG nlbl_sid = xfrm_sid te ctx, netlabel mls ctx ext_sid = nlbl_sid final skb-secmark = avc_ok : ext_sid ? unchanged * XFRM present xfrm_sid = full context from xfrm loc_sid = SECINITSID_NETMSG nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged * NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECINITSID_NETMSG te ctx, netlabel mls ctx ext_sid = nlbl_sid final skb-secmark = avc_ok : ext_sid ? unchanged * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged This has implications for getpeercon() where it would - fail with ENOPROTOOPT (xfrm case) - returns network_t (netlabel) I would still argue that the nature of the domain being carried by the packet is still unlabeled_t as implied by the null secmark. While I view secmark/point as specifying BOTH a flow control point and a default domain (incidentally using the same label more because of implementation constrainst), I view network_t as purely a flow control point. But I also realize there can be equally forceful arguments for what this patch does. I know the two of us have talked about this before on the mail lists, but I don't believe anyone else has ever made a comment in this regard. I tend to feel rather strongly that when using just NetLabel on a connection you shouldn't see an unlabeled_t type as I feel that the connotation associated with this type is misleading, even though from a TE point of view there may be an argument made that it is appropriate. What does the community think? We need to resolve it one way or the other unless the above differences in behavior are desired or somehow accounted for in policy and apps. I agree - I'd like to hear what others (namely Stephen Smalley, James Morris and all of the Tresys folks past and present) have to say on this issue. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix
On Wed, 4 Oct 2006, [EMAIL PROTECTED] wrote: This patchset includes an update to the NetLabel/secid-reconciliation patch, replacing my v3 patch from earlier this week, and a bugfix patch to cure a race condition found during testing this week. The bugfix patch does not rely on the secid patches and should be merged regardless as it fixes a bug which has been around since the very first NetLabel patches (not sure why I didn't see this sooner). So, patch 2/2 should go in on it's own against upstream? If so, in 5B future, please post such patches separately. As for the rest of the network labeling, please work together with Venkat and the SELinux developers on a final patchset which meets all of the design goals and has been tested, with policy which has been merged upstream and is available via Fedora devel. Please keep the discussion going, but ensure that the final patchset for review and merge consideration is a complete set against the current git kernel coming from one person. Thanks, - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix
As for the rest of the network labeling, please work together with Venkat and the SELinux developers on a final patchset which meets all of the design goals and has been tested, with policy which has been merged upstream and is available via Fedora devel. Please keep the discussion going, but ensure that the final patchset for review and merge consideration is a complete set against the current git kernel coming from one person. I'm trying :) When I posted the NetLabel secid support patch last week I asked Venkat if he could merge it with the main secid patchset (due to size and dependencies that seemed like the most reasonable course of action). For reasons I'm not aware of he chose not to. FYI- I am no NetLabel expert, and the pathset I sent out that day included the peersid changes. And since you were going to have to post a patch for that again, I thought it best you ported and reposted the entire patch again. As a result I keep posting updated patches backed against Venkat's latest and incorporating the latest feedback. And let's keep this going like this on the selinux list. When all the testing is done and selinux ok's the patchsets, I will combine them and send them onto netdev. How does that sound? Venkat, can you please merge the latest my latest NetLabel secid support patch in with your next release? I would, but it currently is premature. As James says, let's get policy done, the design proven, and tested and then we will go to netdev with one patchset. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/2] NetLabel: secid reconciliation support
* XFRM present xfrm_sid = full context from xfrm loc_sid = SECINITSID_NETMSG nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged * NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECINITSID_NETMSG te ctx, netlabel mls ctx ext_sid = nlbl_sid final skb-secmark = avc_ok : ext_sid ? unchanged I was referring to the differences in what getpeercon would return in the above 2 scenarios. In the xfrm case: final skb-secmark would be 0 resulting in getpeercon to return EPROTONOOPT In the NetLabel case: final skb-secmark would be network_t resulting in getpeercon to return network_t * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged This has implications for getpeercon() where it would - fail with ENOPROTOOPT (xfrm case) - returns network_t (netlabel) I would still argue that the nature of the domain being carried by the packet is still unlabeled_t as implied by the null secmark. While I view secmark/point as specifying BOTH a flow control point and a default domain (incidentally using the same label more because of implementation constrainst), I view network_t as purely a flow control point. But I also realize there can be equally forceful arguments for what this patch does. I know the two of us have talked about this before on the mail lists, but I don't believe anyone else has ever made a comment in this regard. I tend to feel rather strongly that when using just NetLabel on a connection you shouldn't see an unlabeled_t type as I feel that the connotation associated with this type is misleading, even though from a TE point of view there may be an argument made that it is appropriate. What does the community think? We need to resolve it one way or the other unless the above differences in behavior are desired or somehow accounted for in policy and apps. I agree - I'd like to hear what others (namely Stephen Smalley, James Morris and all of the Tresys folks past and present) have to say on this issue. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: fix multicast with 32 groups
On Fri, 2006-09-29 at 17:53 -0400, Bill Helfinstine wrote: The b44 driver has a bug where if there are more than B44_MCAST_TABLE_SIZE groups in the dev-mc_list, it will only listen to the first B44_MCAST_TABLE_SIZE that it sees. This patch makes the driver go into RXCONFIG_ALLMULTI mode if there are more than B44_MCAST_TABLE_SIZE groups being subscribed to. This patch is against 2.6.18, b44.c version 1.01. Signed-off-by: Bill Helfinstine [EMAIL PROTECTED] diff --git a/drivers/net/b44.c b/drivers/net/b44.c index e891ea2..dd024e1 100644 --- a/drivers/net/b44.c +++ b/drivers/net/b44.c @@ -1706,7 +1706,8 @@ static void __b44_set_rx_mode(struct net __b44_set_mac_addr(bp); - if (dev-flags IFF_ALLMULTI) + if ((dev-flags IFF_ALLMULTI) || + (dev-mc_count B44_MCAST_TABLE_SIZE)) val |= RXCONFIG_ALLMULTI; else i = __b44_load_mcast(bp, dev); It looks good to me, however, I'll have to nack it as this patch has spaces and will not apply. Please convert the spaces to tabs. Thanks, Gary - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/2] NetLabel: secid reconciliation support
* XFRM present xfrm_sid = full context from xfrm loc_sid = SECINITSID_NETMSG nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged Actually, I meant to cite the following instead of the above: * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged * NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECINITSID_NETMSG te ctx, netlabel mls ctx ext_sid = nlbl_sid final skb-secmark = avc_ok : ext_sid ? unchanged I was referring to the differences in what getpeercon would return in the above 2 scenarios. In the xfrm case: final skb-secmark would be 0 resulting in getpeercon to return EPROTONOOPT In the XFRM present case above if the access is allowed (avc_ok is true) then the final skb-secmark value is going to be set to the value of ext_sid which is the xfrm_sid. Any calls made to getpeercon() would return success with the context matching xfrm_sid. You are right, but I was actually referring to the Nothing case above. I have a hunch we are still on different pages here ... In the NetLabel case: final skb-secmark would be network_t resulting in getpeercon to return network_t Yep, and I understand you would like to see it as unlabeled_t. I think we both have valid arguments for either case and we are just waiting to hear from others. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix
Venkat Yekkirala wrote: As for the rest of the network labeling, please work together with Venkat and the SELinux developers on a final patchset which meets all of the design goals and has been tested, with policy which has been merged upstream and is available via Fedora devel. Please keep the discussion going, but ensure that the final patchset for review and merge consideration is a complete set against the current git kernel coming from one person. I'm trying :) When I posted the NetLabel secid support patch last week I asked Venkat if he could merge it with the main secid patchset (due to size and dependencies that seemed like the most reasonable course of action). For reasons I'm not aware of he chose not to. FYI- I am no NetLabel expert, and the pathset I sent out that day included the peersid changes. And since you were going to have to post a patch for that again, I thought it best you ported and reposted the entire patch again. I'm not talking about the peer_sid changes, although I'm glad they are part of the secid patchset - thank you. I'm talking about the patch I keep reposting to include NetLabel is the secid reconciliation path. There was a secid patchset posted on Thursday (9/28) night, I posted the a patch on Friday (9/29) to provide NetLabel support. There was a secid patchset posted on Sunday (10/1) night, I respun the NetLabel support patch on Monday (10/2) - v2. I respun the NetLabel support patch to take into account Stephen Smalley's comments on Monday (10/2) - v3. There was a small update to the secid patches yesterday (10/3) so I respun the NetLabel support patch (10/4) - v4. As a result I keep posting updated patches backed against Venkat's latest and incorporating the latest feedback. And let's keep this going like this on the selinux list. When all the testing is done and selinux ok's the patchsets, I will combine them and send them onto netdev. How does that sound? Yes, the discussion is a good one I don't want to disrupt that. I would prefer if all of the patches were in one patchset, pushed out by one person as that would save me from having to respin my patch if all I need to do is update it for the latest secid patches. I think that has value so people can review/test/etc all of the parts as one coherent patchset. However, it's ultimately up to you as you are the one working on the main secid patchset. Venkat, can you please merge the latest my latest NetLabel secid support patch in with your next release? I would, but it currently is premature. As James says, let's get policy done, the design proven, and tested and then we will go to netdev with one patchset. I think it's easier to decide on policy, review the design, and test it all if there is one place/patchset with all of the latest bits/patches. Right not it's not that easy with different patches scattered around. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] NetLabel: secid reconciliation support
On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: Venkat Yekkirala wrote: * XFRM present xfrm_sid = full context from xfrm loc_sid = SECINITSID_NETMSG nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged * NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECINITSID_NETMSG te ctx, netlabel mls ctx ext_sid = nlbl_sid final skb-secmark = avc_ok : ext_sid ? unchanged I was referring to the differences in what getpeercon would return in the above 2 scenarios. In the xfrm case: final skb-secmark would be 0 resulting in getpeercon to return EPROTONOOPT In the XFRM present case above if the access is allowed (avc_ok is true) then the final skb-secmark value is going to be set to the value of ext_sid which is the xfrm_sid. Any calls made to getpeercon() would return success with the context matching xfrm_sid. I have a hunch we are still on different pages here ... In the NetLabel case: final skb-secmark would be network_t resulting in getpeercon to return network_t Yep, and I understand you would like to see it as unlabeled_t. I think we both have valid arguments for either case and we are just waiting to hear from others. I don't understand the argument for network_t, and it seems to violate our goals of 1) having consistent policy regardless of network labeling mechanism, and 2) having getpeercon() always return a subject label that can be used as a basis for avc_has_perm() and setexeccon() calls. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/2] NetLabel: secid reconciliation support
On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: Venkat Yekkirala wrote: * XFRM present xfrm_sid = full context from xfrm loc_sid = SECINITSID_NETMSG nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged As noted subsequently, I actually meant to refer to the below instead of the XFRM case above: * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb-secmark = avc_ok : ext_sid ? unchanged * NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECINITSID_NETMSG te ctx, netlabel mls ctx ext_sid = nlbl_sid final skb-secmark = avc_ok : ext_sid ? unchanged I was referring to the differences in what getpeercon would return in the above 2 scenarios. In the xfrm case: final skb-secmark would be 0 resulting in getpeercon to return EPROTONOOPT In the XFRM present case above if the access is allowed (avc_ok is true) then the final skb-secmark value is going to be set to the value of ext_sid which is the xfrm_sid. Any calls made to getpeercon() would return success with the context matching xfrm_sid. I have a hunch we are still on different pages here ... In the NetLabel case: final skb-secmark would be network_t resulting in getpeercon to return network_t Yep, and I understand you would like to see it as unlabeled_t. I think we both have valid arguments for either case and we are just waiting to hear from others. I don't understand the argument for network_t, and it seems to violate our goals of 1) having consistent policy regardless of network labeling mechanism, and 2) having getpeercon() always return a subject label that can be used as a basis for avc_has_perm() and setexeccon() calls. But in the case where there's no domain info, but a cipso label, getpeercon will fail (EPROTONOOPT). Do I rememember that Paul was trying to use a special SID to use as a base sid in this case? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prism54: wpa support for fullmac cards
On Wed, Oct 04, 2006 at 04:12:26PM +0200, [EMAIL PROTECTED] wrote: the AP code never worked. And the hostapd-ioctl interface was designed for prism2/2.5/3 cards, but not for fullmac prism54. What do you mean by never working? I have seen fullmac Prism54 completing WPA authentication with hostapd.. This was using the driver_prism54.c in hostapd, not the Host AP driver interface. (BTW, hostapd's backend for prism54 uses a proprietary interface - PIMFOR -, which never made it into the kernel.) But it worked in the external driver. So yes, saying that the version in kernel tree never worked in AP mode would probably be valid. And as far as the WEXT interface in hostapd is concerned, no, there is no such thing yet. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wext
On Wed, Oct 04, 2006 at 10:37:23AM +0200, Johannes Berg wrote: On Mon, 2006-10-02 at 19:55 +0200, [EMAIL PROTECTED] wrote: This patch (wext-patch) is a proposal. It adds two new defines for the SIOCSIWMLME to cover all kinds MLMEs (well, except REASSOC) through a ioctl. (it would be nice to have them, so that I can post the hostapd code for the prism54 card!) NACK from me. Please help me work on nl80211 instead :) SIOCSIWMLME was designed to allow additional MLME commands to be added. IMHO, a potential replacement in the future should not prevent us from extending WEXT at this point and stop all changes in something that is currently available. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take19 1/4] kevent: Core files.
On 10/3/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c http://tservice.net.ru/~s0mbre/archive/kevent/evtest.c These are simple programs which by themselves have problems. For instance, I consider a very bad idea to hardcode the size of the ring buffer. Specifying macros in the header file counts as hardcoding. Systems grow over time and so will the demand of connections. I have no problem with the kernel hardcoding the value internally (or having a /proc entry to select it) but programs should be able to dynamically learn about the value so they don't have to be recompiled. But more problematic is that I don't see how the interfaces can be efficiently used in multi-threaded (or multi-process) programs. How would multiple threads using the same kevent queue and running in the same kevent_get_events() loop work out? How do they guarantee that each request is only handled once? From what I see now this means a second data structure is needed to keep track of the state of each entry. But even then, how do we even recognized used ring buffer entries? For instance, assume two threads. Both call get_events, one event is reported, both threads are woken up (which is another thing to consider, more later). One thread uses ring buffer entry, the other goes back to sleep in get_events. Now, how does the kernel know when the other thread is done working on the ring buffer entry? There might be lots of entries coming in overflowing the entire buffer. Heck, you don't even need two threads for this scenario. When I was thinking about this (and discussing it in Ottawa) I was always assuming that we have a status field in the ring buffer entry which lets the userlevel code indicate whether the entry is free again or not. This requires a writable mapping, yes, and potentially causes cache line ping-pong. I think Zach mentioned he has some ideas about this. As for the multiple thread wakeup, I mentioned this before. We have to avoid the trampling herd problem. We cannot wakeup all waiters. But we also cannot assume that, without protocols, waking up just one for each available entry is sufficient. So the first question is: what is the current policy? AIO was removed from patchset by request of Cristoph. Timers, network AIO, fs AIO, socket nortifications and poll/select events work well with existing structures. Well, excuse me if I don't take your word for it. I agree, the AIO code should not be submitted along with this. The same for any other code using the event handling. But we need to check whether the interface is generic enough to accomodate them in a way which actually makes sense. Again, think highly threaded processes or multiple processes sharing the same event queue. It is even possible to create variable sized kevents - each kevent contain pointer to user's data, which can be considered as pointer to additional area (it's size kernel implementation for given kevent type can determine from other parameters or use predefined one and fetch additional data in -enqueue() callback). That sounds interesting and certainly helps with securing the interface for the future. But if there is anything we can do to avoid unnecessary costs we should do it, even if this means investigation all this further. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm3 oops in xfrm_register_mode
On Wed, 2006-10-04 at 09:57 -0700, Andrew Morton wrote: You might well find this bisection lands you on origin.patch. ie: a mainline bug. I note that David merged a few more xfrm fixes this morning. So to confirm that, first test just origin.patch and if that fails, test git-of-the-moment. If that doesn't fail, they fixed it. origin.patch from --m3 failed. Unfortunately so did a fresh clone of Linus's git tree. -- Steve Fox IBM Linux Technology Center - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LARTC] [ANNOUNCE] iproute2-2.6.18-061002
Stephen Hemminger wrote: This is a much delayed update to the iproute2 command set. It can be downloaded from: http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.18-061002.tar.gz Thanks! Are there any plans to merge the ip arp patches at http://www.ssi.bg/~ja/#iparp ? Apologies if this has already been rejected before. Searching the archives I couldn't find such a discussion. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LARTC] [ANNOUNCE] iproute2-2.6.18-061002
On Wed, 04 Oct 2006 23:34:24 +0200 Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: This is a much delayed update to the iproute2 command set. It can be downloaded from: http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.18-061002.tar.gz Thanks! Are there any plans to merge the ip arp patches at http://www.ssi.bg/~ja/#iparp ? Apologies if this has already been rejected before. Searching the archives I couldn't find such a discussion. Regards, Carl-Daniel When the kernel patches were accepted by the mainline kernel, then I'll update iproute2. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix
On Wed, 4 Oct 2006, Paul Moore wrote: So, patch 2/2 should go in on it's own against upstream? If so, in 5B future, please post such patches separately. Yes, please commit patch 2/2 regardless as it fixes a bug which is not dependent on any of the secid patches which are being discussed. My apologies for including it in the same patchset, I'll be sure to split it up next time. Applied. http://git.infradead.org/?p=users/jmorris/selinux-2.6.git (This repo may move soon). -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Network Events Connector
David Miller [EMAIL PROTECTED] writes: From: Samir Bellabes [EMAIL PROTECTED] Date: Mon, 02 Oct 2006 08:11:06 +0200 This patch adds a connector which reports networking's events to userspace. It's sending events when a sock has its sk_state changed to : - LISTEN or CLOSE for DCCP and TCP - BIND or CLOSE for UDP. You can do this with the security layer, netfilter's ULOG, or even the netfilter connection tracking netlink sockets. That's 3 facilities by which you can accomplish this, and if none of them are perfect, add the small modifications you need to one of them to make them usable for your task. It makes no sense to add new facilities just for this. I see, i will look futher the netfilter conntrack netlink sockets in order to merge my code into it. thanks for comments. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Network Events Connector
Evgeniy Polyakov [EMAIL PROTECTED] writes: On Mon, Oct 02, 2006 at 02:57:55PM +0200, Samir Bellabes ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov [EMAIL PROTECTED] writes: On Mon, Oct 02, 2006 at 08:11:06AM +0200, Samir Bellabes ([EMAIL PROTECTED]) wrote: You can also extend your module to be more generic and send all (or just requested in config) state changes for all protocols (or those checked in config). Ok, so the next step now is to target all state changes for all protocols, *but* send only the states asked dynamically from the userspace, using the userspace-to-kernel's way of the netlink. What do you think about that ? Btw, you could also create netlink/connector based firewall rules update, I think people with hundreds of rules in one table will bless you after that. This is the real goal, using ipset - http://ipset.netfilter.org/ With this we can easily create a uniq rule for iptables, and then add/remove port from the 'set' involve. It is not the same as create and update existing rules. I think hipac project uses feature of fast rules update. It is quite major break for existing iptables, but it should be eventually done... Ok now i understand clearly your point. But we are a bit far from the initial idea, even if it could be really good to do that. First, let's code the initial idea. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Wed, 04 Oct 2006 11:41:59 -0500 Steve Fox [EMAIL PROTECTED] wrote: On Wed, 2006-10-04 at 08:45 -0700, Andrew Morton wrote: On Wed, 04 Oct 2006 08:42:28 -0500 Steve Fox [EMAIL PROTECTED] wrote: Sorry for the delay. I was finally able to perform a bisect on this. It turns out the patch that causes this is x86_64-mm-re-positioning-the-bss-segment.patch, which seems like a strange candidate, but sure enough I can boot to login: right up until that patch is applied. hm, that patch was merged into mainline September 29. Does mainline work? -git21 also fails with this same error. OK, thanks. And we know that x86_64-mm-re-positioning-the-bss-segment.patch triggered this failure. And that patch is non-buggy, and the xfrm code is probably non-buggy. So we don't know squat, and we're going to need to debug this crash. Well. There is one trick we could use: apply x86_64-mm-re-positioning-the-bss-segment.patch to 2.6.18 base and see if it crashes. If it doesn't, then we can theorise that the bug is some buggy post 2.6.18 patch which is being exposed by x86_64-mm-re-positioning-the-bss-segment.patch. A technique I've used before for identifying the buggy patch is to do a git-bisect, but apply x86_64-mm-re-positioning-the-bss-segment.patch by hand at each bisection step. It's pretty straightforward as long as the patch roughly applies at each step. Or we could debug it. Can you send the .config? Let's see if it happens with my toolchain+machine first. Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On Wed, Oct 04, 2006 at 05:06:59PM -0700, Andrew Morton wrote: On Wed, 04 Oct 2006 11:41:59 -0500 Steve Fox [EMAIL PROTECTED] wrote: On Wed, 2006-10-04 at 08:45 -0700, Andrew Morton wrote: On Wed, 04 Oct 2006 08:42:28 -0500 Steve Fox [EMAIL PROTECTED] wrote: Sorry for the delay. I was finally able to perform a bisect on this. It turns out the patch that causes this is x86_64-mm-re-positioning-the-bss-segment.patch, which seems like a strange candidate, but sure enough I can boot to login: right up until that patch is applied. hm, that patch was merged into mainline September 29. Does mainline work? -git21 also fails with this same error. OK, thanks. And we know that x86_64-mm-re-positioning-the-bss-segment.patch triggered this failure. And that patch is non-buggy, and the xfrm code is probably non-buggy. So we don't know squat, and we're going to need to debug this crash. Well. There is one trick we could use: apply x86_64-mm-re-positioning-the-bss-segment.patch to 2.6.18 base and see if it crashes. If it doesn't, then we can theorise that the bug is some buggy post 2.6.18 patch which is being exposed by I think most likely it would crash on 2.6.18. Keith mannthey had reported a different crash on 2.6.18-rc4-mm2 when this patch was introduced first time. Following is the link to the thread. http://marc.theaimsgroup.com/?l=linux-kernelm=115629369729911w=2 Following is the backtrace he had reported. Unable to handle kernel NULL pointer dereference at 0007 RIP: [803d45b0] __unix_insert_socket+0x49/0x5a PGD 115c934067 PUD 115c935067 PMD 0 Oops: 0002 [1] SMP last sysfs file: CPU 14 Modules linked in: Pid: 1, comm: init Not tainted 2.6.18-rc4-mm2-smp #3 RIP: 0010:[803d45b0] [803d45b0] __unix_insert_socket+0x49/0x5a RSP: 0018:810460605eb8 EFLAGS: 00010286 RAX: RBX: 81115c171c80 RCX: RDX: 81115c171c88 RSI: 81115c171c80 RDI: 806656e0 RBP: 806656e0 R08: 81115c069200 R09: 8110700b4000 R10: R11: 0002 R12: 81115c170d00 R13: 0001 R14: 0001 R15: FS: 2b793a4fd6d0() GS:81115c910e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0007 CR3: 00115c92d000 CR4: 06e0 Process init (pid: 1, threadinfo 810460604000, task 81115cb10040) Stack: 00010001 81115c171c80 803d58e9 8045bb30 000180298f61 80498080 0001 81115c170d00 803d595d 0004 80376061 Call Trace: [803d58e9] unix_create1+0xf3/0x107 [803d595d] unix_create+0x60/0x6b [80376061] __sock_create+0x12f/0x227 [80376429] sys_socket+0xf/0x37 [8020968e] system_call+0x7e/0x83 Code: 48 89 50 08 48 89 55 00 48 89 6a 08 41 58 5b 5d c3 c7 47 08 RIP [803d45b0] __unix_insert_socket+0x49/0x5a RSP 810460605eb8 CR2: 0007 0Kernel panic - not syncing: Attempted to kill init! Thanks Vivek - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
I think most likely it would crash on 2.6.18. Keith mannthey had reported a different crash on 2.6.18-rc4-mm2 when this patch was introduced first time. Following is the link to the thread. Then maybe trying 2.6.17 + the patch and then bisect between that and -rc4? -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm2 boot failure on x86-64
On 10/4/06, Martin Bligh [EMAIL PROTECTED] wrote: Andi Kleen wrote: I think most likely it would crash on 2.6.18. Keith mannthey had reported a different crash on 2.6.18-rc4-mm2 when this patch was introduced first time. Following is the link to the thread. Then maybe trying 2.6.17 + the patch and then bisect between that and -rc4? I think it's fixed already in -git22, or at least it is for the IBM box reporting to test.kernel.org. You might want to try that one ... Fixed or hidden... hard to say at this point. I think it could be a werid interaction between patches and or config options. I will see tommorrow if I can recreate again. Thanks, Keith - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Disable addrconf on ~multicast interfaces?
Hi Yoshifuji-san:
Are there any non-multicast interfaces that require addrconf?
In other words, what does the following patch break :)
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2130,6 +2130,9 @@ static void addrconf_dev_config(struct n
return;
}
+ if (!(dev-flags IFF_MULTICAST))
+ return;
+
idev = addrconf_add_dev(dev);
if (idev == NULL)
return;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
