[PATCH] IPSec anti-replay sequence numbers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
IPSec uses sequence numbers to protect against replay attacks.
So far there is no way to get or set these sequence numbers in the kernel.
The attached patches will remedy these issues. Any comments are
welcome! :)
I would be pleased if at least 2.6.13-rc3_ipsec_pfkey_seqnr.diff and
2.6.13-rc3_ipsec_xfrm_seqnr.diff find there way in the vanilla kernel.
Best regards
Ulrich
2.6.13-rc3_ipsec_pfkey_seqnr.diff:
Get sequence numbers over the pf_key interface. Command "setkey -D".
Credits go to Hiroyuki YAMAMORI
(http://www.linux-ipv6.org/ml/usagi-users/msg02909.html)
2.6.13-rc3_ipsec_xfrm_seqnr.diff:
Get sequence numbers over the XFRM/Netlink interface. Therefore a new
XFRM attribute
(XFRMA_REPLAY) is added every SA dump. Please see
iproute2-2.6.11-050330_XFRMA_REPLAY.diff
to use with "ip -s xfrm state".
2.6.13-rc3_ipsec_set_xfrm_seqnr.diff:
For IPSec HA solutions it is necessary to be informed about sequence
number changes
and to set the sequence number counter of installed SAs. Therefore a
new XFRM group
(XFRMGRP_REPLAY) was added with a new XFRM message type XFRM_MSG_UPDSEQ.
These XFRM_MSG_UPDSEQ messages can be used to inform in intervals
about changed
sequence numbers (an inbound and outbound interval is used, set via
sysctl) and
to set sequence numbers of installed SAs. In addition, it is possible
to install SAs with
an given XFRMA_REPLAY attribute as initial sequence number value.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC23uH22t2oTuElzoRAvUyAKCkGSwFnqOjs6RnAI9IoZyd9Zk0mgCdGbuB
iIvA8vPtWJ0htDiaIxJ6mls=
=4f66
-END PGP SIGNATURE-
diff -Nru linux-2.6.13-rc3.org/net/key/af_key.c linux-2.6.13-rc3/net/key/af_key.c
--- linux-2.6.13-rc3.org/net/key/af_key.c 2005-07-18 10:24:12.0 +0200
+++ linux-2.6.13-rc3/net/key/af_key.c 2005-07-18 10:47:15.0 +0200
@@ -868,7 +868,7 @@
sa2->sadb_x_sa2_mode = x->props.mode + 1;
sa2->sadb_x_sa2_reserved1 = 0;
sa2->sadb_x_sa2_reserved2 = 0;
- sa2->sadb_x_sa2_sequence = 0;
+ sa2->sadb_x_sa2_sequence = x->replay.seq ? x->replay.seq : x->replay.oseq;
sa2->sadb_x_sa2_reqid = x->props.reqid;
if (natt && natt->encap_type) {
diff -Nru linux-2.6.13-rc3.org/include/linux/sysctl.h linux-2.6.13-rc3/include/linux/sysctl.h
--- linux-2.6.13-rc3.org/include/linux/sysctl.h 2005-07-18 10:24:11.0 +0200
+++ linux-2.6.13-rc3/include/linux/sysctl.h 2005-07-18 10:49:54.0 +0200
@@ -253,6 +253,8 @@
NET_CORE_DEV_WEIGHT=17,
NET_CORE_SOMAXCONN=18,
NET_CORE_BUDGET=19,
+ NET_CORE_XFRM_SEQDIFF_IN=20,
+ NET_CORE_XFRM_SEQDIFF_OUT=21,
};
/* /proc/sys/net/ethernet */
diff -Nru linux-2.6.13-rc3.org/include/linux/xfrm.h linux-2.6.13-rc3/include/linux/xfrm.h
--- linux-2.6.13-rc3.org/include/linux/xfrm.h 2005-07-18 10:49:43.0 +0200
+++ linux-2.6.13-rc3/include/linux/xfrm.h 2005-07-18 10:49:54.0 +0200
@@ -140,6 +140,9 @@
XFRM_MSG_FLUSHPOLICY,
#define XFRM_MSG_FLUSHPOLICY XFRM_MSG_FLUSHPOLICY
+ XFRM_MSG_UPDSEQ,
+#define XFRM_MSG_UPDSEQ XFRM_MSG_UPDSEQ
+
__XFRM_MSG_MAX
};
#define XFRM_MSG_MAX (__XFRM_MSG_MAX - 1)
@@ -263,5 +266,6 @@
#define XFRMGRP_EXPIRE 2
#define XFRMGRP_SA 4
#define XFRMGRP_POLICY 8
+#define XFRMGRP_REPLAY 16
#endif /* _LINUX_XFRM_H */
diff -Nru linux-2.6.13-rc3.org/include/net/xfrm.h linux-2.6.13-rc3/include/net/xfrm.h
--- linux-2.6.13-rc3.org/include/net/xfrm.h 2005-07-18 10:24:11.0 +0200
+++ linux-2.6.13-rc3/include/net/xfrm.h 2005-07-18 10:49:54.0 +0200
@@ -134,6 +134,9 @@
/* State for replay detection */
struct xfrm_replay_state replay;
+ /* Replay detection state at the time we sent the last notification */
+ struct xfrm_replay_state preplay;
+
/* Statistics */
struct xfrm_stats stats;
@@ -301,6 +304,11 @@
struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH];
};
+/* which seqno */
+#define XFRM_REPLAY_INBOUND 1
+#define XFRM_REPLAY_OUTBOUND 2
+#define XFRM_REPLAY_BOUND_MASK 3
+
#define XFRM_KM_TIMEOUT 30
struct xfrm_mgr
@@ -312,6 +320,7 @@
struct xfrm_policy *(*compile_policy)(u16 family, int opt, u8 *data, int len, int *dir);
int (*new_mapping)(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport);
int (*notify_policy)(struct xfrm_policy *x, int dir, struct km_event *c);
+ int (*notify_seq)(struct xfrm_state *x, u32, u32);
};
extern int xfrm_register_km(struct xfrm_mgr *km);
@@ -838,6 +847,8 @@
extern void xfrm_state_flush(u8 proto);
extern int xfrm_replay_check(struct xfrm_state *x, u32 seq);
extern void xfrm_replay_advance(struct xfrm_state *x, u32 seq);
+extern void xfrm_replay_notify(struct xfrm_state *x, int event);
+extern void xfrm_state_replay_update(struct xfrm_state *x, struct xfrm_replay_state *replay);
extern int xfrm_state_check(struct xfrm_state *x, struct sk_buff *skb);
extern int xfrm_state_mtu(struct xfrm_state *x, int mtu);
extern int xfrm_init_state(struct xfrm_
[PATCH] [PKT_SCHED]: Remove debugging leftover from textsearch ematch
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/sched/em_text.c
===
--- net-2.6.orig/net/sched/em_text.c2005-06-24 13:17:08.0 +0200
+++ net-2.6/net/sched/em_text.c 2005-07-17 19:33:30.0 +0200
@@ -55,9 +55,6 @@
struct ts_config *ts_conf;
int flags = 0;
- printk("Configuring text: %s from %d:%d to %d:%d len %d\n", conf->algo,
conf->from_offset,
- conf->from_layer, conf->to_offset, conf->to_layer,
conf->pattern_len);
-
if (len < sizeof(*conf) || len < (sizeof(*conf) + conf->pattern_len))
return -EINVAL;
-
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] [PKT_SCHED]: Reduce branch mispredictions in pfifo_fast_dequeue
The current call to __qdisc_dequeue_head leads to a branch
misprediction for every loop iteration, the fact that the
most common priority is 2 makes this even worse. This issue
has been brought up by Eric Dumazet <[EMAIL PROTECTED]>
but unlike his solution which was to manually unroll the loop,
this approach preserves the possibility to increase the number
of bands at compile time.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/sched/sch_generic.c
===
--- net-2.6.orig/net/sched/sch_generic.c2005-07-06 15:26:47.0
+0200
+++ net-2.6/net/sched/sch_generic.c 2005-07-17 20:27:56.0 +0200
@@ -331,11 +331,10 @@
int prio;
struct sk_buff_head *list = qdisc_priv(qdisc);
- for (prio = 0; prio < PFIFO_FAST_BANDS; prio++, list++) {
- struct sk_buff *skb = __qdisc_dequeue_head(qdisc, list);
- if (skb) {
+ for (prio = 0; prio < PFIFO_FAST_BANDS; prio++) {
+ if (!skb_queue_empty(list + prio)) {
qdisc->q.qlen--;
- return skb;
+ return __qdisc_dequeue_head(qdisc, list + prio);
}
}
-
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] IPSec anti-replay sequence numbers
Ulrich Weber schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
IPSec uses sequence numbers to protect against replay attacks.
So far there is no way to get or set these sequence numbers in the kernel.
The attached patches will remedy these issues. Any comments are
welcome! :)
I would be pleased if at least 2.6.13-rc3_ipsec_pfkey_seqnr.diff and
2.6.13-rc3_ipsec_xfrm_seqnr.diff find there way in the vanilla kernel.
Some comments:
+#define XFRM_REPLAY_BOUND_MASK 3
This is unnecessary.
@@ -312,6 +320,7 @@
struct xfrm_policy *(*compile_policy)(u16 family, int opt, u8
*data, int len, int *dir);
int (*new_mapping)(struct xfrm_state *x,
xfrm_address_t *ipaddr, u16 sport);
int (*notify_policy)(struct xfrm_policy *x, int
dir, struct km_event *c);
+ int (*notify_seq)(struct xfrm_state *x, u32, u32);
Please do this consistently. Either add the argument names, or don't.
+void km_replay_notify(struct xfrm_state *);
extern
+#ifdef CONFIG_XFRM
+extern u32 sysctl_xfrm_seqdiff_in;
+extern u32 sysctl_xfrm_seqdiff_out;
+#endif /* CONFIG_XFRM */
Sysctls are a bad idea for this. The replay window is a per-state
parameter, so the diff should be too.
+void xfrm_state_replay_update(struct xfrm_state *x, struct xfrm_replay_state
*replay)
+{
+ spin_lock(&x->lock);
You need spin_lock_bh here.
+ memcpy(&x->replay, replay, sizeof(*replay));
+ memcpy(&x->preplay, replay, sizeof(*replay));
+ spin_unlock(&x->lock);
+}
+EXPORT_SYMBOL(xfrm_state_replay_update);
There's no external user. Why is this exported?
+ if(pid == 0)
+ {
+ NETLINK_CB(skb).dst_groups = XFRMGRP_REPLAY;
+ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_REPLAY,
GFP_ATOMIC);
+ }
+ else
Missing whitespace and incorrect placed braces
+static int xfrm_update_seq(struct sk_buff *skb, struct nlmsghdr *nlh, void
**xfrma)
+{
+ struct xfrm_state *x;
+ struct xfrm_usersa_id *p = NLMSG_DATA(nlh);
+ struct xfrm_replay_state *replay;
+ struct rtattr *rt = xfrma[XFRMA_REPLAY-1];
+
+ x = xfrm_state_lookup(&p->daddr, p->spi, p->proto, p->family);
+ if (x == NULL) {
+ printk(KERN_INFO "Found no xfrm state for sa seq update\n");
Please remove this debugging stuff
+ return -ESRCH;
+ }
+
+ if( xfrma[XFRMA_REPLAY-1] != NULL && (rt->rta_len == (sizeof(struct
xfrm_replay_state) + sizeof(struct rtattr {
Whitespace broken, too long line
+ replay = RTA_DATA(xfrma[XFRMA_REPLAY - 1]);
+ xfrm_state_replay_update(x, replay);
+ xfrm_state_put(x);
+ }
+ else {
+ xfrm_send_replay_notify(x, nlh->nlmsg_pid, nlh->nlmsg_seq);
xfrm_state leak
Regards
Patrick
-
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 1/2] LSM-IPSec Networking Hooks -- authorizing flow_cache_entry's
This patch adds LSM hooks to the XFRM subsystem code. This patch
differs from previous ones in that an authorizer function pointer
is passed to flow_cache_lookup in order to use LSM to authorize
previously cached entries -- as suggested in my reply to Herbert.
This approach is consistent with how the XFRM subsystem defines
the type of objects cached by passing a resolver function pointer.
Thus, the flow_cache_lookup code remains agnostic to the type of
object cached.
Regards,
Trent.
This patch series implements per packet access control via the
extension of the Linux Security Modules (LSM) interface by hooks in
the XFRM and pfkey subsystems that leverage IPSec security
associations to label packets. Extensions to the SELinux LSM are
included that leverage the patch for this purpose.
This patch implements the changes necessary to the XFRM subsystem,
pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a
socket to use only authorized security associations (or no security
association) to send/receive network packets.
Patch purpose:
The patch is designed to enable access control per packets based on
the strongly authenticated IPSec security association. Such access
controls augment the existing ones based on network interface and IP
address. The former are very coarse-grained, and the latter can be
spoofed. By using IPSec, the system can control access to remote
hosts based on cryptographic keys generated using the IPSec mechanism.
This enables access control on a per-machine basis or per-application
if the remote machine is running the same mechanism and trusted to
enforce the access control policy.
Patch design approach:
The overall approach is that policy (xfrm_policy) entries set by
user-level programs (e.g., setkey for ipsec-tools) are extended with a
security context that is used at policy selection time in the XFRM
subsystem to restrict the sockets that can send/receive packets via
security associations (xfrm_states) that are built from those
policies.
A presentation available at
www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf
from the SELinux symposium describes the overall approach.
Patch implementation details:
On output, the policy retrieved (via xfrm_policy_lookup or
xfrm_sk_policy_lookup) must be authorized for the security context of
the socket and the same security context is required for resultant
security association (retrieved or negotiated via racoon in
ipsec-tools). This is enforced in xfrm_state_find.
On input, the policy retrieved must also be authorized for the socket
(at __xfrm_policy_check), and the security context of the policy must
also match the security association being used.
The patch has virtually no impact on packets that do not use IPSec.
The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as
before.
Also, if IPSec is used without security contexts, the impact is
minimal. The LSM must allow such policies to be selected for the
combination of socket and remote machine, but subsequent IPSec
processing proceeds as in the original case.
Testing:
The pfkey interface is tested using the ipsec-tools. ipsec-tools have
been modified (a separate ipsec-tools patch is available for version
0.5) that supports assignment of xfrm_policy entries and security
associations with security contexts via setkey and the negotiation
using the security contexts via racoon.
The xfrm_user interface is tested via ad hoc programs that set
security contexts. These programs are also available from me, and
contain programs for setting, getting, and deleting policy for testing
this interface. Testing of sa functions was done by tracing kernel
behavior.
---
include/linux/pfkeyv2.h | 13 +++
include/linux/security.h | 119
include/linux/xfrm.h | 29
include/net/flow.h |8 +-
include/net/xfrm.h | 29 +++-
net/core/flow.c | 10 +-
net/ipv4/xfrm4_policy.c |2
net/ipv6/xfrm6_policy.c |2
net/key/af_key.c | 162 ++--
net/xfrm/xfrm_policy.c | 79 +
net/xfrm/xfrm_state.c| 16 +++-
net/xfrm/xfrm_user.c | 170 +--
security/Kconfig | 13 +++
security/dummy.c | 37 ++
14 files changed, 632 insertions(+), 57 deletions(-)
diff -puN include/linux/pfkeyv2.h~lsm-xfrm-nethooks include/linux/pfkeyv2.h
--- linux-2.6.13-rc3-git4-xfrm/include/linux/pfkeyv2.h~lsm-xfrm-nethooks
2005-07-18 12:11:01.0 -0400
+++ linux-2.6.13-rc3-git4-xfrm-root/include/linux/pfkeyv2.h 2005-07-18
12:11:01.0 -0400
@@ -216,6 +216,16 @@ struct sadb_x_nat_t_port {
} __attribute__((packed));
/* sizeof(struct sadb_x_nat_t_port) == 8 */
+/* Generic LSM security context */
+struct sadb_x_sec_ctx {
+ uint16_tsadb_x_sec_len;
+ uint16_tsadb_x
peculiar messages
L.S., After an upgrade from 2.6.11.12 to 2.6.12.3 I see peculiar messages appearing in my syslog, dmesg and on my console. Before this upgrade I never saw this type of messages. Googling delivers (as of now) two hits on: "ip_local_deliver: bad skb:" http://www.linuxhq.com/kernel/v2.6/12/net/core/netfilter.c and http://www.linuxhq.com/kernel/v2.6/13-rc1/net/core/netfilter.c So, to me this seems to be something relatively new. Here's a part of my last /var/log/dmesg pcnet32: PCnet/FAST 79C971 at 0xe800, 00 60 b0 c3 cc ea tx_start_pt(0x0c00):~220 bytes, BCR18(9861):BurstWrEn BurstRdEn NoUFlow SRAMSIZE=0x7f00, SRAM_BND=0x3f00, assigned IRQ 10. eth0: registered as PCnet/FAST 79C971 pcnet32: 1 cards_found. eth1: 3c5x9 found at 0x2a0, 10baseT port, address 00 60 8c f7 29 61, IRQ 11. 3c509.c:1.19b 08Nov2002 [EMAIL PROTECTED] http://www.scyld.com/network/3c509.html smc-ultra.c: Presently autoprobing (not recommended) for a single card. smc-ultra.c:v2.02 2/3/98 Donald Becker ([EMAIL PROTECTED]) eth%d: SMC EtherEZ at 0x240, 00 00 C0 AC 5F DD,EEPROM IRQ 5 programmed-I/O mode. kjournald starting. Commit interval 5 seconds EXT3 FS on hda6, internal journal EXT3-fs: mounted filesystem with ordered data mode. eth1: Setting 3c5x9/3c5x9B half-duplex mode if_port: 0, sw_info: 3320 eth1: Setting Rx mode to 1 addresses. eth1: Setting Rx mode to 2 addresses. eth1: Setting Rx mode to 3 addresses. eth1: Setting Rx mode to 4 addresses. eth0: link down eth1: Setting Rx mode to 5 addresses. eth1: Setting Rx mode to 6 addresses. eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING skb: pf=2 (unowned) dev=lo len=60 PROTO=17 44.137.x.y+1:1024 44.137.x.y+1:53 L=60 S=0x00 I=51385 F=0x4000 T=64 ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING skb: pf=2 (unowned) dev=lo len=88 PROTO=1 44.137.x.y+1:0 44.137.x.y+1:0 L=88 S=0xC0 I=27660 F=0x T=64 ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING skb: pf=2 (unowned) dev=lo len=60 PROTO=17 44.137.x.y+1:1024 44.137.x.y+1:53 L=60 S=0x00 I=51386 F=0x4000 T=64 ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING skb: pf=2 (unowned) dev=lo len=88 PROTO=1 44.137.x.y+1:0 44.137.x.y+1:0 L=88 S=0xC0 I=27661 F=0x T=64 ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING skb: pf=2 (unowned) dev=lo len=74 PROTO=17 44.137.x.y+1:1024 44.137.x.y+1:53 L=74 S=0x00 I=51387 F=0x4000 T=64 A part of my syslog: [EMAIL PROTECTED] [/home/geurt]> tail -f /var/log/syslog ul 18 19:19:33 localhost kernel: PROTO=17 44.137.x.y+1:61005 44.137.x.y+1:53 L=61 S=0x00 I=16725 F=0x4000 T=64 Jul 18 19:19:33 localhost kernel: ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING Jul 18 19:19:33 localhost kernel: skb: pf=2 (unowned) dev=lo len=241 Jul 18 19:19:33 localhost kernel: PROTO=17 44.137.x.y+1:53 44.137.x.y+1:61005 L=241 S=0x00 I=200 F=0x4000 T=64 Jul 18 19:19:33 localhost kernel: ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING Jul 18 19:19:33 localhost kernel: skb: pf=2 (unowned) dev=lo len=118 Jul 18 19:19:33 localhost kernel: PROTO=17 44.137.x.y+1:61005 44.137.x.y+1:53 L=118 S=0x00 I=16729 F=0x4000 T=64 Jul 18 19:19:33 localhost kernel: ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING Jul 18 19:19:33 localhost kernel: skb: pf=2 (unowned) dev=lo len=331 Jul 18 19:19:33 localhost kernel: PROTO=17 44.137.x.y+1:53 44.137.x.y+1:61005 L=331 S=0x00 I=201 F=0x4000 T=64 Because this message seems to origine from netfilter.c, herewith an iptables -L -vnx: [EMAIL PROTECTED] [/home/geurt]> iptables -L -vnx Chain INPUT (policy ACCEPT 101 packets, 7852 bytes) pkts bytes target prot opt in out source destination 34475631 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 2119 260990 ACCEPT all -- eth0 * 44.137.x.y/28 0.0.0.0/0 396083 39074573 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 26713104 REJECT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,139,445,1025,1080,1433,2745,3127,3128,61 29,17300,27374 reject-with tcp-reset 13927217 REJECT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 multiport dports 37,135,137,445,524,666,1026,1027,1028,1029 r eject-with icmp-port-unreachable 4 304 DROP udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 udp spt:666 1 44 REJECT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:37 reject-with tcp-reset 5 280 DROP icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 13 1 104 DROP icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 3 00 DROP
Re: 2.6.12 and 82559er ok with eepro100, not ok with e100.
> What eeprom part and vendor are you using? > atmel 93C46B > your eeprom seems to have 64 words. The addr_len being incorrect > might be causing a problem. is there any chance you could try hard > coding it? I tried this, it did not help, the reads were still bogus. I'm still leaning toward an address mapping issue. Would any of the pci kernel parameters have any effect here? Well, I'm going to try out a few anyhow, to see if it changes anything. > > admittedly this is from old old email in this thread, but I think > something in eepro100 may need some cpu_to_le16 because they seem to > be reading an incorrect mac address, or the eeprom's words are > backwards. in later threads that seems to be okay. > > eth0: OEM i82557/i82558 10/100 Ethernet, 50:00:0F:C2:E0:F8, IRQ 12. > > This might be a clue, I'm not sure. Yes, early on I discovered several problems with the way the EEPROM was being programmed, but interestingly?, the error was not with the checksum, even though that was what the error message reported. I think we now have the EEPROM programmed correctly. -- Thanks, -Bob - 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] [PKT_SCHED]: Reduce branch mispredictions in pfifo_fast_dequeue
From: Thomas Graf <[EMAIL PROTECTED]> Date: Mon, 18 Jul 2005 15:36:36 +0200 > The current call to __qdisc_dequeue_head leads to a branch > misprediction for every loop iteration, the fact that the > most common priority is 2 makes this even worse. This issue > has been brought up by Eric Dumazet <[EMAIL PROTECTED]> > but unlike his solution which was to manually unroll the loop, > this approach preserves the possibility to increase the number > of bands at compile time. > > Signed-off-by: Thomas Graf <[EMAIL PROTECTED]> Also applied, thanks Thomas. - 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] [PKT_SCHED]: Remove debugging leftover from textsearch ematch
From: Thomas Graf <[EMAIL PROTECTED]> Date: Mon, 18 Jul 2005 15:35:02 +0200 > Signed-off-by: Thomas Graf <[EMAIL PROTECTED]> Applied, thanks Thomas. - 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 3/3] net/sctp/objcnt: Audit return code of create_proc_*
From: [EMAIL PROTECTED] Date: Thu, 14 Jul 2005 23:42:00 +0200 > From: Christophe Lucas <[EMAIL PROTECTED]> > > Audit return of create_proc_* functions. > > Signed-off-by: Christophe Lucas <[EMAIL PROTECTED]> > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> Applied, 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: [patch 1/3] netlink: Fix "nocast type" warnings
From: [EMAIL PROTECTED] Date: Thu, 14 Jul 2005 23:41:58 +0200 > From: Victor Fusco <[EMAIL PROTECTED]> > > Fix the sparse warning "implicit cast to nocast type" > > File/Subsystem:net/netlink/af_netlink.c > > Signed-off-by: Victor Fusco <[EMAIL PROTECTED]> > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> Applied, 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: [Patch 2.6 3/3]ioctl: Add support for getting a permanent hardware address
From: Jon Wetzel <[EMAIL PROTECTED]> Subject: [Patch 2.6 3/3]ioctl: Add support for getting a permanent hardware address Date: Thu, 14 Jul 2005 16:43:50 -0500 > This patch is the third of three, designed to allow access to the > permanent hardware address of a network device. This patch adds a new > ioctl to get the field, "perm_addr," which was added to net_device by > the first patch. > > Signed-off-by: Jon Wetzel <[EMAIL PROTECTED]> No new BSD style device ioctls, _please_! If we want to create new facilities, they should be done via netlink and possibly the ethtool interfaces. - 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] net configs: NETCONSOLE and NETPOLL together
From: randy_dunlap <[EMAIL PROTECTED]> Date: Tue, 12 Jul 2005 21:27:28 -0700 > Put NETCONSOLE and NETPOLL options together since they are related. > This cuts down on the hassle of flipping back and forth between > the Networking menu and the Network drivers menu to change their > config settings. > > Tested with menuconfig, gconfig, and xconfig. > gconfig has a small problem with this. I think that it's > a bug in gconfig and I will take it up with Romain Lievin. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Applied, thanks Randy. - 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: peculiar messages
Remco den Besten schrieb: L.S., After an upgrade from 2.6.11.12 to 2.6.12.3 I see peculiar messages appearing in my syslog, dmesg and on my console. Before this upgrade I never saw this type of messages. Googling delivers (as of now) two hits on: "ip_local_deliver: bad skb:" Disable CONFIG_NETFILTER_DEBUG to get rid of this. The debugging stuff has been removed in 2.6.13-rc. Regards Patrick - 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 2/3] skbuff.h: Fix "nocast type" warnings
From: [EMAIL PROTECTED] Date: Thu, 14 Jul 2005 23:41:59 +0200 > From: Victor Fusco <[EMAIL PROTECTED]> > > Fix the sparse warning "implicit cast to nocast type" > > File/Subsystem:include/linux/skbuff.h > > Signed-off-by: Victor Fusco <[EMAIL PROTECTED]> > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> Applied, 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
[PATCH 2/2] LSM-IPSec Networking Hooks -- SELinux portion bug fixes
Some bug fixes to the SELinux patch. Regards, Trent. == This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. --- security/selinux/Makefile|2 security/selinux/hooks.c | 20 + security/selinux/include/av_perm_to_string.h |2 security/selinux/include/av_permissions.h|2 security/selinux/include/xfrm.h | 19 + security/selinux/xfrm.c | 439 +++ selinux/include/av_inherit.h |0 selinux/include/class_to_string.h|0 selinux/include/common_perm_to_string.h |0 selinux/include/flask.h |0 selinux/include/initial_sid_to_string.h |0 11 files changed, 484 insertions(+) diff -puN security/selinux/hooks.c~lsm-selinux-nethooks security/selinux/hooks.c --- linux-2.6.13-rc3-git4-xfrm/security/selinux/hooks.c~lsm-selinux-nethooks 2005-07-18 12:11:05.0 -0400 +++ linux-2.6.13-rc3-git4-xfrm-root/security/selinux/hooks.c2005-07-18 12:11:24.0 -0400 @@ -73,6 +73,7 @@ #include "avc.h" #include "objsec.h" #include "netif.h" +#include "xfrm.h" #define XATTR_SELINUX_SUFFIX "selinux" #define XATTR_NAME_SELINUX XATTR_SECURITY_PREFIX XATTR_SELINUX_SUFFIX @@ -3372,6 +3373,10 @@ static int selinux_socket_sock_rcv_skb(s err = avc_has_perm(sock_sid, port_sid, sock_class, recv_perm, &ad); } + + if (!err) + err = selinux_xfrm_sock_rcv_skb(sock_sid, skb); + out:
Re: [NET]: Kill skb->tc_classid
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Mon, 18 Jul 2005 06:39:11 +0200 > OK, here's the patch to remove it. Dave, please apply together with the > previous patch. Patch applied, 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: [PATCH 1/2] LSM-IPSec Networking Hooks -- authorizing flow_cache_entry's
On Mon, Jul 18, 2005 at 01:50:33PM -0400, jaegert wrote:
>
> @@ -190,8 +191,9 @@ void *flow_cache_lookup(struct flowi *ke
> if (fle->genid == atomic_read(&flow_cache_genid)) {
> void *ret = fle->object;
>
> - if (ret)
> + if (ret && (authorizer(sk, ret, key, dir) == 0))
> atomic_inc(fle->object_ref);
> +
> local_bh_enable();
>
> return ret;
Sorry, but I don't see how this can work. If the authorizer call fails,
we still return that object, albeit without the reference count.
We need to ponder this a bit more.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[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
[Fwd: Re: [PATCH 2.6.13-rc3] tg3: Move tg3 firmware into separate file]
Original Message From: - Mon Jul 18 15:34:09 2005 X-Mozilla-Status: 0001 X-Mozilla-Status2: 0080 Message-ID: <[EMAIL PROTECTED]> Date: Mon, 18 Jul 2005 15:34:07 -0400 From: Nathanael Nerode <[EMAIL PROTECTED]> User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David S. Miller <[EMAIL PROTECTED]> Subject: Re: [PATCH 2.6.13-rc3] tg3: Move tg3 firmware into separate file References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David S. Miller wrote: > From: "Nathanael Nerode" <[EMAIL PROTECTED]> > Date: Sun, 17 Jul 2005 07:55:45 -0400 > > >>This is partly for the purpose of doing firmware loading in the future, >>but it's also a matter of tidiness. > > > So make the change when we do the loading like that in the > future. > > The fact that you are forcing the issue right now makes Not "forcing"; do what you think best, of course! > me suspicious of your real reason for desiring this change. OK, the "real" reason is that it makes life slightly easier for Debian. Sorry I didn't mention that; I've been a bit flaky lately. Gory details follow. Debian's policy means that it can't ship the firmware in its kernel source package, because that goes in "main" and has to satisfy all kinds of requirements. Instead the plan is to ship the firmware in a separate package in the "non-free" section (which is nearly ready to go, actually). Debian already has a form of firmware loading working, but apparently that is not sufficiently ready to be accepted upstream, which is why it hasn't been submitted yet. (I'm working on it. IIRC, necessary elements for acceptance upstream include transitional code which will fall back to the built-in firmware if loadable firmware isn't available, and an automatic installation system for loadable firmware files. Right?) Debian policy further means that the "upstream tarball" portion of its kernel source package shouldn't contain files which differ from the versions in the real upstream tarball. (Simple deletions or additions are acceptable in a pinch, but changes belong in the "Debian local" portion.) So due to the current file structure, the tg3.c file is deleted from the upstream tarball, and an entirely new copy is added in the "Debian local" portion. With the firmware in a separate file, the tg3_firmware.h file could be deleted from the upstream tarball, and a (small) diff to tg3.c could be included in the "Debian local" portion. Which would make life easier for the Debian maintainers and help avoid accidental version skew in tg3.c versus upstream. In addition, having the firmware in a separate file will make it more straightforward to construct the separate package which will contain the firmware; the source file can then be used as-is, which it can't now. tg3 isn't the only driver for which Debian is doing this sort of thing, but all the others have the firmware in separate files, causing the package maintainers to swear rather more about tg3. I figured it wouldn't hurt to submit this change now rather than waiting until the firmware loading code was ready. I am a habitual code tidier anyway. Hope this helps, Nathanael Nerode - 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] convert nfmark and conntrack mark to 32bit
From: Harald Welte <[EMAIL PROTECTED]> Date: Sun, 17 Jul 2005 23:42:23 +0200 > As discussed at netconf'05, we convert nfmark and conntrack-mark to be > 32bits even on 64bit architectures. > > Signed-off-by: Harald Welte <[EMAIL PROTECTED]> Applied, thanks Harald. - 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 2.6 3/3]ioctl: Add support for getting a permanent hardware address
On Mon, Jul 18, 2005 at 01:40:07PM -0700, David S. Miller wrote: > From: Jon Wetzel <[EMAIL PROTECTED]> > Subject: [Patch 2.6 3/3]ioctl: Add support for getting a permanent hardware > address > Date: Thu, 14 Jul 2005 16:43:50 -0500 > > > This patch is the third of three, designed to allow access to the > > permanent hardware address of a network device. This patch adds a new > > ioctl to get the field, "perm_addr," which was added to net_device by > > the first patch. > > No new BSD style device ioctls, _please_! > > If we want to create new facilities, they should be done via > netlink and possibly the ethtool interfaces. Jon's patch 1/3 created the ethtool interface, 2/3 fixed up e1000 to use it. 3/3 can be dropped as you desire. Do you want a patch for netlink too then, given the ethtool kernel work is already done? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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] reduce netfilte sk_buff enlargement
From: Harald Welte <[EMAIL PROTECTED]> Date: Mon, 18 Jul 2005 00:04:51 +0200 > The only real in-tree user of nfcache was IPVS, who only needs a single > bit. Unfortunately I couldn't find some other free bit in sk_buff to > stuff that bit into, so I introduced a separate field for them. Maybe > the IPVS guys can resolve that to further save space. I think we must resolve this one before 2.6.14 goes out, which gives us a lot of time, but for now I'll eat that one-bit member. > Initially I wanted to shrink pkt_type to three bits (PACKET_HOST and > alike are only 6 values defined), but unfortunately the bluetooth code > overloads pkt_type :( This also must be cured somehow, that really isn't a clean nor nice usage of this field. > - remove all never-implemented 'nfcache' code > - don't have ipvs code abuse 'nfcache' field. currently get's their own > compile-conditional skb->ipvs_property field. IPVS maintainers can > decide to move this bit elswhere, but nfcache needs to die. > - remove skb->nfcache field to save 4 bytes > - move skb->nfctinfo into three unused bits to save further 4 bytes > > Signed-off-by: Harald Welte <[EMAIL PROTECTED]> Applied, thanks Harald. - 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 2.6.13-rc3] tg3: Move tg3 firmware into separate file
David S. Miller wrote: > From: Nathanael Nerode <[EMAIL PROTECTED]> > Date: Mon, 18 Jul 2005 15:34:07 -0400 > > >>Debian's policy means that it can't ship the firmware in its kernel >>source package, because that goes in "main" and has to satisfy all kinds >>of requirements. > > > Exactly as I suspected, and you removed the CC: list in your > response which really angers me. Why can't you show your > true reasons for desiring this change on the mailing list? Oh, please forward my message to the mailing list if you wish to. On second thought, I'll save you the trouble and do it myself. I hit "reply" instead of "reply all". Things have been a mess around here lately and I've been flakier than usual. If you're going to get angry, please find a better reason. Are you still angry because I (among other people) wanted to get the copyright license on the firmware fixed so it actually worked? Well, it's fixed now, and thanks for incorporating it. If you wish to keep the firmware in the .c file for whatever reason, that's your prerogative. Personally, I can't see any technical reason for not separating the firmware into a separate header file -- it seems to be the standard practice -- but if you have a reason I'd love to hear it. It's reasonable from a file-size perspective, anyway; the tg3.c file is 300K, and the firmware is 42K of that, so it's not creating any gratuitously small files. - 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 2.6 3/3]ioctl: Add support for getting a permanent hardware address
From: Matt Domsch <[EMAIL PROTECTED]> Date: Mon, 18 Jul 2005 22:30:11 -0500 > Do you want a patch for netlink too then, given the ethtool kernel work is > already done? I think what we're going to end up doing is have a netlink interface for the ethtool stuff, so if you add some ethtool bits they will show up in the netlink think we come up with automatically. - 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
net-2.6.14 tree made
I just put up the first batch of changes due for the 2.6.14 networking at: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.14.git Anything that isn't a bug fix will end up there, and once 2.6.13 goes out the door I'll push the stuff in that tree to Linus. 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
