Re: [PATCH] IPv6/DCCP: Fix memory leak in dccp_v6_do_rcv()
On Fri, 29 Sep 2006 02:45:33 +0200
Jesper Juhl [EMAIL PROTECTED] wrote:
Coverity found what looks like a real leak in
net/dccp/ipv6.c::dccp_v6_do_rcv()
We may leave via the return inside if (sk-sk_state == DCCP_OPEN) {
but at that point we may have allocated opt_skb, but we never free it
in that path before the return.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
net/dccp/ipv6.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.18-git10-orig/net/dccp/ipv6.c 2006-09-28 22:40:07.0
+0200
+++ linux-2.6.18-git10/net/dccp/ipv6.c2006-09-29 02:35:15.0
+0200
@@ -997,6 +997,8 @@ static int dccp_v6_do_rcv(struct sock *s
if (sk-sk_state == DCCP_OPEN) { /* Fast path */
if (dccp_rcv_established(sk, skb, dccp_hdr(skb), skb-len))
goto reset;
+ if (opt_skb)
+ __kfree_skb(opt_skb);
return 0;
}
Looks right to me. But it'd be better coded as below, so we don't have
multiple deeply-nested return points (the cause of this bug) and duplicated
code.
otoh, it seems to me that opt_skb doesn't actually do anything and can be
removed?
diff -puN net/dccp/ipv6.c~ipv6-dccp-fix-memory-leak-in-dccp_v6_do_rcv
net/dccp/ipv6.c
--- a/net/dccp/ipv6.c~ipv6-dccp-fix-memory-leak-in-dccp_v6_do_rcv
+++ a/net/dccp/ipv6.c
@@ -997,7 +997,7 @@ static int dccp_v6_do_rcv(struct sock *s
if (sk-sk_state == DCCP_OPEN) { /* Fast path */
if (dccp_rcv_established(sk, skb, dccp_hdr(skb), skb-len))
goto reset;
- return 0;
+ goto out;
}
if (sk-sk_state == DCCP_LISTEN) {
@@ -1013,9 +1013,7 @@ static int dccp_v6_do_rcv(struct sock *s
if (nsk != sk) {
if (dccp_child_process(sk, nsk, skb))
goto reset;
- if (opt_skb != NULL)
- __kfree_skb(opt_skb);
- return 0;
+ goto out;
}
}
@@ -1026,9 +1024,10 @@ static int dccp_v6_do_rcv(struct sock *s
reset:
dccp_v6_ctl_send_reset(skb);
discard:
+ kfree_skb(skb);
+out:
if (opt_skb != NULL)
__kfree_skb(opt_skb);
- kfree_skb(skb);
return 0;
}
_
-
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: tc related lockdep warning.
On Thu, Sep 28, 2006 at 07:20:00AM -0700, Stephen Hemminger wrote:
On Thu, 28 Sep 2006 15:13:01 +0200
Jarek Poplawski [EMAIL PROTECTED] wrote:
On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
[My mail provider is down, so responding manually]
Jarek Poplawski wrote:
[NET_SCHED]: Fix fallout from dev-qdisc RCU change
Sorry again but I can't abstain from some doubts:
...
diff --git a/net/core/dev.c b/net/core/dev.c
index 14de297..4d891be 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1480,14 +1480,16 @@ #endif
if (q-enqueue) {
/* Grab device queue */
spin_lock(dev-queue_lock);
+ q = dev-qdisc;
I don't get it. If it is some anti-race step according to
rcu rules it should be again:
q = rcu_dereference(dev-qdisc);
At this point RCU protection is not needed anymore since we
have the lock. We simply want to avoid taking the lock for
devices that don't have a real qdisc attached (like loopback).
Thats what the test for q-enqueue is there for. RCU is only
needed to avoid races between testing q-enqueue and freeing
of the qdisc.
But in Documentation/RCU/whatisRCU.txt I see this:
/*
* Return the value of field a of the current gbl_foo
* structure. Use rcu_read_lock() and rcu_read_unlock()
* to ensure that the structure does not get deleted out
* from under us, and use rcu_dereference() to ensure that
* we see the initialized version of the structure (important
* for DEC Alpha and for people reading the code).
*/
int foo_get_a(void)
{
int retval;
rcu_read_lock();
retval = rcu_dereference(gbl_foo)-a;
rcu_read_unlock();
return retval;
}
The example uses rcu_read_lock() which is a weaker form of protection
than a real lock, so the rcu_dereference() is needed to do memory barriers.
I don't question this and I know it is not required - I mean
what is in the parenthesis (important ...) or here:
From Documentation/RCU/checklist.txt:
The rcu_dereference() primitive is used by the various
_rcu() list-traversal primitives, such as the
list_for_each_entry_rcu(). Note that it is perfectly
legal (if redundant) for update-side code to use
rcu_dereference() and the _rcu() list-traversal
primitives. This is particularly useful in code
that is common to readers and updaters.
In the qdisc case we have the proper spin_lock() so no additional
barrier is needed.
So why isn't it done in the code instead of comments?:
if (q-enqueue) {
rcu_read_unlock();
/* Grab device queue */
spin_lock(dev-queue_lock);
q = dev-qdisc;
...
}
rcu_read_unlock();
I mean the consequence.
Another thing is why? Now it looks RCU is good for the first test
but we don't believe it entirely (or assume the pointer could change
at this particular moment) so take this pointer again with
a real lock. I think RCU assures the consistency within it's block
and we should only test for NULL pointer.
Jarek P.
-
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 backport] RTL8168 ethernet support in r8169
Samir Bellabes [EMAIL PROTECTED] :
[...]
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), 0, 0, RTL_CFG_1 },
^
Should be RTL_CFG_1.
You mean should be RTL_CFG_0 ?
Yes.
It was typos night.
--
Ueimor
-
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.19 status
Hi Dave,
29 Eyl 2006 Cum 04:41 tarihinde şunları yazmıştınız:
I've just pushed my current net-2.6 tree to Linus. The bulk of the
changes in there are endianness annotations for sparse by Al Viro,
along with the patches I've been ACK'ing here on the list and
elsewhere.
If you want a non-bugfix change to get into 2.6.19 you must have it to
me by the end of the weekend.
As of next Monday, anything I receive has to be a bugfix for 2.6.19
consideration.
Thanks for everyone's hard work and let's make sure there are no
networking regressions at all in 2.6.19, in fact let's strive to
make it have no regressions plus bugs fixed that were in 2.6.18 :-)
Looks like following fix from Herbert still didn't made it to Linus which
fixes hard lockups with some tc usage.
[NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
Fix incorrect use of RB_EMPTY_NODE in htb_safe_rb_erase, which makes it
skip nodes within the rbtree instead of nodes not in the tree, resulting
in crashes later on.
The root cause for this seems to be the very counter-intuitive behaviour
of the RB_EMPTY_NODE macro, which returns _false_ when the node is empty.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 9a0cd6d60280d88c38791844c87548d45cf6f2c2
tree fdf4f4a46fb088d957322006828af557b8ce594a
parent 7e4720201ad44ace85a443f41d668a62a737e7d0
author Patrick McHardy [EMAIL PROTECTED] Wed, 27 Sep 2006 13:27:24 +0200
committer Patrick McHardy [EMAIL PROTECTED] Wed, 27 Sep 2006 13:27:24 +0200
net/sched/sch_htb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index bb3ddd4..6c058e3 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -391,7 +391,7 @@ static inline void htb_add_class_to_row(
/* If this triggers, it is a bug in this code, but it need not be fatal */
static void htb_safe_rb_erase(struct rb_node *rb, struct rb_root *root)
{
- if (RB_EMPTY_NODE(rb)) {
+ if (!RB_EMPTY_NODE(rb)) {
WARN_ON(1);
} else {
rb_erase(rb, root);
--
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
-- Benjamin Franklin
-
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
XFRM BEET mode and 2.6.19 kernel
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. -- Miika Komu http://www.iki.fi/miika/ - 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 6/7] secid reconciliation-v03: Label locally generated IPv4 traffic
On Thu, 28 Sep 2006, Venkat Yekkirala wrote:
+static inline void security_skb_classify_ipcm(struct sk_buff *skb,
+ struct ipcm_cookie *ipc)
+{
+ ipc-secid = 0;
+ ipc-secid = skb-secmark;
+}
You don't need the assignment to 0.
- 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 4/7] secid reconciliation-v03: Invoke LSM hook for outbound traffic
On Thu, 28 Sep 2006, Venkat Yekkirala wrote: + } + else/* inbound */ + /* loopback traffic should already be labeled +and any filtering on outbound should suffice */ + if (in == loopback_dev) + goto out; Minor nit that akpm will point out, the else belongs on the same line as the brace. Also, the comment style is: /* * Comment... * etc. */ - 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: 2.6.19 status
From: Ismail Donmez [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 10:10:34 +0300 Hi Dave, 29 Eyl 2006 Cum 04:41 tarihinde $,1 (Bunlar$,1 Q(B yazm$,1 Q (Bt$,1 Q(Bn$,1 Q(Bz: I've just pushed my current net-2.6 tree to Linus. The bulk of the changes in there are endianness annotations for sparse by Al Viro, along with the patches I've been ACK'ing here on the list and elsewhere. If you want a non-bugfix change to get into 2.6.19 you must have it to me by the end of the weekend. As of next Monday, anything I receive has to be a bugfix for 2.6.19 consideration. Thanks for everyone's hard work and let's make sure there are no networking regressions at all in 2.6.19, in fact let's strive to make it have no regressions plus bugs fixed that were in 2.6.18 :-) Looks like following fix from Herbert still didn't made it to Linus which fixes hard lockups with some tc usage. It's in my net-2.6 tree, which is where you should check for whether something is queued and pending submission yet. - 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 4/7] secid reconciliation-v03: Invoke LSM hook for outbound traffic
On Thu, 28 Sep 2006, Venkat Yekkirala wrote:
+ if (connsecmark)
+ if (*connsecmark != skb-secmark) {
*connsecmark = skb-secmark;
+ }
Please remove the braces if re-submitting.
+printk(KERN_ERR IN HOOK (%d) (%u) (%u)\n, hooknum, skb-secmark,
*psecmark);\
Please remove debugging (here and elsewhere).
+ /* Set secmark on inbound and filter it on outbound */
+ if ((target-family == AF_INET
+ (hooknum == NF_IP_POST_ROUTING ||
+ hooknum == NF_IP_LOCAL_OUT ||
+ hooknum == NF_IP_FORWARD)) ||
+ (target-family == AF_INET6
+ (hooknum == NF_IP6_POST_ROUTING ||
+ hooknum == NF_IP6_LOCAL_OUT ||
+ hooknum == NF_IP6_FORWARD))) {
I think this should be a separate helper function, so the logic can be
changed/evaluated in isolation (preferred, but not a blocker).
+ secmark_save(skb, hooknum, target);
It seems that the target parameter is not needed.
+ return secmark_restore(skb, hooknum, in, target);
Please pass a family parameter instead of target.
--
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: [PATH] Allow mtu bigger than 1500 for ieee80211
On Thu, 2006-09-28 at 19:57 +0200, matthieu castet wrote: + if ((new_mtu 68) || (new_mtu IEEE80211_DATA_LEN)) + return -EINVAL; What's with that lower limit, why 68? 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 3/3] Add tsi108 On Chip Ethernet device driver support
On Thu, 2006-09-21 at 12:46, Jeff Garzik wrote:
Zang Roy-r61911 wrote:
+struct tsi108_prv_data {
+ void __iomem *regs;/* Base of normal regs */
+ void __iomem *phyregs; /* Base of register bank used for PHY
access */
+
+ int phy;/* Index of PHY for this interface */
+ int irq_num;
+ int id;
+
+ struct timer_list timer;/* Timer that triggers the check phy
function */
+ int rxtail; /* Next entry in rxring to read */
+ int rxhead; /* Next entry in rxring to give a new
buffer */
+ int rxfree; /* Number of free, allocated RX
buffers */
+
+ int rxpending; /* Non-zero if there are still
descriptors
+ * to be processed from a previous
descriptor
+ * interrupt condition that has been
cleared */
+
+ int txtail; /* Next TX descriptor to check status
on */
+ int txhead; /* Next TX descriptor to use */
most of these should be unsigned, to prevent bugs.
+ /* Number of free TX descriptors. This could be calculated
from
+ * rxhead and rxtail if one descriptor were left unused to
disambiguate
+ * full and empty conditions, but it's simpler to just keep
track
+ * explicitly. */
+
+ int txfree;
+
+ int phy_ok; /* The PHY is currently powered on. */
+
+ /* PHY status (duplex is 1 for half, 2 for full,
+ * so that the default 0 indicates that neither has
+ * yet been configured). */
+
+ int link_up;
+ int speed;
+ int duplex;
+
+ tx_desc *txring;
+ rx_desc *rxring;
+ struct sk_buff *txskbs[TSI108_TXRING_LEN];
+ struct sk_buff *rxskbs[TSI108_RXRING_LEN];
+
+ dma_addr_t txdma, rxdma;
+
+ /* txlock nests in misclock and phy_lock */
+
+ spinlock_t txlock, misclock;
+
+ /* stats is used to hold the upper bits of each hardware
counter,
+ * and tmpstats is used to hold the full values for returning
+ * to the caller of get_stats(). They must be separate in
case
+ * an overflow interrupt occurs before the stats are consumed.
+ */
+
+ struct net_device_stats stats;
+ struct net_device_stats tmpstats;
+
+ /* These stats are kept separate in hardware, thus require
individual
+ * fields for handling carry. They are combined in get_stats.
+ */
+
+ unsigned long rx_fcs; /* Add to rx_frame_errors */
+ unsigned long rx_short_fcs; /* Add to rx_frame_errors */
+ unsigned long rx_long_fcs; /* Add to rx_frame_errors */
+ unsigned long rx_underruns; /* Add to rx_length_errors */
+ unsigned long rx_overruns; /* Add to rx_length_errors */
+
+ unsigned long tx_coll_abort;/* Add to
tx_aborted_errors/collisions */
+ unsigned long tx_pause_drop;/* Add to tx_aborted_errors */
+
+ unsigned long mc_hash[16];
+};
+
+/* Structure for a device driver */
+
+static struct platform_driver tsi_eth_driver = {
+ .probe = tsi108_init_one,
+ .remove = tsi108_ether_remove,
+ .driver = {
+ .name = tsi-ethernet,
+ },
+};
+
+static void tsi108_timed_checker(unsigned long dev_ptr);
+
+static void dump_eth_one(struct net_device *dev)
+{
+ struct tsi108_prv_data *data = netdev_priv(dev);
+
+ printk(Dumping %s...\n, dev-name);
+ printk(intstat %x intmask %x phy_ok %d
+ link %d speed %d duplex %d\n,
+TSI108_ETH_READ_REG(TSI108_EC_INTSTAT),
+TSI108_ETH_READ_REG(TSI108_EC_INTMASK), data-phy_ok,
+data-link_up, data-speed, data-duplex);
+
+ printk(TX: head %d, tail %d, free %d, stat %x, estat %x, err
%x\n,
+data-txhead, data-txtail, data-txfree,
+TSI108_ETH_READ_REG(TSI108_EC_TXSTAT),
+TSI108_ETH_READ_REG(TSI108_EC_TXESTAT),
+TSI108_ETH_READ_REG(TSI108_EC_TXERR));
+
+ printk(RX: head %d, tail %d, free %d, stat %x,
+ estat %x, err %x, pending %d\n\n,
+data-rxhead, data-rxtail, data-rxfree,
+TSI108_ETH_READ_REG(TSI108_EC_RXSTAT),
+TSI108_ETH_READ_REG(TSI108_EC_RXESTAT),
+TSI108_ETH_READ_REG(TSI108_EC_RXERR), data-rxpending);
+}
+
+/* Synchronization is needed between the thread and up/down events.
+ * Note that the PHY is accessed through the same registers for
both
+ * interfaces, so this can't be made interface-specific.
+ */
+
+static DEFINE_SPINLOCK(phy_lock);
you should have a chip structure, that contains two structs (one for
each interface/port)
Could you interpret the chip structure in more detail?
Need I create two net_device struct for each port?
Thanks.
Roy
-
To unsubscribe from this list: send the line
Re: [patch 3/3] Add tsi108 On Chip Ethernet device driver support
Zang Roy-r61911 wrote: Could you interpret the chip structure in more detail? Need I create two net_device struct for each port? No. One net_device per port. And one container structure for the entire device. Jeff - 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: [PATH] Allow mtu bigger than 1500 for ieee80211
On Fri, Sep 29, 2006 at 09:38:21AM +0200, Johannes Berg wrote: On Thu, 2006-09-28 at 19:57 +0200, matthieu castet wrote: + if ((new_mtu 68) || (new_mtu IEEE80211_DATA_LEN)) + return -EINVAL; What's with that lower limit, why 68? Isn't 68 the minimum MTU required by IPv4? - 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] IPv6/DCCP: Remove unused IPV6_PKTOPTIONS code
Coverity found what looks like a real leak in
net/dccp/ipv6.c::dccp_v6_do_rcv()
| otoh, it seems to me that opt_skb doesn't actually do anything and can be
| removed?
This is right, there is no code referencing opt_skb: compare with
net/ipv6/tcp_ipv6.c.
Until someone has time to add the missing DCCP-specific code, it does seem
better
to replace the dead part with a FIXME. This is done by the patch below, applies
to
davem-net2.6 and has been tested to compile.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
ipv6.c | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 7a47399..9d19344 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -956,8 +956,6 @@ out:
*/
static int dccp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)
{
- struct ipv6_pinfo *np = inet6_sk(sk);
- struct sk_buff *opt_skb = NULL;
/* Imagine: socket is IPv6. IPv4 packet arrives,
goes to IPv4 receive handler and backlogged.
@@ -978,21 +976,8 @@ static int dccp_v6_do_rcv(struct sock *s
* called with bh processing disabled.
*/
- /* Do Stevens' IPV6_PKTOPTIONS.
-
- Yes, guys, it is the only place in our code, where we
- may make it not affecting IPv4.
- The rest of code is protocol independent,
- and I do not like idea to uglify IPv4.
-
- Actually, all the idea behind IPV6_PKTOPTIONS
- looks not very well thought. For now we latch
- options, received in the last packet, enqueued
- by tcp. Feel free to propose better solution.
- --ANK (980728)
-*/
- if (np-rxopt.all)
- opt_skb = skb_clone(skb, GFP_ATOMIC);
+ /* FIXME: Add handling of IPV6_PKTOPTIONS with appropriate freeing of
+*skb (see net/ipv6/tcp_ipv6.c for example) */
if (sk-sk_state == DCCP_OPEN) { /* Fast path */
if (dccp_rcv_established(sk, skb, dccp_hdr(skb), skb-len))
@@ -1013,8 +998,6 @@ static int dccp_v6_do_rcv(struct sock *s
if (nsk != sk) {
if (dccp_child_process(sk, nsk, skb))
goto reset;
- if (opt_skb != NULL)
- __kfree_skb(opt_skb);
return 0;
}
}
@@ -1026,8 +1009,6 @@ static int dccp_v6_do_rcv(struct sock *s
reset:
dccp_v6_ctl_send_reset(skb);
discard:
- if (opt_skb != NULL)
- __kfree_skb(opt_skb);
kfree_skb(skb);
return 0;
}
-
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: [ACRYPTO] New asynchronous crypto layer (acrypto) release.
On Thu, Sep 28, 2006 at 03:23:43PM +0200, Andreas Jellinghaus ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov wrote: Hello. I'm pleased to announce asynchronous crypto layer (acrypto) [1] release for 2.6.18 kernel tree. Acrypto allows to handle crypto requests asynchronously in hardware. Combined patchset includes: * acrypto core * IPsec ESP4 port to acrypto * dm-crypt port to acrypto so I should be able to replace a plain 2.6.18 kernel with one with this patchset and use dm-crypt'ed partitions (e.g. swap, encrypted root filesystem) as usual without further changes? Did anyone test this with success? Regards, Andreas As I answered in your first e-mail, yes, you just need to patch 2.6.18 tree and load one of the crypto provider. Acrypto works with request/response model, i.e. you ask acrypto core to perform some operation on given buffers and if it can, it will call your callback when it is ready (or some error happend and acrypto was unable to reroute request to other device), otherwise it will return error. With such a model it is possible to extend acrypto to any kind of operations on buffers, not only crypto related, for example it is possible to onload IPsec header transformation, perform DMA between specified areas and much more. -- 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: [ACRYPTO] New asynchronous crypto layer (acrypto) release.
Evgeniy == Evgeniy Polyakov [EMAIL PROTECTED] writes: Evgeniy Hello. I'm pleased to announce asynchronous crypto layer Evgeniy (acrypto) [1] release for 2.6.18 kernel tree. Acrypto allows Evgeniy to handle crypto requests asynchronously in hardware. Would userspace programs benefit from this patch? In particular, would OpenSSL get better performances on Via nehemiah CPUs or does it need to be patched? Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/ - 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: [ACRYPTO] New asynchronous crypto layer (acrypto) release.
On Fri, Sep 29, 2006 at 12:17:58PM +0200, Samuel Tardieu ([EMAIL PROTECTED]) wrote: Evgeniy == Evgeniy Polyakov [EMAIL PROTECTED] writes: Evgeniy Hello. I'm pleased to announce asynchronous crypto layer Evgeniy (acrypto) [1] release for 2.6.18 kernel tree. Acrypto allows Evgeniy to handle crypto requests asynchronously in hardware. Would userspace programs benefit from this patch? In particular, would OpenSSL get better performances on Via nehemiah CPUs or does it need to be patched? Userspace supports Via Nehemiah CPUs crypto engine quite for a long time without any external patching. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/ -- 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
lifetime of IPv6 tempaddr is limited to lifetime specified in router advertisements: address lost while SSH connection is still established
Hi, running kernel-2.6.17-1.2187_FC5 and using net.ipv6.conf.default.use_tempaddr = 2 in /etc/sysctl.conf results in enabling and prefered use of temporary IPv6 addresses as expected. Current related sysctl values are: # sysctl -a |grep temp_ net.ipv6.conf.eth0.temp_prefered_lft = 86400 net.ipv6.conf.eth0.temp_valid_lft = 604800 net.ipv6.conf.default.temp_prefered_lft = 86400 net.ipv6.conf.default.temp_valid_lft = 604800 net.ipv6.conf.all.temp_prefered_lft = 86400 net.ipv6.conf.all.temp_valid_lft = 604800 net.ipv6.conf.lo.temp_prefered_lft = 86400 net.ipv6.conf.lo.temp_valid_lft = 604800 But now strange things happen. It looks like that the prefered_lft is not used because of receiving router advertisements (imho a normal scenario). Router advertisements have valid time 3000s, pref. time 2000s Current available addresses: # ip -6 addr show dev eth0 2: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qlen 1000 inet6 2001:db8:0:0:f0fc:f50b:3cb1:cfea/64 scope global secondary dynamic valid_lft 2047sec preferred_lft 1047sec inet6 2001:db8:0:0:a963:ce7f:8e4e:fdf2/64 scope global secondary deprecated dynamic valid_lft 265sec preferred_lft -735sec inet6 2001:db8:0:0:201:3ff:fe33:23c9/64 scope global dynamic valid_lft 2555sec preferred_lft 1555sec inet6 fe80::201:3ff:fe01:2345/64 scope link valid_lft forever preferred_lft forever Established TCP sessions: # lsof -n -i :22 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sshd 1613 root3u IPv6 4777 TCP *:ssh (LISTEN) ssh 15606 peter3u IPv6 153678 TCP [2001:db8:0:0:d45e:37d7:616d:99a]:55953-[2001:dba:0:1::164:1]:ssh (ESTABLISHED) As you see, the source address 2001:db8:0:0:d45e:37d7:616d:99a do no longer appear in interface address list. So it looks like that if lifetime from router advertisment limits the lifetime of the temporary address, but there is an update mechanism missing which extends the lifetime of this temporary address (up to the sysctl limit), if a next router advertisement is received. Also it should not happen that the address is removed completly in case it's still used in an open socket. Is this a (known) bug or a (strange) feature or already fixed in 2.6.18? Thank you very much. Regards, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto:[EMAIL PROTECTED] Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ OpenBChttp://www.openbc.com/hp/Peter_Bieringer/ Personal invitation to OpenBC http://www.openbc.com/go/invita/3889 - 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: [PATH] Allow mtu bigger than 1500 for ieee80211
On Fri, 2006-09-29 at 11:30 +0200, Joerg Roedel wrote: On Fri, Sep 29, 2006 at 09:38:21AM +0200, Johannes Berg wrote: On Thu, 2006-09-28 at 19:57 +0200, matthieu castet wrote: + if ((new_mtu 68) || (new_mtu IEEE80211_DATA_LEN)) + return -EINVAL; What's with that lower limit, why 68? Isn't 68 the minimum MTU required by IPv4? No idea, but shouldn't there be a named constant somewhere for that then? 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 7/7] secid reconciliation-v03: Enforcement for SELinux
On Thu, 2006-09-28 at 23:52 -0400, Joshua Brindle wrote:
Venkat Yekkirala wrote:
snip
+
+ err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (xfrm_sid) {
+ err = security_transition_sid(xfrm_sid, skb-secmark,
+ SECCLASS_PACKET, trans_sid);
+ if (err)
+ goto out;
+
I thought we weren't doing transitions to label packets anymore per the
conference call?
No, transitions are still part of the reconciliation process. By
default, this just means that we end up with the xfrm_sid (which is what
you want). But it allows us the freedom to define transitions on the
secmark label if desired, and those transitions can still yield subject
labels.
--
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 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 2006-09-29 at 08:59 -0400, Stephen Smalley wrote:
On Thu, 2006-09-28 at 23:52 -0400, Joshua Brindle wrote:
Venkat Yekkirala wrote:
snip
+
+ err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (xfrm_sid) {
+ err = security_transition_sid(xfrm_sid, skb-secmark,
+ SECCLASS_PACKET, trans_sid);
+ if (err)
+ goto out;
+
I thought we weren't doing transitions to label packets anymore per the
conference call?
No, transitions are still part of the reconciliation process. By
default, this just means that we end up with the xfrm_sid (which is what
you want). But it allows us the freedom to define transitions on the
secmark label if desired, and those transitions can still yield subject
labels.
This is not consistent with my perception of the decision made in the
conference call. I thought that the secid was either going to be 1) the
secmark label if no external labeling is present or 2) the external
label if it is present. The flow_in permission would be checked between
the external label and the secmark label in either case (unlabeled in
the case of #1)
How is this different from the implementation before the call?
-
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 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 2006-09-29 at 10:00 -0400, Joshua Brindle wrote:
On Fri, 2006-09-29 at 08:59 -0400, Stephen Smalley wrote:
On Thu, 2006-09-28 at 23:52 -0400, Joshua Brindle wrote:
Venkat Yekkirala wrote:
snip
+
+ err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (xfrm_sid) {
+ err = security_transition_sid(xfrm_sid, skb-secmark,
+ SECCLASS_PACKET,
trans_sid);
+ if (err)
+ goto out;
+
I thought we weren't doing transitions to label packets anymore per the
conference call?
No, transitions are still part of the reconciliation process. By
default, this just means that we end up with the xfrm_sid (which is what
you want). But it allows us the freedom to define transitions on the
secmark label if desired, and those transitions can still yield subject
labels.
This is not consistent with my perception of the decision made in the
conference call. I thought that the secid was either going to be 1) the
secmark label if no external labeling is present or 2) the external
label if it is present. The flow_in permission would be checked between
the external label and the secmark label in either case (unlabeled in
the case of #1)
The behavior you describe is precisely what will happen in the absence
of any type_transition rules on packet class in the policy, given the
way in which he has defined security_transition_sid on packet class.
The only question is whether there is any value in allowing a transition
to be configured in policy (and if such a transition is configured,
whether the resulting SID requires its own separate permission check,
which is what is usually done - the transition doesn't implicitly
authorize anything). I don't recall a particular decision on the
transition issue during the call nor do I see it in the posted notes.
However, since the transition was removed in the flow_out case, it would
be logical to remove it from the flow_in case as well, and that would
have the side benefit of less overhead.
--
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 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 29 Sep 2006, Stephen Smalley wrote: However, since the transition was removed in the flow_out case, it would be logical to remove it from the flow_in case as well, and that would have the side benefit of less overhead. How about adding secmark transitions later, if needed, perhaps with an /selinux config control ? It does keep things simpler for now, in terms of getting this code merged, deployed into distros and likely certified. - 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] IPv6/DCCP: Remove unused IPV6_PKTOPTIONS code
On 9/29/06, Gerrit Renker [EMAIL PROTECTED] wrote: Coverity found what looks like a real leak in net/dccp/ipv6.c::dccp_v6_do_rcv() | otoh, it seems to me that opt_skb doesn't actually do anything and can be | removed? This is right, there is no code referencing opt_skb: compare with net/ipv6/tcp_ipv6.c. Until someone has time to add the missing DCCP-specific code, it does seem better to replace the dead part with a FIXME. This is done by the patch below, applies to davem-net2.6 and has been tested to compile. Thanks, I've been again sidetracked by Real Life(tm) but hopefully tomorrow I'll go over all the DCCP pending patches backlog and get them into tree to submit to Dave. - Arnaldo - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
Stephen Smalley wrote: On Fri, 2006-09-29 at 10:33 -0400, James Morris wrote: On Fri, 29 Sep 2006, Stephen Smalley wrote: However, since the transition was removed in the flow_out case, it would be logical to remove it from the flow_in case as well, and that would have the side benefit of less overhead. How about adding secmark transitions later, if needed, perhaps with an /selinux config control ? It does keep things simpler for now, in terms of getting this code merged, deployed into distros and likely certified. Fine with me, unless Venkat has an immediate use case for such transitions in the flow_in case (but I think this is mostly my fault for suggesting transitions a while ago). Unless I'm confusing something, there still may be a need for transitions if we want to support both IPsec and NetLabel labeling on the same connection. If we don't support transitions and allow both labeling methods on the same connection we'll need to decide how to handle resolving the two - maybe use a transition is this one case? -- 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 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 29 Sep 2006, Paul Moore wrote: Unless I'm confusing something, there still may be a need for transitions if we want to support both IPsec and NetLabel labeling on the same connection. I'd prefer not to support this, as it's too complicated, and CIPSO is a legacy protocol. Normal IPsec protection applied to CIPSO: yes, but not IPsec labeling and CIPSO labeling on the same connection. - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
Fine with me, unless Venkat has an immediate use case for such transitions in the flow_in case (but I think this is mostly my fault for suggesting transitions a while ago). I don't have a use case currently. Unless I'm confusing something, there still may be a need for transitions if we want to support both IPsec and NetLabel labeling on the same connection. If we don't support transitions and allow both labeling methods on the same connection we'll need to decide how to handle resolving the two - maybe use a transition is this one case? Since CIPSO doesn't do full contexts currently, it would be just a matter of an additional flow_in check. The base sid used here would be the current secmark at that point (which will be the xfrm sid if xfrm was used). So, no transitions needed here currently. - 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: mii-tool gigabit support.
On Wed, 2006-09-27 at 12:32 -0700, Auke Kok wrote: dumping registers in readable format is an extension that needs to be implemented per driver. Not all nics have done this - we just did it ourselves for ixgb, and I saw skge/sky2 just fly by this week. This has always bothered me a bit with ethtool. It really stinks that we have to actually write code and generate patches and get everyone to update a utility just to be able to get this type of access. I see two ways to make the situation better: 1) add extensions to the drivers themselves to be able to report this which would likely lead to a lot of driver bloat and too much user-space style info (like verbose descriptions of the register and it's purpose) or 2) develop some style of register description definition type of text file, maybe XML, maybe INI style or something stored in /etc/ethtool as drivername.conf or something like that. This way, ethtool doesn't have to be changed/updated/patched/likely-bug-added for every single device known to man. Just a thought. -- David Hollis [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 7/7] secid reconciliation-v03: Enforcement for SELinux
Venkat Yekkirala wrote: Fine with me, unless Venkat has an immediate use case for such transitions in the flow_in case (but I think this is mostly my fault for suggesting transitions a while ago). I don't have a use case currently. Unless I'm confusing something, there still may be a need for transitions if we want to support both IPsec and NetLabel labeling on the same connection. If we don't support transitions and allow both labeling methods on the same connection we'll need to decide how to handle resolving the two - maybe use a transition is this one case? Since CIPSO doesn't do full contexts currently, it would be just a matter of an additional flow_in check. The base sid used here would be the current secmark at that point (which will be the xfrm sid if xfrm was used). So, no transitions needed here currently. That's fine by me, I just wanted to make sure something like that would be acceptable. So, in summary, we would do the normal flow_in checks for both IPsec and NetLabel and then set the secmark using the IPsec label as the base sid for the NetLabel's generated SID? -- 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 7/7] secid reconciliation-v03: Enforcement for SELinux
Unless I'm confusing something, there still may be a need for transitions if we want to support both IPsec and NetLabel labeling on the same connection. I'd prefer not to support this, as it's too complicated, Actually, from my vantage point, it actually seems natural. and CIPSO is a legacy protocol. Sure. Normal IPsec protection applied to CIPSO: yes, but not IPsec labeling and CIPSO labeling on the same connection. One use case example can be one SA for Secret in combination with any/all/none of the compartments. And another SA for Top Secret ... - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
That's fine by me, I just wanted to make sure something like that would be acceptable. So, in summary, we would do the normal flow_in checks for both IPsec and NetLabel and then set the secmark using the IPsec label as the base sid for the NetLabel's generated SID? That's correct (in short you won't care if IPSec was in use or not, you would just use the secmark at that point as the base sid in coming up with the NetLabel sid, and if it flow controls fine vis a vis the secmark you would replace secmark with the NetLabel sid. The logic flow is quite natural and intuitive for the users as well). - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
I tend to agree, I just can't see it being all that useful in the real world. However, each time it comes up (including the conference call earlier this week) it seems that people would prefer to use both at the same time. A matter of providing options to users. It seems more of a pain to actually prevent their use at the same time and/or explain strange/unnatural behavior. - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
Venkat Yekkirala wrote: I tend to agree, I just can't see it being all that useful in the real world. However, each time it comes up (including the conference call earlier this week) it seems that people would prefer to use both at the same time. A matter of providing options to users. As long as those options receive the blessings of the maintainers ;) It seems more of a pain to actually prevent their use at the same time and/or explain strange/unnatural behavior. Agreed, the solution that we agreed upon is much easier to implement and explain than a lot of the alternatives. -- 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 7/7] secid reconciliation-v03: Enforcement for SELinux
Venkat Yekkirala wrote:
This defines SELinux enforcement of the 2 new LSM hooks as well
as related changes elsewhere in the SELinux code.
As soon as I hit send on this mail I'll start working on the related
patch to provide the missing NetLabel support.
Additional comments are below.
Signed-off-by: Venkat Yekkirala [EMAIL PROTECTED]
---
security/selinux/hooks.c| 129 +++---
security/selinux/include/xfrm.h |5 +
security/selinux/ss/mls.c |2
security/selinux/ss/services.c |2
security/selinux/xfrm.c | 28 ++
5 files changed, 139 insertions(+), 27 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 5a66c4c..143b4b8 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3449,8 +3449,12 @@ static int selinux_sock_rcv_skb_compat(s
err = avc_has_perm(sock_sid, port_sid,
sock_class, recv_perm, ad);
+ if (err)
+ goto out;
}
+ err = selinux_xfrm_sock_rcv_skb(sock_sid, skb, ad);
+
out:
return err;
}
@@ -3489,10 +3493,6 @@ static int selinux_socket_sock_rcv_skb(s
goto out;
err = selinux_netlbl_sock_rcv_skb(sksec, skb, ad);
- if (err)
- goto out;
-
- err = selinux_xfrm_sock_rcv_skb(sksec-sid, skb, ad);
out:
return err;
}
@@ -3626,13 +3626,16 @@ static int selinux_inet_conn_request(str
return 0;
}
- err = selinux_xfrm_decode_session(skb, peersid, 0);
- BUG_ON(err);
+ if (selinux_compat_net) {
+ err = selinux_xfrm_decode_session(skb, peersid, 0);
+ BUG_ON(err);
- if (peersid == SECSID_NULL) {
- req-secid = sksec-sid;
- return 0;
- }
+ if (peersid == SECSID_NULL) {
+ req-secid = sksec-sid;
+ return 0;
+ }
+ } else
+ peersid = skb-secmark;
err = security_sid_mls_copy(sksec-sid, peersid, newsid);
if (err)
@@ -3662,6 +3665,69 @@ static void selinux_req_classify_flow(co
fl-secid = req-secid;
}
+static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
+{
+ u32 xfrm_sid, trans_sid;
+ int err;
+
+ if (selinux_compat_net)
+ return 1;
+
+ /* xfrm/cipso inapplicable for loopback traffic */
+ if (skb-dev == loopback_dev)
+ return 1;
Just to clarify (I believe this is the case from your remarks as well as
the code, but better safe than sorry) the secmark for loopback traffic
is set by the originating socket, yes?
Beware: a bit of a nit follows :)
While I understand that NetLabel currently only supports CIPSO, it is a
framework that can support multiple labeling procotols (i.e. RIPSO
support is planned). Please change the comment from cipso/CIPSO to
netlabel/NetLabel so it is consistent with the rest of the code which
makes use of NetLabel.
+ err = selinux_xfrm_decode_session(skb, xfrm_sid, 0);
+ BUG_ON(err);
+
+ err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (xfrm_sid) {
+ err = security_transition_sid(xfrm_sid, skb-secmark,
+ SECCLASS_PACKET, trans_sid);
+ if (err)
+ goto out;
+
+ skb-secmark = trans_sid;
+ }
+ /* See if CIPSO can flow in thru the current secmark here */
Same nit applies about the use of CIPSO vs NetLabel.
+out:
+ return err ? 0 : 1;
+};
+
+static int selinux_skb_flow_out(struct sk_buff *skb, u32 nf_secid)
+{
+ u32 trans_sid;
+ int err;
+
+ if (selinux_compat_net)
+ return 1;
+
+ if (!skb-secmark) {
+ u32 xfrm_sid;
+
+ selinux_skb_xfrm_sid(skb, xfrm_sid);
+
+ if (xfrm_sid)
+ skb-secmark = xfrm_sid;
+ else if (skb-sk) {
+ struct sk_security_struct *sksec = skb-sk-sk_security;
+ skb-secmark = sksec-sid;
+ }
+ }
+
+ err = avc_has_perm(skb-secmark, nf_secid, SECCLASS_PACKET,
+ PACKET__FLOW_OUT, NULL);
While I don't see any explicit mention of it in the documentation or
your comments, I assume we would want a flow_out check for NetLabel here
as well?
+out:
+ return err ? 0 : 1;
+}
+
static int selinux_nlmsg_perm(struct sock *sk, struct sk_buff *skb)
{
int err = 0;
@@ -3700,7 +3766,8 @@ out:
#ifdef CONFIG_NETFILTER
-static int selinux_ip_postroute_last_compat(struct sock *sk, struct
net_device *dev,
+static int selinux_ip_postroute_last_compat(struct sock *sk, struct sk_buff
*skb,
+
[PATCH 3/8][ATM]: [lec] header indent, comment and whitespace cleanup
please consider for 2.6.19 -- thanks!
[ATM]: [lec] header indent, comment and whitespace cleanup
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit ad9e9d30230b99dd41921b61a506c41e168e1a84
tree cc1e31605aaf3d473c4f3c8e26d9a1f9b98e72b7
parent 55300d040155e883eb8d3dd39d381c95080719e6
author chas williams - CONTRACTOR [EMAIL PROTECTED] Wed, 20 Sep 2006 18:18:44
-0400
committer chas williams - CONTRACTOR [EMAIL PROTECTED] Wed, 20 Sep 2006
18:18:44 -0400
include/linux/atmlec.h | 119 ++---
net/atm/lec.h | 172 ++--
net/atm/lec_arpc.h | 148 +
3 files changed, 235 insertions(+), 204 deletions(-)
diff --git a/include/linux/atmlec.h b/include/linux/atmlec.h
index f267f24..e7f1a75 100644
--- a/include/linux/atmlec.h
+++ b/include/linux/atmlec.h
@@ -1,9 +1,7 @@
/*
- *
- * ATM Lan Emulation Daemon vs. driver interface
- *
- * [EMAIL PROTECTED]
+ * ATM Lan Emulation Daemon driver interface
*
+ * Marko Kiiskila [EMAIL PROTECTED]
*/
#ifndef _ATMLEC_H_
@@ -13,76 +11,87 @@ #include linux/atmapi.h
#include linux/atmioc.h
#include linux/atm.h
#include linux/if_ether.h
+
/* ATM lec daemon control socket */
-#define ATMLEC_CTRL _IO('a',ATMIOC_LANE)
-#define ATMLEC_DATA _IO('a',ATMIOC_LANE+1)
-#define ATMLEC_MCAST _IO('a',ATMIOC_LANE+2)
+#define ATMLEC_CTRL_IO('a', ATMIOC_LANE)
+#define ATMLEC_DATA_IO('a', ATMIOC_LANE+1)
+#define ATMLEC_MCAST _IO('a', ATMIOC_LANE+2)
/* Maximum number of LEC interfaces (tweakable) */
#define MAX_LEC_ITF 48
-/* From the total of MAX_LEC_ITF, last NUM_TR_DEVS are reserved for Token Ring.
+/*
+ * From the total of MAX_LEC_ITF, last NUM_TR_DEVS are reserved for Token Ring.
* E.g. if MAX_LEC_ITF = 48 and NUM_TR_DEVS = 8, then lec0-lec39 are for
* Ethernet ELANs and lec40-lec47 are for Token Ring ELANS.
*/
#define NUM_TR_DEVS 8
-typedef enum {
-l_set_mac_addr, l_del_mac_addr,
-l_svc_setup,
-l_addr_delete,l_topology_change,
-l_flush_complete, l_arp_update,
-l_narp_req, /* LANE2 mandates the use of this */
-l_config, l_flush_tran_id,
-l_set_lecid, l_arp_xmt,
-l_rdesc_arp_xmt,
-l_associate_req,
-l_should_bridge /* should we bridge this MAC? */
+typedef enum {
+ l_set_mac_addr,
+ l_del_mac_addr,
+ l_svc_setup,
+ l_addr_delete,
+ l_topology_change,
+ l_flush_complete,
+ l_arp_update,
+ l_narp_req, /* LANE2 mandates the use of this */
+ l_config,
+ l_flush_tran_id,
+ l_set_lecid,
+ l_arp_xmt,
+ l_rdesc_arp_xmt,
+ l_associate_req,
+ l_should_bridge /* should we bridge this MAC? */
} atmlec_msg_type;
#define ATMLEC_MSG_TYPE_MAX l_should_bridge
struct atmlec_config_msg {
-unsigned int maximum_unknown_frame_count;
-unsigned int max_unknown_frame_time;
-unsigned short max_retry_count;
-unsigned int aging_time;
-unsigned int forward_delay_time;
-unsigned int arp_response_time;
-unsigned int flush_timeout;
-unsigned int path_switching_delay;
-unsigned int lane_version; /* LANE2: 1 for LANEv1, 2 for LANEv2 */
-int mtu;
-int is_proxy;
+ unsigned int maximum_unknown_frame_count;
+ unsigned int max_unknown_frame_time;
+ unsigned short max_retry_count;
+ unsigned int aging_time;
+ unsigned int forward_delay_time;
+ unsigned int arp_response_time;
+ unsigned int flush_timeout;
+ unsigned int path_switching_delay;
+ unsigned int lane_version; /* LANE2: 1 for LANEv1, 2 for LANEv2 */
+ int mtu;
+ int is_proxy;
};
-
+
struct atmlec_msg {
-atmlec_msg_type type;
-int sizeoftlvs;/* LANE2: if != 0, tlvs follow */
-union {
-struct {
-unsigned char mac_addr[ETH_ALEN];
-unsigned char atm_addr[ATM_ESA_LEN];
-unsigned int flag;/* Topology_change flag,
- remoteflag, permanent flag,
- lecid, transaction id */
-unsigned int targetless_le_arp; /* LANE2 */
-unsigned int no_source_le_narp; /* LANE2 */
-} normal;
-struct atmlec_config_msg config;
-struct {
-uint16_t lec_id; /* requestor
lec_id */
-uint32_t tran_id;/* transaction id
*/
-unsigned char mac_addr[ETH_ALEN];/* dst mac addr
*/
-unsigned char atm_addr[ATM_ESA_LEN]; /* reqestor ATM
addr */
-} proxy;
-/* For mapping LE_ARP
[PATCH 4/8][ATM]: [lec] convert lec_arp_table to hlist
please consider for 2.6.19 -- thanks!
[ATM]: [lec] convert lec_arp_table to hlist
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit cf14c654bcb812dae6ed85075777a19e1e02bee1
tree d01bc707baf050862e676e5609081ba1cc22aca1
parent ad9e9d30230b99dd41921b61a506c41e168e1a84
author chas williams - CONTRACTOR [EMAIL PROTECTED] Wed, 20 Sep 2006 18:52:59
-0400
committer chas williams - CONTRACTOR [EMAIL PROTECTED] Wed, 20 Sep 2006
18:52:59 -0400
net/atm/lec.c | 442 +++-
net/atm/lec.h |8 -
net/atm/lec_arpc.h |2
3 files changed, 170 insertions(+), 282 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 13aeacf..87fb0c2 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -806,7 +806,7 @@ #endif
dev_kfree_skb(skb);
return;
}
- if (priv-lec_arp_empty_ones) {
+ if (!hlist_empty(priv-lec_arp_empty_ones)) {
lec_arp_check_empties(priv, vcc, skb);
}
skb-dev = dev;
@@ -998,29 +998,32 @@ static void lec_info(struct seq_file *se
struct lec_state {
unsigned long flags;
struct lec_priv *locked;
- struct lec_arp_table *entry;
+ struct hlist_node *node;
struct net_device *dev;
int itf;
int arp_table;
int misc_table;
};
-static void *lec_tbl_walk(struct lec_state *state, struct lec_arp_table *tbl,
+static void *lec_tbl_walk(struct lec_state *state, struct hlist_head *tbl,
loff_t *l)
{
- struct lec_arp_table *e = state-entry;
+ struct hlist_node *e = state-node;
+ struct lec_arp_table *tmp;
if (!e)
- e = tbl;
+ e = tbl-first;
if (e == (void *)1) {
- e = tbl;
+ e = tbl-first;
--*l;
}
- for (; e; e = e-next) {
+
+ hlist_for_each_entry_from(tmp, e, next) {
if (--*l 0)
break;
}
- state-entry = e;
+ state-node = e;
+
return (*l 0) ? state : NULL;
}
@@ -1031,7 +1034,7 @@ static void *lec_arp_walk(struct lec_sta
int p;
for (p = state-arp_table; p LEC_ARP_TABLE_SIZE; p++) {
- v = lec_tbl_walk(state, priv-lec_arp_tables[p], l);
+ v = lec_tbl_walk(state, priv-lec_arp_tables[p], l);
if (v)
break;
}
@@ -1042,10 +1045,10 @@ static void *lec_arp_walk(struct lec_sta
static void *lec_misc_walk(struct lec_state *state, loff_t *l,
struct lec_priv *priv)
{
- struct lec_arp_table *lec_misc_tables[] = {
- priv-lec_arp_empty_ones,
- priv-lec_no_forward,
- priv-mcast_fwds
+ struct hlist_head *lec_misc_tables[] = {
+ priv-lec_arp_empty_ones,
+ priv-lec_no_forward,
+ priv-mcast_fwds
};
void *v = NULL;
int q;
@@ -1112,7 +1115,7 @@ static void *lec_seq_start(struct seq_fi
state-locked = NULL;
state-arp_table = 0;
state-misc_table = 0;
- state-entry = (void *)1;
+ state-node = (void *)1;
return *pos ? lec_get_idx(state, *pos) : (void *)1;
}
@@ -1148,9 +1151,10 @@ static int lec_seq_show(struct seq_file
else {
struct lec_state *state = seq-private;
struct net_device *dev = state-dev;
+ struct lec_arp_table *entry = hlist_entry(state-node, struct
lec_arp_table, next);
seq_printf(seq, %s , dev-name);
- lec_info(seq, state-entry);
+ lec_info(seq, entry);
}
return 0;
}
@@ -1455,8 +1459,11 @@ static void lec_arp_init(struct lec_priv
unsigned short i;
for (i = 0; i LEC_ARP_TABLE_SIZE; i++) {
- priv-lec_arp_tables[i] = NULL;
+ INIT_HLIST_HEAD(priv-lec_arp_tables[i]);
}
+INIT_HLIST_HEAD(priv-lec_arp_empty_ones);
+INIT_HLIST_HEAD(priv-lec_no_forward);
+INIT_HLIST_HEAD(priv-mcast_fwds);
spin_lock_init(priv-lec_arp_lock);
init_timer(priv-lec_arp_timer);
priv-lec_arp_timer.expires = jiffies + LEC_ARP_REFRESH_INTERVAL;
@@ -1479,7 +1486,7 @@ static void lec_arp_clear_vccs(struct le
vcc-user_back = NULL;
vcc-push = entry-old_push;
vcc_release_async(vcc, -EPIPE);
- vcc = NULL;
+ entry-vcc = NULL;
}
if (entry-recv_vcc) {
entry-recv_vcc-push = entry-old_recv_push;
@@ -1493,27 +1500,17 @@ static void lec_arp_clear_vccs(struct le
* LANE2: Add to the end of the list to satisfy 8.1.13
*/
static inline void
-lec_arp_add(struct lec_priv *priv, struct lec_arp_table *to_add)
+lec_arp_add(struct lec_priv *priv, struct lec_arp_table *entry)
{
-
[PATCH 5/8][ATM]: [lec] old_close is no longer used
please consider for 2.6.19 -- thanks!
[ATM]: [lec] old_close is no longer used
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit 693b186c2a764f62e017db4b7ed39298831d99e8
tree d054ccd10917693803070634a21481b09361b126
parent cf14c654bcb812dae6ed85075777a19e1e02bee1
author chas williams - CONTRACTOR [EMAIL PROTECTED] Wed, 20 Sep 2006 18:54:09
-0400
committer chas williams - CONTRACTOR [EMAIL PROTECTED] Wed, 20 Sep 2006
18:54:09 -0400
net/atm/lec_arpc.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/atm/lec_arpc.h b/net/atm/lec_arpc.h
index 3cc2eba..69aeb07 100644
--- a/net/atm/lec_arpc.h
+++ b/net/atm/lec_arpc.h
@@ -24,9 +24,6 @@ struct lec_arp_table {
void (*old_recv_push) (struct atm_vcc *vcc, struct sk_buff *skb);
/* Push that leads to daemon */
- void (*old_close) (struct atm_vcc *vcc);
- /* We want to see when this vcc gets
closed */
-
unsigned long last_used;/* For expiry */
unsigned long timestamp;/* Used for various timestamping things:
* 1. FLUSH started
-
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 6/8][ATM]: [lec] use work queue instead of timer for lec arp expiry
please consider for 2.6.19 -- thanks!
[ATM]: [lec] use work queue instead of timer for lec arp expiry
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit 0152dcfb9d42e203ff26d1619158c9664cfbf2d9
tree 24d0a36e52e7d4e86dd7bf1422ae9948011a194d
parent 693b186c2a764f62e017db4b7ed39298831d99e8
author chas williams - CONTRACTOR [EMAIL PROTECTED] Mon, 25 Sep 2006 07:22:57
-0400
committer chas williams - CONTRACTOR [EMAIL PROTECTED] Mon, 25 Sep 2006
07:22:57 -0400
net/atm/lec.c | 17 +++--
net/atm/lec.h |2 +-
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 87fb0c2..8a9f9ab 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -1442,7 +1442,7 @@ #define DEBUG_ARP_TABLE 0
#define LEC_ARP_REFRESH_INTERVAL (3*HZ)
-static void lec_arp_check_expire(unsigned long data);
+static void lec_arp_check_expire(void *data);
static void lec_arp_expire_arp(unsigned long data);
/*
@@ -1465,11 +1465,8 @@ static void lec_arp_init(struct lec_priv
INIT_HLIST_HEAD(priv-lec_no_forward);
INIT_HLIST_HEAD(priv-mcast_fwds);
spin_lock_init(priv-lec_arp_lock);
- init_timer(priv-lec_arp_timer);
- priv-lec_arp_timer.expires = jiffies + LEC_ARP_REFRESH_INTERVAL;
- priv-lec_arp_timer.data = (unsigned long)priv;
- priv-lec_arp_timer.function = lec_arp_check_expire;
- add_timer(priv-lec_arp_timer);
+ INIT_WORK(priv-lec_arp_work, lec_arp_check_expire, priv);
+ schedule_delayed_work(priv-lec_arp_work, LEC_ARP_REFRESH_INTERVAL);
}
static void lec_arp_clear_vccs(struct lec_arp_table *entry)
@@ -1719,7 +1716,7 @@ static void lec_arp_destroy(struct lec_p
struct lec_arp_table *entry;
int i;
- del_timer_sync(priv-lec_arp_timer);
+ cancel_rearming_delayed_work(priv-lec_arp_work);
/*
* Remove all entries
@@ -1865,10 +1862,10 @@ static void lec_arp_expire_vcc(unsigned
* to ESI_FORWARD_DIRECT. This causes the flush period to end
* regardless of the progress of the flush protocol.
*/
-static void lec_arp_check_expire(unsigned long data)
+static void lec_arp_check_expire(void *data)
{
unsigned long flags;
- struct lec_priv *priv = (struct lec_priv *)data;
+ struct lec_priv *priv = data;
struct hlist_node *node, *next;
struct lec_arp_table *entry;
unsigned long now;
@@ -1930,7 +1927,7 @@ static void lec_arp_check_expire(unsigne
}
spin_unlock_irqrestore(priv-lec_arp_lock, flags);
- mod_timer(priv-lec_arp_timer, jiffies + LEC_ARP_REFRESH_INTERVAL);
+ schedule_delayed_work(priv-lec_arp_work, LEC_ARP_REFRESH_INTERVAL);
}
/*
diff --git a/net/atm/lec.h b/net/atm/lec.h
index 8a6cb64..5bf3544 100644
--- a/net/atm/lec.h
+++ b/net/atm/lec.h
@@ -93,7 +93,7 @@ struct lec_priv {
spinlock_t lec_arp_lock;
struct atm_vcc *mcast_vcc; /* Default Multicast Send VCC */
struct atm_vcc *lecd;
- struct timer_list lec_arp_timer;/* C10 */
+ struct work_struct lec_arp_work;/* C10 */
unsigned int maximum_unknown_frame_count;
/*
* Within the period of time
defined by this variable, the client will send
-
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 7/8][ATM]: [lec] add reference counting to lec_arp entries
please consider for 2.6.19 -- thanks!
[ATM]: [lec] add reference counting to lec_arp entries
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit 397725689277192a899da4009cd078bab8f6ee2d
tree 3bba44e1549229947ed332bb6263c704cabd55c7
parent 0152dcfb9d42e203ff26d1619158c9664cfbf2d9
author chas williams - CONTRACTOR [EMAIL PROTECTED] Mon, 25 Sep 2006 07:28:18
-0400
committer chas williams - CONTRACTOR [EMAIL PROTECTED] Mon, 25 Sep 2006
07:28:18 -0400
net/atm/lec.c | 42 --
net/atm/lec_arpc.h |1 +
2 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 8a9f9ab..c865f68 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -107,6 +107,19 @@ static void lec_vcc_added(struct lec_pri
struct sk_buff *skb));
static void lec_vcc_close(struct lec_priv *priv, struct atm_vcc *vcc);
+/* must be done under lec_arp_lock */
+static inline void lec_arp_hold(struct lec_arp_table *entry)
+{
+ atomic_inc(entry-usage);
+}
+
+static inline void lec_arp_put(struct lec_arp_table *entry)
+{
+ if (atomic_dec_and_test(entry-usage))
+ kfree(entry);
+}
+
+
static struct lane2_ops lane2_ops = {
lane2_resolve, /* resolve, spec 3.1.3 */
lane2_associate_req,/* associate_req, spec 3.1.4 */
@@ -795,7 +808,7 @@ #endif
entry = lec_arp_find(priv, src);
if (entry entry-vcc != vcc) {
lec_arp_remove(priv, entry);
- kfree(entry);
+ lec_arp_put(entry);
}
}
spin_unlock_irqrestore(priv-lec_arp_lock, flags);
@@ -1726,7 +1739,7 @@ static void lec_arp_destroy(struct lec_p
for (i = 0; i LEC_ARP_TABLE_SIZE; i++) {
hlist_for_each_entry_safe(entry, node, next,
priv-lec_arp_tables[i], next) {
lec_arp_remove(priv, entry);
- kfree(entry);
+ lec_arp_put(entry);
}
INIT_HLIST_HEAD(priv-lec_arp_tables[i]);
}
@@ -1735,7 +1748,7 @@ static void lec_arp_destroy(struct lec_p
del_timer_sync(entry-timer);
lec_arp_clear_vccs(entry);
hlist_del(entry-next);
- kfree(entry);
+ lec_arp_put(entry);
}
INIT_HLIST_HEAD(priv-lec_arp_empty_ones);
@@ -1743,7 +1756,7 @@ static void lec_arp_destroy(struct lec_p
del_timer_sync(entry-timer);
lec_arp_clear_vccs(entry);
hlist_del(entry-next);
- kfree(entry);
+ lec_arp_put(entry);
}
INIT_HLIST_HEAD(priv-lec_no_forward);
@@ -1751,7 +1764,7 @@ static void lec_arp_destroy(struct lec_p
/* No timer, LANEv2 7.1.20 and 2.3.5.3 */
lec_arp_clear_vccs(entry);
hlist_del(entry-next);
- kfree(entry);
+ lec_arp_put(entry);
}
INIT_HLIST_HEAD(priv-mcast_fwds);
priv-mcast_vcc = NULL;
@@ -1799,6 +1812,7 @@ static struct lec_arp_table *make_entry(
to_return-last_used = jiffies;
to_return-priv = priv;
skb_queue_head_init(to_return-tx_wait);
+ atomic_set(to_return-usage, 1);
return to_return;
}
@@ -1843,7 +1857,7 @@ static void lec_arp_expire_vcc(unsigned
spin_unlock_irqrestore(priv-lec_arp_lock, flags);
lec_arp_clear_vccs(to_remove);
- kfree(to_remove);
+ lec_arp_put(to_remove);
}
/*
@@ -1891,7 +1905,7 @@ static void lec_arp_check_expire(void *d
/* Remove entry */
DPRINTK(LEC:Entry timed out\n);
lec_arp_remove(priv, entry);
- kfree(entry);
+ lec_arp_put(entry);
} else {
/* Something else */
if ((entry-status == ESI_VC_PENDING ||
@@ -2045,7 +2059,7 @@ lec_addr_delete(struct lec_priv *priv, u
(permanent ||
!(entry-flags LEC_PERMANENT_FLAG))) {
lec_arp_remove(priv, entry);
- kfree(entry);
+ lec_arp_put(entry);
}
spin_unlock_irqrestore(priv-lec_arp_lock, flags);
return 0;
@@ -2094,7 +2108,7 @@ lec_arp_update(struct lec_priv *priv, un
tmp-old_push = entry-old_push;
tmp-last_used = jiffies;
del_timer(entry-timer);
- kfree(entry);
+
[PATCH 8/8][ATM]: [lec] use refcnt to protect lec_arp_entries outside lock
please consider for 2.6.19 -- thanks!
[ATM]: [lec] use refcnt to protect lec_arp_entries outside lock
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit 74391472d01cdd483714b807c9417a0279ed75d5
tree a191d09973b569f0562d9d433c324bbe80a08560
parent 397725689277192a899da4009cd078bab8f6ee2d
author chas williams - CONTRACTOR [EMAIL PROTECTED] Mon, 25 Sep 2006 22:07:01
-0400
committer chas williams - CONTRACTOR [EMAIL PROTECTED] Mon, 25 Sep 2006
22:07:01 -0400
net/atm/lec.c | 34 --
1 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index c865f68..9e635a0 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -396,7 +396,7 @@ #endif
priv-stats.tx_dropped++;
dev_kfree_skb(skb);
}
- return 0;
+ goto out;
}
#if DUMP_PACKETS 0
printk(%s:sending to vpi:%d vci:%d\n, dev-name, vcc-vpi, vcc-vci);
@@ -428,6 +428,9 @@ #endif /* DUMP_PACKETS 0 */
netif_wake_queue(dev);
}
+out:
+ if (entry)
+ lec_arp_put(entry);
dev-trans_start = jiffies;
return 0;
}
@@ -1888,6 +1891,7 @@ static void lec_arp_check_expire(void *d
DPRINTK(lec_arp_check_expire %p\n, priv);
now = jiffies;
+restart:
spin_lock_irqsave(priv-lec_arp_lock, flags);
for (i = 0; i LEC_ARP_TABLE_SIZE; i++) {
hlist_for_each_entry_safe(entry, node, next,
priv-lec_arp_tables[i], next) {
@@ -1927,14 +1931,16 @@ static void lec_arp_check_expire(void *d
time_after_eq(now, entry-timestamp +
priv-path_switching_delay)) {
struct sk_buff *skb;
+ struct atm_vcc *vcc = entry-vcc;
- while ((skb =
- skb_dequeue(entry-tx_wait)) !=
- NULL)
- lec_send(entry-vcc, skb,
-entry-priv);
+ lec_arp_hold(entry);
+
spin_unlock_irqrestore(priv-lec_arp_lock, flags);
+ while ((skb =
skb_dequeue(entry-tx_wait)) != NULL)
+ lec_send(vcc, skb, entry-priv);
entry-last_used = jiffies;
entry-status = ESI_FORWARD_DIRECT;
+ lec_arp_put(entry);
+ goto restart;
}
}
}
@@ -1977,6 +1983,7 @@ static struct atm_vcc *lec_arp_resolve(s
if (entry-status == ESI_FORWARD_DIRECT) {
/* Connection Ok */
entry-last_used = jiffies;
+ lec_arp_hold(entry);
*ret_entry = entry;
found = entry-vcc;
goto out;
@@ -2007,6 +2014,7 @@ static struct atm_vcc *lec_arp_resolve(s
* or BUS flood limit was reached for an entry which is
* in ESI_ARP_PENDING or ESI_VC_PENDING state.
*/
+ lec_arp_hold(entry);
*ret_entry = entry;
DPRINTK(lec: entry-status %d entry-vcc %p\n, entry-status,
entry-vcc);
@@ -2335,18 +2343,24 @@ static void lec_flush_complete(struct le
int i;
DPRINTK(LEC:lec_flush_complete %lx\n, tran_id);
+restart:
spin_lock_irqsave(priv-lec_arp_lock, flags);
for (i = 0; i LEC_ARP_TABLE_SIZE; i++) {
hlist_for_each_entry(entry, node, priv-lec_arp_tables[i],
next) {
if (entry-flush_tran_id == tran_id
entry-status == ESI_FLUSH_PENDING) {
struct sk_buff *skb;
+ struct atm_vcc *vcc = entry-vcc;
- while ((skb =
- skb_dequeue(entry-tx_wait)) != NULL)
- lec_send(entry-vcc, skb, entry-priv);
+ lec_arp_hold(entry);
+ spin_unlock_irqrestore(priv-lec_arp_lock,
flags);
+ while ((skb = skb_dequeue(entry-tx_wait)) !=
NULL)
+ lec_send(vcc, skb, entry-priv);
+ entry-last_used = jiffies;
entry-status = ESI_FORWARD_DIRECT;
+ lec_arp_put(entry);
DPRINTK(LEC_ARP: Flushed\n);
+
Re: [PATCH 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 29 Sep 2006, Paul Moore wrote: It seems more of a pain to actually prevent their use at the same time and/or explain strange/unnatural behavior. Agreed, the solution that we agreed upon is much easier to implement and explain than a lot of the alternatives. Ok, can you please explain it further? i.e. show me what the policy looks like, exactly what the user is trying to achieve, and explain what happens to each packet exactly in terms of labeling on the input and output paths. -- 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: mii-tool gigabit support.
On Fri, 29 Sep 2006 12:12:58 -0400 David Hollis [EMAIL PROTECTED] wrote: On Wed, 2006-09-27 at 12:32 -0700, Auke Kok wrote: dumping registers in readable format is an extension that needs to be implemented per driver. Not all nics have done this - we just did it ourselves for ixgb, and I saw skge/sky2 just fly by this week. This has always bothered me a bit with ethtool. It really stinks that we have to actually write code and generate patches and get everyone to update a utility just to be able to get this type of access. I see two ways to make the situation better: 1) add extensions to the drivers themselves to be able to report this which would likely lead to a lot of driver bloat and too much user-space style info (like verbose descriptions of the register and it's purpose) or 2) develop some style of register description definition type of text file, maybe XML, maybe INI style or something stored in /etc/ethtool as drivername.conf or something like that. This way, ethtool doesn't have to be changed/updated/patched/likely-bug-added for every single device known to man. Just a thought. We could switch to shared libraries like 'tc' uses. -- 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 7/7] secid reconciliation-v03: Enforcement for SELinux
+static int selinux_skb_flow_in(struct sk_buff *skb,
unsigned short family)
+{
+ u32 xfrm_sid, trans_sid;
+ int err;
+
+ if (selinux_compat_net)
+ return 1;
+
+ /* xfrm/cipso inapplicable for loopback traffic */
+ if (skb-dev == loopback_dev)
+ return 1;
Just to clarify (I believe this is the case from your remarks
as well as
the code, but better safe than sorry) the secmark for loopback traffic
is set by the originating socket, yes?
That's correct.
Beware: a bit of a nit follows :)
While I understand that NetLabel currently only supports
CIPSO, it is a
framework that can support multiple labeling procotols (i.e. RIPSO
support is planned). Please change the comment from cipso/CIPSO to
netlabel/NetLabel so it is consistent with the rest of the code which
makes use of NetLabel.
Sure.
+ err = selinux_xfrm_decode_session(skb, xfrm_sid, 0);
+ BUG_ON(err);
+
+ err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (xfrm_sid) {
+ err = security_transition_sid(xfrm_sid, skb-secmark,
+
SECCLASS_PACKET, trans_sid);
+ if (err)
+ goto out;
+
+ skb-secmark = trans_sid;
+ }
+ /* See if CIPSO can flow in thru the current secmark here */
Same nit applies about the use of CIPSO vs NetLabel.
Sure.
+out:
+ return err ? 0 : 1;
+};
+
+static int selinux_skb_flow_out(struct sk_buff *skb, u32 nf_secid)
+{
+ u32 trans_sid;
+ int err;
+
+ if (selinux_compat_net)
+ return 1;
+
+ if (!skb-secmark) {
+ u32 xfrm_sid;
+
+ selinux_skb_xfrm_sid(skb, xfrm_sid);
+
+ if (xfrm_sid)
+ skb-secmark = xfrm_sid;
+ else if (skb-sk) {
+ struct sk_security_struct *sksec =
skb-sk-sk_security;
+ skb-secmark = sksec-sid;
+ }
+ }
+
+ err = avc_has_perm(skb-secmark, nf_secid, SECCLASS_PACKET,
+ PACKET__FLOW_OUT, NULL);
While I don't see any explicit mention of it in the documentation or
your comments, I assume we would want a flow_out check for
NetLabel here
as well?
I don't believe we do. By this time, the packet is or should already be
carrying the CIPSO/NetLabel option which should already be the right one
(derived from the socket or flow as appropriate), but you would want to
audit the code to make sure. IOW, the label option in the IP header should
already be reflecting the secmark on the skb. But again, you may want to
audit the code to make sure.
+out:
+ return err ? 0 : 1;
+}
+
static int selinux_nlmsg_perm(struct sock *sk, struct sk_buff *skb)
{
int err = 0;
@@ -3700,7 +3766,8 @@ out:
#ifdef CONFIG_NETFILTER
-static int selinux_ip_postroute_last_compat(struct sock
*sk, struct net_device *dev,
+static int selinux_ip_postroute_last_compat(struct sock
*sk, struct sk_buff *skb,
+ struct net_device *dev,
struct avc_audit_data *ad,
u16 family, char
*addrp, int len)
{
@@ -3710,6 +3777,9 @@ static int selinux_ip_postroute_last_com
struct inode *inode;
struct inode_security_struct *isec;
+ if (!sk)
+ goto out;
+
sock = sk-sk_socket;
if (!sock)
goto out;
@@ -3768,7 +3838,11 @@ static int selinux_ip_postroute_last_com
err = avc_has_perm(isec-sid, port_sid, isec-sclass,
send_perm, ad);
+ if (err)
+ goto out;
}
+
+ err = selinux_xfrm_postroute_last(isec-sid, skb, ad);
out:
return err;
}
@@ -3782,17 +3856,9 @@ static unsigned int selinux_ip_postroute
{
char *addrp;
int len, err = 0;
- struct sock *sk;
struct sk_buff *skb = *pskb;
struct avc_audit_data ad;
struct net_device *dev = (struct net_device *)out;
- struct sk_security_struct *sksec;
-
- sk = skb-sk;
- if (!sk)
- goto out;
-
- sksec = sk-sk_security;
AVC_AUDIT_DATA_INIT(ad, NET);
ad.u.net.netif = dev-name;
@@ -3803,16 +3869,25 @@ static unsigned int selinux_ip_postroute
goto out;
if (selinux_compat_net)
- err = selinux_ip_postroute_last_compat(sk, dev, ad,
+ err = selinux_ip_postroute_last_compat(skb-sk,
skb, dev, ad,
family,
addrp, len);
- else
- err = avc_has_perm(sksec-sid, skb-secmark,
SECCLASS_PACKET,
- PACKET__SEND, ad);
+ else {
+ if (!skb-secmark) {
+
Re: [PATCH 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 29 Sep 2006, James Morris wrote: On Fri, 29 Sep 2006, Paul Moore wrote: It seems more of a pain to actually prevent their use at the same time and/or explain strange/unnatural behavior. Agreed, the solution that we agreed upon is much easier to implement and explain than a lot of the alternatives. Ok, can you please explain it further? i.e. show me what the policy looks like, exactly what the user is trying to achieve, and explain what happens to each packet exactly in terms of labeling on the input and output paths. Also, why can't this be done just with xfrm labeling? CIPSO is not there to provide a mechanism for separating the label of the connection from the label of the data, it's only there to provide interop with legacy systems. If you need to have two labels for a packet (the object and the domain), then this needs to be supported directly by xfrm labeling. - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
Venkat Yekkirala wrote:
+static int selinux_skb_flow_out(struct sk_buff *skb, u32 nf_secid)
+{
+u32 trans_sid;
+int err;
+
+if (selinux_compat_net)
+return 1;
+
+if (!skb-secmark) {
+u32 xfrm_sid;
+
+selinux_skb_xfrm_sid(skb, xfrm_sid);
+
+if (xfrm_sid)
+skb-secmark = xfrm_sid;
+else if (skb-sk) {
+struct sk_security_struct *sksec =
skb-sk-sk_security;
+skb-secmark = sksec-sid;
+}
+}
+
+err = avc_has_perm(skb-secmark, nf_secid, SECCLASS_PACKET,
+PACKET__FLOW_OUT, NULL);
While I don't see any explicit mention of it in the documentation or
your comments, I assume we would want a flow_out check for
NetLabel here
as well?
I don't believe we do. By this time, the packet is or should already be
carrying the CIPSO/NetLabel option which should already be the right one
(derived from the socket or flow as appropriate), but you would want to
audit the code to make sure. IOW, the label option in the IP header should
already be reflecting the secmark on the skb. But again, you may want to
audit the code to make sure.
In the case above I am concerned about the situation where the
skb-secmark == 0 and there is a IPv4 option (i.e. it is NetLabel
labeled) on the packet. It would seem that the right/consistent thing
to do would be to adjust the secmark accordingly, similar to what we
would do on the flow_in case, yes?
+static int selinux_ip_postroute_last_compat(struct sock
*sk, struct sk_buff *skb,
+struct net_device *dev,
struct avc_audit_data *ad,
u16 family, char
*addrp, int len)
{
@@ -3710,6 +3777,9 @@ static int selinux_ip_postroute_last_com
struct inode *inode;
struct inode_security_struct *isec;
+if (!sk)
+goto out;
+
sock = sk-sk_socket;
if (!sock)
goto out;
@@ -3768,7 +3838,11 @@ static int selinux_ip_postroute_last_com
err = avc_has_perm(isec-sid, port_sid, isec-sclass,
send_perm, ad);
+if (err)
+goto out;
}
+
+err = selinux_xfrm_postroute_last(isec-sid, skb, ad);
out:
return err;
}
@@ -3782,17 +3856,9 @@ static unsigned int selinux_ip_postroute
{
char *addrp;
int len, err = 0;
-struct sock *sk;
struct sk_buff *skb = *pskb;
struct avc_audit_data ad;
struct net_device *dev = (struct net_device *)out;
-struct sk_security_struct *sksec;
-
-sk = skb-sk;
-if (!sk)
-goto out;
-
-sksec = sk-sk_security;
AVC_AUDIT_DATA_INIT(ad, NET);
ad.u.net.netif = dev-name;
@@ -3803,16 +3869,25 @@ static unsigned int selinux_ip_postroute
goto out;
if (selinux_compat_net)
-err = selinux_ip_postroute_last_compat(sk, dev, ad,
+err = selinux_ip_postroute_last_compat(skb-sk,
skb, dev, ad,
family,
addrp, len);
-else
-err = avc_has_perm(sksec-sid, skb-secmark,
SECCLASS_PACKET,
- PACKET__SEND, ad);
+else {
+if (!skb-secmark) {
+u32 xfrm_sid;
-if (err)
-goto out;
+selinux_skb_xfrm_sid(skb, xfrm_sid);
-err = selinux_xfrm_postroute_last(sksec-sid, skb, ad);
+if (xfrm_sid)
+skb-secmark = xfrm_sid;
+else if (skb-sk) {
+struct sk_security_struct *sksec =
+skb-sk-sk_security;
+skb-secmark = sksec-sid;
+}
+}
+err = avc_has_perm(skb-secmark, SECINITSID_UNLABELED,
+ SECCLASS_PACKET,
PACKET__FLOW_OUT, ad);
+}
This looks nearly identical to selinux_skb_flow_out() as implemented
above, the only real differences being two of the args to the
avc_has_perm() call. Any reason you don't abstract out the
common parts
to a separate function?
May be in the future.
Also, the same comment/question about NetLabel support in
selinux_skb_flow_out() applies here as well I suspect.
My comments earlier should apply here as well.
Mine too :)
--
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 7/7] secid reconciliation-v03: Enforcement for SELinux
James Morris wrote:
On Fri, 29 Sep 2006, Paul Moore wrote:
It seems more of a pain to actually
prevent their use at the same time and/or explain strange/unnatural
behavior.
Agreed, the solution that we agreed upon is much easier to implement and
explain than a lot of the alternatives.
Ok, can you please explain it further?
i.e. show me what the policy looks like, exactly what the user is trying
to achieve, and explain what happens to each packet exactly in terms of
labeling on the input and output paths.
All right, here is my take on it, perhaps Venkat can chime in too.
* packet labeling, input
Code below is taken from the secid patchset, minus the SID transition
code as it sounds like that is going to be dropped. Please note that
this is not a patch just something to help explain.
+static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
+{
+ u32 xfrm_sid, trans_sid;
u32 nlbl_sid;
+ int err;
+
+ if (selinux_compat_net)
+ return 1;
+
+ /* xfrm/cipso inapplicable for loopback traffic */
+ if (skb-dev == loopback_dev)
+ return 1;
+
+ err = selinux_xfrm_decode_session(skb, xfrm_sid, 0);
+ BUG_ON(err);
+
+ err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
if (xfrm_sid)
skb-secmark = xfrm_sid;
err = selinux_netlbl_skbuff_getsid(skb,
skb-secmark,
nlbl_sid);
if (err)
goto out;
if (nlbl_sid != SECINITSID_UNLABELED) {
/* not sure if we want this avc check above this if
* block? */
err = avc_has_perm(nlbl_sid,
skb-secmark,
SECCLASS_PACKET,
PACKET__FLOW_IN,
NULL);
if (err)
goto out;
skb-secmark = nlbl_sid;
}
+
+out:
+ return err ? 0 : 1;
+};
* packet labeling, output
This is currently being discussed, so take this with a few grains of salt.
+static int selinux_skb_flow_out(struct sk_buff *skb, u32 nf_secid)
+{
+ u32 trans_sid;
u32 nlbl_sid;
+ int err;
+
+ if (selinux_compat_net)
+ return 1;
+
+ if (!skb-secmark) {
+ u32 xfrm_sid;
+
+ selinux_skb_xfrm_sid(skb, xfrm_sid);
+
+ if (xfrm_sid)
+ skb-secmark = xfrm_sid;
+ else if (skb-sk) {
+ struct sk_security_struct *sksec =
+ skb-sk-sk_security;
+ skb-secmark = sksec-sid;
+ }
err = selinux_netlbl_skbuff_getsid(skb,
skb-secmark,
nlbl_sid);
if (err)
goto out;
if (nlbl_sid != SECINITSID_UNLABELED) {
err = avc_has_perm(nlbl_sid,
skb-secmark,
SECCLASS_PACKET,
PACKET__FLOW_OUT,
NULL);
if (err)
goto out;
skb-secmark = nlbl_sid;
}
+ }
+
+ err = avc_has_perm(skb-secmark, nf_secid, SECCLASS_PACKET,
+ PACKET__FLOW_OUT, NULL);
+
+out:
+ return err ? 0 : 1;
+}
* pseudo policy
Since NetLabel presently only provides a MLS label I don't believe there
would be any additional SELinux allow rules beyond those needed for
IPsec labeling (maybe in the flow_out, not sure). The MLS/MCS
constraints would be the only thing affected I believe, and even then
the existing constraints should suffice.
--
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 7/7] secid reconciliation-v03: Enforcement for SELinux
James Morris wrote: On Fri, 29 Sep 2006, James Morris wrote: On Fri, 29 Sep 2006, Paul Moore wrote: It seems more of a pain to actually prevent their use at the same time and/or explain strange/unnatural behavior. Agreed, the solution that we agreed upon is much easier to implement and explain than a lot of the alternatives. Ok, can you please explain it further? i.e. show me what the policy looks like, exactly what the user is trying to achieve, and explain what happens to each packet exactly in terms of labeling on the input and output paths. Also, why can't this be done just with xfrm labeling? I believe the issue Venkat and I were discussing was how to handle the case of multiple external labeling protocols, i.e. what to do if we get a packet through labeled SA which has a CIPSO option. As I've said before, I don't believe this is something we will see much in practice but I think we need to decide what to do: handle it somehow or just punt on the problem and drop it. Several people with experience with external labeling have commented on how supporting both external labeling protocols would be a good idea so Venkat and I are trying to come up with a solution that works. Please see my reponse with the pseudo code/policy examples as this might help clear things up. -- 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: mii-tool gigabit support.
2) develop some style of register description definition type of text file, maybe XML, maybe INI style or something stored in /etc/ethtool as drivername.conf or something like that. This way, ethtool doesn't have to be changed/updated/patched/likely-bug-added for every single device known to man. Just a thought. We could switch to shared libraries like 'tc' uses. From a practical standpoint is shipping a new config file or a new shared library all that much different from a new ethtool binary? rick - 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
rewriting skb-truesize... good or bad idea
Hi Folks I was looking at SCTP performance problem that is a result of receive buffer exhaustion and found the we severely overcharge the receive buffer when multiple data chunks are bundled together. This bundling usually happens at retransmit time which penalizes us even more. Here is what happens. For every data chunk that SCTP stack receives, we clone skb of that data chunk, charge the receive buffer for the skb, and put the chunk on the the socket receive queue (this is skipping a few steps, but they don't matter for the sake of this discussion). We charge the receive buffer with the skb-truesize. The problem shows up when multiple data chunks are bundled into the same skb. We end up with multiple clones, and for each clone we charge skb-truesize against the receive buffer. However, since skb_clone() preservers the original truesize in all clones, we end up overcharging. One of the proposed solutions is change the skb-truesize of the clone to just be sizeof(struct sk_buff), if and only if this is not the first data chunk in the packet. I've attached the patch, in case people want to look at the code. However, we question if this is a good idea or if this is going to break things... Thanks -vlad diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c index 5b5ae79..9bb1dbd 100644 --- a/net/sctp/sm_statefuns.c +++ b/net/sctp/sm_statefuns.c @@ -5349,7 +5349,7 @@ static int sctp_eat_data(const struct sc if (SCTP_CMD_CHUNK_ULP == deliver) sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_TSN, SCTP_U32(tsn)); - chunk-data_accepted = 1; + chunk-data_accepted++; /* Note: Some chunks may get overcounted (if we drop) or overcounted * if we renege and the chunk arrives again. diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c index ee23678..0e1f11d 100644 --- a/net/sctp/ulpevent.c +++ b/net/sctp/ulpevent.c @@ -685,6 +685,17 @@ struct sctp_ulpevent *sctp_ulpevent_make /* Initialize event with flags 0. */ sctp_ulpevent_init(event, 0); + /* Check to see if we need to fixup the truesize of the clone. +* We are about to charge the receive buffer for this chunk, +* and we always use skb-truesize. However, this doesn't work +* for bundled data chunks since we'll drastically overcharge. +* To get around that, keep the oiginal truesize on the clone +* only for the first data chunk, and update truesize for the clone +* on subsequent ones. +*/ + if (chunk-data_accepted 1) + skb-truesize = sizeof(struct skb); + sctp_ulpevent_receive_data(event, asoc); event-stream = ntohs(chunk-subh.data_hdr-stream);
Re: sky2 (was Re: 2.6.18-mm2)
On Thu, Sep 28, 2006 at 04:30:23PM -0700, Stephen Hemminger wrote: Note: I know what is causing all the sky2 problems, there is something wrong that is causing flow control negotiation not to propagate back to all the multiple levels of the chip. Unclear how to fix it, the documentation is not helpful on this. If not resolved soon, I'll just force Tx flow control off for now. just for the record, same problem here. I mean, with my Sony Vaio VGN-SZ1VP (here[1] you can find all hardware details), it's enough some mega of udp traffic, usually nfs, to freeze the network. Well, no complain from the kernel. It's enough to rmmod and modprobe sky2 to fix the problem. I already tried -mm1, but nothing changed. In the meanwhile I will continue to use my usb network card. Thanks a lot for your time, Andrea Gelmini --- [1] http://groups.google.it/group/linux.kernel/msg/ceff3014c410bea6 - 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] NetLabel: add audit support for configuration changes
On Thursday 28 September 2006 14:03, [EMAIL PROTECTED] wrote:
This patch adds audit support to NetLabel, including six new audit message
types shown below.
#define AUDIT_MAC_UNLBL_ACCEPT 1406
#define AUDIT_MAC_UNLBL_DENY 1407
#define AUDIT_MAC_CIPSOV4_ADD 1408
#define AUDIT_MAC_CIPSOV4_DEL 1409
#define AUDIT_MAC_MAP_ADD 1410
#define AUDIT_MAC_MAP_DEL 1411
Please consider this for inclusion into 2.6.19.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
include/linux/audit.h |6 ++
include/net/cipso_ipv4.h |5 +-
include/net/netlabel.h |2
net/ipv4/cipso_ipv4.c |8 ++-
net/netlabel/netlabel_cipso_v4.c | 43 +
net/netlabel/netlabel_domainhash.c | 54 +++--
net/netlabel/netlabel_domainhash.h |6 +-
net/netlabel/netlabel_mgmt.c | 14 +++--
net/netlabel/netlabel_unlabeled.c | 36 --
net/netlabel/netlabel_user.c | 91
+ net/netlabel/netlabel_user.h |
6 ++
11 files changed, 235 insertions(+), 36 deletions(-)
Index: net-2.6/include/linux/audit.h
===
--- net-2.6.orig/include/linux/audit.h
+++ net-2.6/include/linux/audit.h
@@ -95,6 +95,12 @@
#define AUDIT_MAC_POLICY_LOAD1403/* Policy file load */
#define AUDIT_MAC_STATUS 1404/* Changed enforcing,permissive,off */
#define AUDIT_MAC_CONFIG_CHANGE 1405/* Changes to booleans */
+#define AUDIT_MAC_UNLBL_ACCEPT 1406/* NetLabel: allow unlabeled
traffic */
+#define AUDIT_MAC_UNLBL_DENY 1407/* NetLabel: deny unlabeled traffic */
Please drop the use of DENY per comments later down.
+#define AUDIT_MAC_CIPSOV4_ADD1408/* NetLabel: add CIPSOv4 DOI
entry */
+#define AUDIT_MAC_CIPSOV4_DEL1409/* NetLabel: del CIPSOv4 DOI
entry */
+#define AUDIT_MAC_MAP_ADD1410/* NetLabel: add LSM domain mapping */
+#define AUDIT_MAC_MAP_DEL1411/* NetLabel: del LSM domain mapping */
#define AUDIT_FIRST_KERN_ANOM_MSG 1700
#define AUDIT_LAST_KERN_ANOM_MSG1799
Index: net-2.6/include/net/cipso_ipv4.h
===
--- net-2.6.orig/include/net/cipso_ipv4.h
+++ net-2.6/include/net/cipso_ipv4.h
@@ -128,7 +128,9 @@ extern int cipso_v4_rbm_strictvalid;
#ifdef CONFIG_NETLABEL
int cipso_v4_doi_add(struct cipso_v4_doi *doi_def);
-int cipso_v4_doi_remove(u32 doi, void (*callback) (struct rcu_head *
head)); +int cipso_v4_doi_remove(u32 doi,
+ u32 audit_secid,
+ void (*callback) (struct rcu_head * head));
struct cipso_v4_doi *cipso_v4_doi_getdef(u32 doi);
int cipso_v4_doi_walk(u32 *skip_cnt,
int (*callback) (struct cipso_v4_doi *doi_def, void *arg),
@@ -143,6 +145,7 @@ static inline int cipso_v4_doi_add(struc
}
static inline int cipso_v4_doi_remove(u32 doi,
+ u32 audit_secid,
void (*callback) (struct rcu_head * head))
{
return 0;
Index: net-2.6/include/net/netlabel.h
===
--- net-2.6.orig/include/net/netlabel.h
+++ net-2.6/include/net/netlabel.h
@@ -96,7 +96,7 @@
struct netlbl_dom_map;
/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain);
+int netlbl_domhsh_remove(const char *domain, u32 audit_secid);
/* LSM security attributes */
struct netlbl_lsm_cache {
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
@@ -474,6 +474,7 @@ doi_add_failure_rlock:
/**
* cipso_v4_doi_remove - Remove an existing DOI from the CIPSO protocol
engine * @doi: the DOI value
+ * @audit_secid: the LSM secid to use in the audit message
* @callback: the DOI cleanup/free callback
*
* Description:
@@ -483,7 +484,9 @@ doi_add_failure_rlock:
* success and negative values on failure.
*
*/
-int cipso_v4_doi_remove(u32 doi, void (*callback) (struct rcu_head *
head)) +int cipso_v4_doi_remove(u32 doi,
+ u32 audit_secid,
+ void (*callback) (struct rcu_head * head))
{
struct cipso_v4_doi *doi_def;
struct cipso_v4_domhsh_entry *dom_iter;
@@ -502,7 +505,8 @@ int cipso_v4_doi_remove(u32 doi, void (*
spin_unlock(cipso_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, doi_def-dom_list, list)
if (dom_iter-valid)
- netlbl_domhsh_remove(dom_iter-domain);
+ netlbl_domhsh_remove(dom_iter-domain,
+ audit_secid);
cipso_v4_cache_invalidate();
Re: [PATCH 1/1] NetLabel: add audit support for configuration changes
Dave,
Looks like this patch needs to be reverted until these issues are
resolved.
On Fri, 29 Sep 2006, Steve Grubb wrote:
On Thursday 28 September 2006 14:03, [EMAIL PROTECTED] wrote:
This patch adds audit support to NetLabel, including six new audit message
types shown below.
#define AUDIT_MAC_UNLBL_ACCEPT 1406
#define AUDIT_MAC_UNLBL_DENY 1407
#define AUDIT_MAC_CIPSOV4_ADD 1408
#define AUDIT_MAC_CIPSOV4_DEL 1409
#define AUDIT_MAC_MAP_ADD 1410
#define AUDIT_MAC_MAP_DEL 1411
Please consider this for inclusion into 2.6.19.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
include/linux/audit.h |6 ++
include/net/cipso_ipv4.h |5 +-
include/net/netlabel.h |2
net/ipv4/cipso_ipv4.c |8 ++-
net/netlabel/netlabel_cipso_v4.c | 43 +
net/netlabel/netlabel_domainhash.c | 54 +++--
net/netlabel/netlabel_domainhash.h |6 +-
net/netlabel/netlabel_mgmt.c | 14 +++--
net/netlabel/netlabel_unlabeled.c | 36 --
net/netlabel/netlabel_user.c | 91
+ net/netlabel/netlabel_user.h |
6 ++
11 files changed, 235 insertions(+), 36 deletions(-)
Index: net-2.6/include/linux/audit.h
===
--- net-2.6.orig/include/linux/audit.h
+++ net-2.6/include/linux/audit.h
@@ -95,6 +95,12 @@
#define AUDIT_MAC_POLICY_LOAD 1403/* Policy file load */
#define AUDIT_MAC_STATUS 1404/* Changed enforcing,permissive,off */
#define AUDIT_MAC_CONFIG_CHANGE1405/* Changes to booleans */
+#define AUDIT_MAC_UNLBL_ACCEPT 1406/* NetLabel: allow unlabeled
traffic */
+#define AUDIT_MAC_UNLBL_DENY 1407/* NetLabel: deny unlabeled
traffic */
Please drop the use of DENY per comments later down.
+#define AUDIT_MAC_CIPSOV4_ADD 1408/* NetLabel: add CIPSOv4 DOI
entry */
+#define AUDIT_MAC_CIPSOV4_DEL 1409/* NetLabel: del CIPSOv4 DOI
entry */
+#define AUDIT_MAC_MAP_ADD 1410/* NetLabel: add LSM domain mapping */
+#define AUDIT_MAC_MAP_DEL 1411/* NetLabel: del LSM domain mapping */
#define AUDIT_FIRST_KERN_ANOM_MSG 1700
#define AUDIT_LAST_KERN_ANOM_MSG1799
Index: net-2.6/include/net/cipso_ipv4.h
===
--- net-2.6.orig/include/net/cipso_ipv4.h
+++ net-2.6/include/net/cipso_ipv4.h
@@ -128,7 +128,9 @@ extern int cipso_v4_rbm_strictvalid;
#ifdef CONFIG_NETLABEL
int cipso_v4_doi_add(struct cipso_v4_doi *doi_def);
-int cipso_v4_doi_remove(u32 doi, void (*callback) (struct rcu_head *
head)); +int cipso_v4_doi_remove(u32 doi,
+ u32 audit_secid,
+ void (*callback) (struct rcu_head * head));
struct cipso_v4_doi *cipso_v4_doi_getdef(u32 doi);
int cipso_v4_doi_walk(u32 *skip_cnt,
int (*callback) (struct cipso_v4_doi *doi_def, void *arg),
@@ -143,6 +145,7 @@ static inline int cipso_v4_doi_add(struc
}
static inline int cipso_v4_doi_remove(u32 doi,
+ u32 audit_secid,
void (*callback) (struct rcu_head * head))
{
return 0;
Index: net-2.6/include/net/netlabel.h
===
--- net-2.6.orig/include/net/netlabel.h
+++ net-2.6/include/net/netlabel.h
@@ -96,7 +96,7 @@
struct netlbl_dom_map;
/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain);
+int netlbl_domhsh_remove(const char *domain, u32 audit_secid);
/* LSM security attributes */
struct netlbl_lsm_cache {
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
@@ -474,6 +474,7 @@ doi_add_failure_rlock:
/**
* cipso_v4_doi_remove - Remove an existing DOI from the CIPSO protocol
engine * @doi: the DOI value
+ * @audit_secid: the LSM secid to use in the audit message
* @callback: the DOI cleanup/free callback
*
* Description:
@@ -483,7 +484,9 @@ doi_add_failure_rlock:
* success and negative values on failure.
*
*/
-int cipso_v4_doi_remove(u32 doi, void (*callback) (struct rcu_head *
head)) +int cipso_v4_doi_remove(u32 doi,
+ u32 audit_secid,
+ void (*callback) (struct rcu_head * head))
{
struct cipso_v4_doi *doi_def;
struct cipso_v4_domhsh_entry *dom_iter;
@@ -502,7 +505,8 @@ int cipso_v4_doi_remove(u32 doi, void (*
spin_unlock(cipso_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, doi_def-dom_list, list)
if (dom_iter-valid)
-
Re: [PATCH 1/1] NetLabel: add audit support for configuration changes
James Morris wrote:
Dave,
Looks like this patch needs to be reverted until these issues are
resolved.
Yes, please revert this patch.
I posted an earlier version to the linux-audit list and waited for a day
to see if there any comments before submitting for inclusion, but
unfortunately it seems I didn't wait long enough for Steve. I'll deal
with Steve's comments once I handle the secid reconciliation patches as
I think they are more important right now.
On Fri, 29 Sep 2006, Steve Grubb wrote:
On Thursday 28 September 2006 14:03, [EMAIL PROTECTED] wrote:
This patch adds audit support to NetLabel, including six new audit message
types shown below.
#define AUDIT_MAC_UNLBL_ACCEPT 1406
#define AUDIT_MAC_UNLBL_DENY 1407
#define AUDIT_MAC_CIPSOV4_ADD 1408
#define AUDIT_MAC_CIPSOV4_DEL 1409
#define AUDIT_MAC_MAP_ADD 1410
#define AUDIT_MAC_MAP_DEL 1411
Please consider this for inclusion into 2.6.19.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
include/linux/audit.h |6 ++
include/net/cipso_ipv4.h |5 +-
include/net/netlabel.h |2
net/ipv4/cipso_ipv4.c |8 ++-
net/netlabel/netlabel_cipso_v4.c | 43 +
net/netlabel/netlabel_domainhash.c | 54 +++--
net/netlabel/netlabel_domainhash.h |6 +-
net/netlabel/netlabel_mgmt.c | 14 +++--
net/netlabel/netlabel_unlabeled.c | 36 --
net/netlabel/netlabel_user.c | 91
+ net/netlabel/netlabel_user.h |
6 ++
11 files changed, 235 insertions(+), 36 deletions(-)
Index: net-2.6/include/linux/audit.h
===
--- net-2.6.orig/include/linux/audit.h
+++ net-2.6/include/linux/audit.h
@@ -95,6 +95,12 @@
#define AUDIT_MAC_POLICY_LOAD 1403/* Policy file load */
#define AUDIT_MAC_STATUS1404/* Changed enforcing,permissive,off */
#define AUDIT_MAC_CONFIG_CHANGE 1405/* Changes to booleans */
+#define AUDIT_MAC_UNLBL_ACCEPT 1406/* NetLabel: allow unlabeled
traffic */
+#define AUDIT_MAC_UNLBL_DENY1407/* NetLabel: deny unlabeled
traffic */
Please drop the use of DENY per comments later down.
+#define AUDIT_MAC_CIPSOV4_ADD 1408/* NetLabel: add CIPSOv4 DOI
entry */
+#define AUDIT_MAC_CIPSOV4_DEL 1409/* NetLabel: del CIPSOv4 DOI
entry */
+#define AUDIT_MAC_MAP_ADD 1410/* NetLabel: add LSM domain mapping */
+#define AUDIT_MAC_MAP_DEL 1411/* NetLabel: del LSM domain mapping */
#define AUDIT_FIRST_KERN_ANOM_MSG 1700
#define AUDIT_LAST_KERN_ANOM_MSG1799
Index: net-2.6/include/net/cipso_ipv4.h
===
--- net-2.6.orig/include/net/cipso_ipv4.h
+++ net-2.6/include/net/cipso_ipv4.h
@@ -128,7 +128,9 @@ extern int cipso_v4_rbm_strictvalid;
#ifdef CONFIG_NETLABEL
int cipso_v4_doi_add(struct cipso_v4_doi *doi_def);
-int cipso_v4_doi_remove(u32 doi, void (*callback) (struct rcu_head *
head)); +int cipso_v4_doi_remove(u32 doi,
+u32 audit_secid,
+void (*callback) (struct rcu_head * head));
struct cipso_v4_doi *cipso_v4_doi_getdef(u32 doi);
int cipso_v4_doi_walk(u32 *skip_cnt,
int (*callback) (struct cipso_v4_doi *doi_def, void *arg),
@@ -143,6 +145,7 @@ static inline int cipso_v4_doi_add(struc
}
static inline int cipso_v4_doi_remove(u32 doi,
+u32 audit_secid,
void (*callback) (struct rcu_head * head))
{
return 0;
Index: net-2.6/include/net/netlabel.h
===
--- net-2.6.orig/include/net/netlabel.h
+++ net-2.6/include/net/netlabel.h
@@ -96,7 +96,7 @@
struct netlbl_dom_map;
/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain);
+int netlbl_domhsh_remove(const char *domain, u32 audit_secid);
/* LSM security attributes */
struct netlbl_lsm_cache {
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
@@ -474,6 +474,7 @@ doi_add_failure_rlock:
/**
* cipso_v4_doi_remove - Remove an existing DOI from the CIPSO protocol
engine * @doi: the DOI value
+ * @audit_secid: the LSM secid to use in the audit message
* @callback: the DOI cleanup/free callback
*
* Description:
@@ -483,7 +484,9 @@ doi_add_failure_rlock:
* success and negative values on failure.
*
*/
-int cipso_v4_doi_remove(u32 doi, void (*callback) (struct rcu_head *
head)) +int cipso_v4_doi_remove(u32 doi,
+u32 audit_secid,
+void (*callback) (struct rcu_head * head))
{
struct cipso_v4_doi *doi_def;
struct cipso_v4_domhsh_entry *dom_iter;
@@ -502,7 +505,8 @@ int cipso_v4_doi_remove(u32 doi, void (*
Re: Network problem with 2.6.18-mm1 ?
On 9/28/06, Sukadev Bhattiprolu [EMAIL PROTECTED] wrote: $ cat /proc/interrupts CPU0 CPU1 28: 0 0 IO-APIC-fasteoi eth0 NMI: 96 35 LOC: 18251 18524 ERR: 0 you should be getting an interrupt every two seconds from the eth0 (e1000) driver. You are having interrupt delivery problems probably due to something screwing up interrupt routing in the kernel. Normally these issues are associated with MSI interrupts but your adapter doesn't support those and is using generic IRQ I'm guessing that if you somehow enable interrupts on your vga card on the same bus as e1000 (bus 3) it will have interrupt delivery problems as well. Maybe try xorg? Jesse - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 29 Sep 2006, Paul Moore wrote: James Morris wrote: Ok, can you please explain it further? i.e. show me what the policy looks like, exactly what the user is trying to achieve, and explain what happens to each packet exactly in terms of labeling on the input and output paths. All right, here is my take on it, perhaps Venkat can chime in too. Thanks, that cleared up many things, but how does this interact with CONNSECMARK? Please provide some example iptables rules, SELinux policy statements, racoon config and netlabel config. I need to understand exactly what happens to each packet in, say, an FTP session and how you envisage the configuration. Here's a sample scenario for the above (let me know if this is not how you expect this to be used): Say that the SA is labeled secret and you have two FTP clients connecting to a server via xinetd on this SA. Each client additionally labels their packets via CIPSO as secret:c1 and secret:c2 respectively. xinetd launches an FTP server for each at the correct level. - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
While I don't see any explicit mention of it in the documentation or your comments, I assume we would want a flow_out check for NetLabel here as well? I don't believe we do. By this time, the packet is or should already be carrying the CIPSO/NetLabel option which should already be the right one (derived from the socket or flow as appropriate), but you would want to audit the code to make sure. IOW, the label option in the IP header should already be reflecting the secmark on the skb. But again, you may want to audit the code to make sure. In the case above I am concerned about the situation where the skb-secmark == 0 and there is a IPv4 option (i.e. it is NetLabel labeled) on the packet. Where we initialize the secmark should be immaterial from the NetLabel point of view. The kernel mechanisms should assure that the IP option reflects the MLS portion (or a label in the SA range) elsewhere. In any case, a flow_out check doesn't make sense since the IP option and the secmark are (should be) mirroring each other and there's in actuality no flow out happening; they are just 2 representation of the SAME label. Your suggestion as to adjusting the secmark per the IP option might be fraught with danger since, in certain cases, I believe, you just return the incoming options in the outgoing packet (timewait, openreq, etc.?), and there's no assurance that that's a valid enough option that you can retrieve a sid with it, correct? - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
James Morris wrote: On Fri, 29 Sep 2006, Paul Moore wrote: James Morris wrote: Ok, can you please explain it further? i.e. show me what the policy looks like, exactly what the user is trying to achieve, and explain what happens to each packet exactly in terms of labeling on the input and output paths. All right, here is my take on it, perhaps Venkat can chime in too. Thanks, that cleared up many things, but how does this interact with CONNSECMARK? Please provide some example iptables rules, SELinux policy statements, racoon config and netlabel config. I need to understand exactly what happens to each packet in, say, an FTP session and how you envisage the configuration. Hopefully Venkat can talk to the iptables rule, policy statements, and racoon config. He has the best understanding of how this works with the secid patches. There really is no specific NetLabel config as the NetLabel config only specifies how to create the explicit packet label (CIPSO IPv4 option) using the socket's SID. NetLabel, like SECMARK, is just a packet labeling mechanism. I think the key thing to remember is that the only change brought about by the pseudo-code I posted earlier is that the secmark's MLS label would be adjusted to match the value of the NetLabel (CIPSO option) assuming it passes the avc flow_in checks. Here's a sample scenario for the above (let me know if this is not how you expect this to be used): Say that the SA is labeled secret and you have two FTP clients connecting to a server via xinetd on this SA. Each client additionally labels their packets via CIPSO as secret:c1 and secret:c2 respectively. xinetd launches an FTP server for each at the correct level. I believe Venkat can address this. -- 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 7/7] secid reconciliation-v03: Enforcement for SELinux
Venkat Yekkirala wrote: While I don't see any explicit mention of it in the documentation or your comments, I assume we would want a flow_out check for NetLabel here as well? I don't believe we do. By this time, the packet is or should already be carrying the CIPSO/NetLabel option which should already be the right one (derived from the socket or flow as appropriate), but you would want to audit the code to make sure. IOW, the label option in the IP header should already be reflecting the secmark on the skb. But again, you may want to audit the code to make sure. In the case above I am concerned about the situation where the skb-secmark == 0 and there is a IPv4 option (i.e. it is NetLabel labeled) on the packet. It's unfortunate that you cut out the code in your reply. Where we initialize the secmark should be immaterial from the NetLabel point of view. The kernel mechanisms should assure that the IP option reflects the MLS portion (or a label in the SA range) elsewhere. Yep, I agree. In any case, a flow_out check doesn't make sense since the IP option and the secmark are (should be) mirroring each other and there's in actuality no flow out happening; they are just 2 representation of the SAME label. Well, reading the code I see that if the secmark is zero upon entering the function you query the XFRM subsystem to query the SA label and set the secmark accordingly, yes? All I am suggesting is that we do the same thing for NetLabel. Please see the mail I sent earlier with the code in it to address James' concerns, this has a proposed solution for the flow_out case. Your suggestion as to adjusting the secmark per the IP option might be fraught with danger since, in certain cases, I believe, you just return the incoming options in the outgoing packet (timewait, openreq, etc.?), and there's no assurance that that's a valid enough option that you can retrieve a sid with it, correct? As implemented in the code snippets I sent earlier the generated NetLabel SID would reflect the secmark as determined by the IPsec label and the IP options on the packet. I believe this is what we want as the resulting secmark value would directly represent the security attributes of the packet. -- 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] tcp-lp: prevent chance for oops
I do this since i have a sourceforge homepage for it. I update the CVS version there, test, and then submit to netdev. As I sync code in both side, this $Id$ is keeped. May you just let it be? I think it will let my maintenance become more simple... On 9/29/06, David Miller [EMAIL PROTECTED] wrote: From: Wong Edison [EMAIL PROTECTED] Date: Thu, 28 Sep 2006 18:43:58 +0800 * - * Version: $Id: tcp_lp.c,v 1.24 2006/09/05 20:22:53 hswong3i Exp $ + * Version: $Id: tcp_lp.c,v 1.25 2006/09/22 20:50:27 hswong3i Exp $ BTW, I'm deleting this line from the source file in the tree because every patch you send doesn't apply cleanly because your patch is against a different string on this line and we don't use $Id$ tags in the kernel sources anyways. - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 29 Sep 2006, Paul Moore wrote: Say that the SA is labeled secret and you have two FTP clients connecting to a server via xinetd on this SA. Each client additionally labels their packets via CIPSO as secret:c1 and secret:c2 respectively. xinetd launches an FTP server for each at the correct level. I believe Venkat can address this. Ok, I'd still really like to see a worked example of just Netlabel + secmark/connseckmark, to see what happens to the connection marks. It seems that the connection mark should always be correct, and restored to the packet. In which case, what happens when a CIPSO label on an established or related packet doesn't match, or you get no CIPSO label (e.g. ICMP from intermediate router) ? Or, is would you be always overwriting secmark/connsecmark labeling, and if so, how/why are you using them? Venkat, With xfrm labeling, the external packets are always going to be protocol ESP or AH, and we can't connection track the inner protocols. So, external labeling when using xfrm labeling seems somewhat superfluous, except for the case of setting a label based on the interface the packets arrived on. Correct? If so, all you can realistically do with the flow permissions is bind the ESP/AH packets to types of interfaces (which does seem useful for some folk). -- 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 7/7] secid reconciliation-v03: Enforcement for SELinux
James Morris wrote:
On Fri, 29 Sep 2006, Paul Moore wrote:
Say that the SA is labeled secret and you have two FTP clients
connecting to a server via xinetd on this SA. Each client additionally
labels their packets via CIPSO as secret:c1 and secret:c2 respectively.
xinetd launches an FTP server for each at the correct level.
I believe Venkat can address this.
Ok, I'd still really like to see a worked example of just Netlabel +
secmark/connseckmark, to see what happens to the connection marks.
Fair enough.
It
seems that the connection mark should always be correct, and restored to
the packet. In which case, what happens when a CIPSO label on an
established {connection} ...
The following would happen, in order, in selinux_skb_flow_in() (I'm
ommitting the IPsec relevant portions of this function for clarity):
1. A NetLabel SID would be generated using the secmark as the
base_sid; this means that the NetLabel would be the concatenation of
the secmark's TE context and the NetLabel's MLS label. The secmark is
not yet modified.
2. The NetLabel SID would be avc checked against the secmark:
avc_has_perm(nlbl_sid,
skb-secmark,
SECCLASS_PACKET,
PACKET__FLOW_IN,
NULL)
Note that in practice this is basically just a MLS label check.
3. If the NetLabel SID != 0 the secmark would be replaced with the
NetLabel SID.
I am trying to make NetLabel behave in a similar fashion as to how
labeled IPsec works in the secid patches; I believe the above steps
acomplish this. If not please let me know and I'll make the necessary
changes.
... or related packet doesn't match ...
Not sure what you mean by related packet, but if the check in step #2
fails then the packet would be dropped. The only case where I can see
this happening is that if the MLS/MCS constraints did not allow the
flow_in permission. This allows administrators to set specific MLS
labels for any iptables object.
... or you get no CIPSO label (e.g. ICMP from intermediate router) ...
If there is no packet label that NetLabel recognizes and NetLabel is
configured to allow unlabeled traffic then the NetLabel SID generated in
step #1 above would be 0.
Or, is would you be always
overwriting secmark/connsecmark labeling, and if so, how/why are you using
them?
I think I addressed that above.
FYI: in between emails I'm working on a patch against Venkat's secid
patches which implements this, hopefully Venkat can roll this patch into
his secid patchset so this is all committed/rejected at once.
--
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 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 29 Sep 2006, Paul Moore wrote: ... or related packet doesn't match ... Not sure what you mean by related packet, A related packet with conntrack would be an FTP data packet related to a specific FTP control session (where the conntrack is initialized, and has a secmark saved to it). but if the check in step #2 fails then the packet would be dropped. Ok. The only case where I can see this happening is that if the MLS/MCS constraints did not allow the flow_in permission. This allows administrators to set specific MLS labels for any iptables object. Yep, one thing to watch for here is packets arriving on a different interface for valid reasons (e.g. routing changes), but that's a policy issue. ... or you get no CIPSO label (e.g. ICMP from intermediate router) ... If there is no packet label that NetLabel recognizes and NetLabel is configured to allow unlabeled traffic then the NetLabel SID generated in step #1 above would be 0. Well, conntrack will say that this packet is related to the connection and CONNSECMARK will restore the secmark label to it (i.e. it'll have the same secmark as the initial syn packet). But, no CIPSO label. I guess this needs to be considered in any case, secmark or not. - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
James Morris wrote: On Fri, 29 Sep 2006, Paul Moore wrote: ... or you get no CIPSO label (e.g. ICMP from intermediate router) ... If there is no packet label that NetLabel recognizes and NetLabel is configured to allow unlabeled traffic then the NetLabel SID generated in step #1 above would be 0. Well, conntrack will say that this packet is related to the connection and CONNSECMARK will restore the secmark label to it (i.e. it'll have the same secmark as the initial syn packet). But, no CIPSO label. I guess this needs to be considered in any case, secmark or not. Yep, I would categorize this case as 'external label not present, internal label present'. I believe the code as described would do the right thing in allowing admins to control this, it's just up to how you configure the system and what your policy dictates. -- 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 4/4] [SCTP]: Do not timestamp every SCTP packet.
[SCTP]: Do not timestamp every SCTP packet.
We only need the timestamp on COOKIE-ECHO chunks, so instead of always
timestamping every SCTP packet, let common code timestamp if the socket
option is set. For COOKIE-ECHO, simply get the time of day if we don't
have a timestamp. This introduces a small possibility that the cookie
may be considered expired, but it will be renegotiated.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED]
---
net/sctp/input.c |6 --
net/sctp/sm_make_chunk.c | 10 +-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 4714882..64f6301 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -218,12 +218,6 @@ int sctp_rcv(struct sk_buff *skb)
}
}
- /* SCTP seems to always need a timestamp right now (FIXME) */
- if (skb-tstamp.off_sec == 0) {
- __net_timestamp(skb);
- sock_enable_timestamp(sk);
- }
-
if (!xfrm_policy_check(sk, XFRM_POLICY_IN, skb, family))
goto discard_release;
nf_reset(skb);
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 7745bde..507dff7 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1447,8 +1447,16 @@ no_hmac:
/* Check to see if the cookie is stale. If there is already
* an association, there is no need to check cookie's expiration
* for init collision case of lost COOKIE ACK.
+* If skb has been timestamped, then use the stamp, otherwise
+* use current time. This introduces a small possibility that
+* that a cookie may be considered expired, but his would only slow
+* down the new association establishment instead of every packet.
*/
- skb_get_timestamp(skb, tv);
+ if (sock_flag(ep-base.sk, SOCK_TIMESTAMP))
+ skb_get_timestamp(skb, tv);
+ else
+ do_gettimeofday(tv);
+
if (!asoc tv_lt(bear_cookie-expiration, tv)) {
__u16 len;
/*
-
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 3/4] [SCTP]: Use correct mask when disabling PMTUD.
[SCTP]: Use correct mask when disabling PMTUD.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED]
---
net/sctp/input.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 03f65de..4714882 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -388,7 +388,7 @@ void sctp_icmp_frag_needed(struct sock *
* pmtu discovery on this transport.
*/
t-pathmtu = SCTP_DEFAULT_MINSEGMENT;
- t-param_flags = (t-param_flags ~SPP_HB) |
+ t-param_flags = (t-param_flags ~SPP_PMTUD) |
SPP_PMTUD_DISABLE;
} else {
t-pathmtu = pmtu;
-
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/4] [SCTP]: Include sk_buff overhead while updating the peer's receive window.
[SCTP]: Include sk_buff overhead while updating the peer's receive window.
Currently if the sender is sending small messages, it can cause a receiver
to run out of receive buffer space even when the advertised receive window
is still open and results in packet drops and retransmissions. Including
a overhead while updating the sender's view of peer receive window will
reduce the chances of receive buffer space overshooting the receive window.
Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED]
---
net/sctp/output.c | 10 --
net/sctp/outqueue.c |3 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/sctp/output.c b/net/sctp/output.c
index cdc5a39..9825b11 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -633,7 +633,7 @@ static sctp_xmit_t sctp_packet_append_da
* data will fit or delay in hopes of bundling a full
* sized packet.
*/
- if (len asoc-pathmtu - packet-overhead) {
+ if (len asoc-frag_point) {
retval = SCTP_XMIT_NAGLE_DELAY;
goto finish;
}
@@ -645,7 +645,13 @@ static sctp_xmit_t sctp_packet_append_da
/* Keep track of how many bytes are in flight to the receiver. */
asoc-outqueue.outstanding_bytes += datasize;
- /* Update our view of the receiver's rwnd. */
+ /* Update our view of the receiver's rwnd. Include sk_buff overhead
+* while updating peer.rwnd so that it reduces the chances of a
+* receiver running out of receive buffer space even when receive
+* window is still open. This can happen when a sender is sending
+* sending small messages.
+*/
+ datasize += sizeof(struct sk_buff);
if (datasize rwnd)
rwnd -= datasize;
else
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 37074a3..7395824 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -416,7 +416,8 @@ void sctp_retransmit_mark(struct sctp_ou
* (Section 7.2.4)), add the data size of those
* chunks to the rwnd.
*/
- q-asoc-peer.rwnd += sctp_data_size(chunk);
+ q-asoc-peer.rwnd += (sctp_data_size(chunk) +
+ sizeof(struct sk_buff));
q-outstanding_bytes -= sctp_data_size(chunk);
transport-flight_size -= sctp_data_size(chunk);
-
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/4] [SCTP]: Enable Nagle algorithm by default.
Dave, Please consider the following 4 SCTP patches for 2.6.19. Thanks Sridhar [SCTP]: Enable Nagle algorithm by default. This allows more aggressive bundling of chunks when sending small messages. Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] --- net/sctp/socket.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/sctp/socket.c b/net/sctp/socket.c index 79c3e07..3fe906d 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -3084,8 +3084,8 @@ SCTP_STATIC int sctp_init_sock(struct so */ sp-disable_fragments = 0; - /* Turn on/off any Nagle-like algorithm. */ - sp-nodelay = 1; + /* Enable Nagle algorithm by default. */ + sp-nodelay = 0; /* Enable by default. */ sp-v4mapped = 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
[PATCH 1/1] 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| 51
security/selinux/include/objsec.h |1
security/selinux/include/selinux_netlabel.h | 16 +++-
security/selinux/ss/mls.c |2 -
security/selinux/ss/services.c | 42 ---
5 files changed, 82 insertions(+), 30 deletions(-)
Index: net-2.6/security/selinux/hooks.c
===
--- net-2.6.orig/security/selinux/hooks.c
+++ net-2.6/security/selinux/hooks.c
@@ -3440,6 +3440,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:
@@ -3476,10 +3480,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;
}
@@ -3654,13 +3655,14 @@ static void selinux_req_classify_flow(co
static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
{
- u32 xfrm_sid, trans_sid;
+ u32 xfrm_sid;
+ u32 nlbl_sid;
int err;
if (selinux_compat_net)
return 1;
- /* xfrm/cipso inapplicable for loopback traffic */
+ /* allow all loopback traffic */
if (skb-dev == loopback_dev)
return 1;
@@ -3672,16 +3674,20 @@ static int selinux_skb_flow_in(struct sk
if (err)
goto out;
- if (xfrm_sid) {
- err = security_transition_sid(xfrm_sid, skb-secmark,
- SECCLASS_PACKET, trans_sid);
- if (err)
- goto out;
+ if (xfrm_sid)
+ skb-secmark = xfrm_sid;
- skb-secmark = trans_sid;
- }
+ err = selinux_netlbl_skb_sid(skb, skb-secmark, nlbl_sid);
+ if (err)
+ goto out;
- /* See if CIPSO can flow in thru the current secmark here */
+ err = avc_has_perm(nlbl_sid, skb-secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (nlbl_sid)
+ skb-secmark = nlbl_sid;
out:
return err ? 0 : 1;
@@ -3689,7 +3695,6 @@ out:
static int selinux_skb_flow_out(struct sk_buff *skb, u32 nf_secid)
{
- u32 trans_sid;
int err;
if (selinux_compat_net)
@@ -3697,6 +3702,7 @@ static int selinux_skb_flow_out(struct s
if (!skb-secmark) {
u32 xfrm_sid;
+ u32 nlbl_sid;
selinux_skb_xfrm_sid(skb, xfrm_sid);
@@ -3706,6 +3712,13 @@ static int selinux_skb_flow_out(struct s
struct sk_security_struct *sksec = skb-sk-sk_security;
skb-secmark = sksec-sid;
}
+
+ err = selinux_netlbl_skb_sid(skb, skb-secmark, nlbl_sid);
+ if (err)
+ goto out;
+
+ if (nlbl_sid)
+ skb-secmark = nlbl_sid;
}
err = avc_has_perm(skb-secmark, nf_secid, SECCLASS_PACKET,
@@ -3861,6 +3874,7 @@ static unsigned int selinux_ip_postroute
else {
if (!skb-secmark) {
u32 xfrm_sid;
+ u32 nlbl_sid;
selinux_skb_xfrm_sid(skb, xfrm_sid);
@@ -3871,6 +3885,15 @@ static unsigned int selinux_ip_postroute
skb-sk-sk_security;
skb-secmark = sksec-sid;
}
+
+ err = selinux_netlbl_skb_sid(skb,
+skb-secmark,
+nlbl_sid);
+ if (err)
+ goto out;
+
+ if (nlbl_sid)
+ skb-secmark = nlbl_sid;
}
err = avc_has_perm(skb-secmark, SECINITSID_UNLABELED,
SECCLASS_PACKET, PACKET__FLOW_OUT, ad);
Index: net-2.6/security/selinux/include/objsec.h
===
--- net-2.6.orig/security/selinux/include/objsec.h
+++ net-2.6/security/selinux/include/objsec.h
@@ -102,7 +102,6 @@ struct sk_security_struct {
u32 sid;/* SID of this object */
u32 peer_sid; /* SID of peer */
#ifdef
[PATCH 0/1] NetLabel: patch against Venkat's secid patchset
The following patch is against this morning's net-2.6 tree with Venkat's secid patches applied. You may notice some differences as I had to fuzz/fix-up Venkat's patches in a few places. This patch provides the missing NetLabel support for the secid reconciliation patches based on the discussions we have been having on the mailing lists. Ideally I would hope Venkat could merge this patch in with his patchset so that the secid patchset will include NetLabel support. However, if that is not possibile I'll respin this patch later once the secid patches have been committed. Venkat, please merge this patch into your next version of the secid patches. -- 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] NetLabel: add audit support for configuration changes
Steve Grubb wrote:
On Thursday 28 September 2006 14:03, [EMAIL PROTECTED] wrote:
@@ -381,21 +380,35 @@ static int netlbl_cipsov4_add(struct sk_
{
int ret_val = -EINVAL;
- u32 map_type;
+ u32 type;
+ u32 doi;
+ const char *type_str = (unknown);
+ struct audit_buffer *audit_buf;
- if (!info-attrs[NLBL_CIPSOV4_A_MTYPE])
+ if (!info-attrs[NLBL_CIPSOV4_A_DOI] ||
+ !info-attrs[NLBL_CIPSOV4_A_MTYPE])
return -EINVAL;
- map_type = nla_get_u32(info-attrs[NLBL_CIPSOV4_A_MTYPE]);
- switch (map_type) {
+ type = nla_get_u32(info-attrs[NLBL_CIPSOV4_A_MTYPE]);
+ switch (type) {
case CIPSO_V4_MAP_STD:
+ type_str = std;
ret_val = netlbl_cipsov4_add_std(info);
break;
case CIPSO_V4_MAP_PASS:
+ type_str = pass;
ret_val = netlbl_cipsov4_add_pass(info);
break;
}
+ if (ret_val == 0) {
+ doi = nla_get_u32(info-attrs[NLBL_CIPSOV4_A_DOI]);
+ audit_buf = netlbl_audit_start_common(AUDIT_MAC_CIPSOV4_ADD,
+ NETLINK_CB(skb).sid);
+ audit_log_format(audit_buf, doi=%u type=%s, doi, type_str);
type field is already taken for another purpose, it needs to be renamed.
If we can't have duplicate field names I would propose prefixing both
these fields (and doing similar things with the other NetLabel specific
fields) with a cipso_ making them cipso_doi and cipso_type.
If this isn't acceptable please suggest names which you feel are
appropriate.
+/**
+ * netlbl_unlabel_acceptflg_set - Set the unlabeled accept flag
+ * @value: desired value
+ * @audit_secid: the LSM secid to use in the audit message
+ *
+ * Description:
+ * Set the value of the unlabeled accept flag to @value.
+ *
+ */
+static void netlbl_unlabel_acceptflg_set(u8 value, u32 audit_secid)
+{
+ atomic_set(netlabel_unlabel_accept_flg, value);
+ netlbl_audit_nomsg((value ?
+ AUDIT_MAC_UNLBL_ACCEPT : AUDIT_MAC_UNLBL_DENY),
+audit_secid);
Looking at how this is being used, I think only 1 message type should be
used.
There are places in the audit system where we set a flag to 1 or 0, but only
have 1 message type. We record the old and new value. So, you'd need to pass
that to the logger.
With that in mind I would probably change the message type to
AUDIT_MAC_UNLBL_ALLOW and use a unlbl_accept field; is that okay? If
not please suggest something you would find acceptable.
+/**
+ * netlbl_audit_start_common - Start an audit message
+ * @type: audit message type
+ * @secid: LSM context ID
+ *
+ * Description:
+ * Start an audit message using the type specified in @type and fill the
audit + * message with some fields common to all NetLabel audit messages.
Returns + * a pointer to the audit buffer on success, NULL on failure.
+ *
+ */
+struct audit_buffer *netlbl_audit_start_common(int type, u32 secid)
+{
Generally, logging functions are moved into auditsc.c where the context and
other functions are defined.
How about leaving this for a future revision? I'd like this first
attempt to be relatively self contained. James Morris has made other
comments along the same lines.
+ audit_log_format(audit_buf,
+ netlabel: auid=%u uid=%u tty=%s pid=%d,
+ audit_loginuid,
+ current-uid,
+ audit_tty,
+ current-pid);
Why are you logging all this? When we add audit rules, all that we log is the
auid, and subj. If we need to log all this, we should probably have a helper
function that gets called by other config change loggers.
If I drop the uid, tty, and pid fields will this be acceptable?
+ audit_log_format(audit_buf, comm=);
+ audit_log_untrustedstring(audit_buf, audit_comm);
+ if (current-mm) {
+ down_read(current-mm-mmap_sem);
+ vma = current-mm-mmap;
+ while (vma) {
+ if ((vma-vm_flags VM_EXECUTABLE)
+ vma-vm_file) {
+ audit_log_d_path(audit_buf,
+ exe=,
+ vma-vm_file-f_dentry,
+ vma-vm_file-f_vfsmnt);
+ break;
+ }
+ vma = vma-vm_next;
+ }
+ up_read(current-mm-mmap_sem);
+ }
+
If this function was moved inside auditsc.c you could use a function there
that does this. But the question remains why all this data?
In the ideal world would you prefer this to be removed?
--
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] NetLabel: add audit support for configuration changes
Dave,
I think Steve and I have agreed on a solution, I'll put together a patch
right now based on what is currently in net-2.6 (i.e. the existing
NetLabel audit patch) and submit it to the lists in a few hours.
Steve Grubb wrote:
On Friday 29 September 2006 14:09, Paul Moore wrote:
type field is already taken for another purpose, it needs to be renamed.
If we can't have duplicate field names I would propose prefixing both
these fields (and doing similar things with the other NetLabel specific
fields) with a cipso_ making them cipso_doi and cipso_type.
That would be fine. This limits future field name collisions.
+/**
+ * netlbl_unlabel_acceptflg_set - Set the unlabeled accept flag
+ * @value: desired value
+ * @audit_secid: the LSM secid to use in the audit message
+ *
+ * Description:
+ * Set the value of the unlabeled accept flag to @value.
+ *
+ */
+static void netlbl_unlabel_acceptflg_set(u8 value, u32 audit_secid)
+{
+ atomic_set(netlabel_unlabel_accept_flg, value);
+ netlbl_audit_nomsg((value ?
+ AUDIT_MAC_UNLBL_ACCEPT : AUDIT_MAC_UNLBL_DENY),
+audit_secid);
Looking at how this is being used, I think only 1 message type should be
used. There are places in the audit system where we set a flag to 1 or 0,
but only have 1 message type. We record the old and new value. So, you'd
need to pass that to the logger.
With that in mind I would probably change the message type to
AUDIT_MAC_UNLBL_ALLOW and use a unlbl_accept field; is that okay?
That would be fine. Just a quick note...we have generally been old to
indicate the previous value. Example, backlog=512 old=256.
+/**
+ * netlbl_audit_start_common - Start an audit message
+ * @type: audit message type
+ * @secid: LSM context ID
+ *
+ * Description:
+ * Start an audit message using the type specified in @type and fill the
audit + * message with some fields common to all NetLabel audit messages.
Returns + * a pointer to the audit buffer on success, NULL on failure.
+ *
+ */
+struct audit_buffer *netlbl_audit_start_common(int type, u32 secid)
+{
Generally, logging functions are moved into auditsc.c where the context
and other functions are defined.
How about leaving this for a future revision?
Come to think of it, you don't need to move it. The reason to move it is to
access the context and use helper functions related to it. But I found that
you were using current which may not always be the sender. So if you cannot
use current, most of the stuff you are logging can't be, so the event being
logged becomes simpler and you don't need to move it.
I have not traced through all the code, but if you do any security checks
before taking the rules, be careful not to use current.
+ audit_log_format(audit_buf,
+ netlabel: auid=%u uid=%u tty=%s pid=%d,
+ audit_loginuid,
+ current-uid,
+ audit_tty,
+ current-pid);
Why are you logging all this? When we add audit rules, all that we log is
the auid, and subj. If we need to log all this, we should probably have a
helper function that gets called by other config change loggers.
If I drop the uid, tty, and pid fields will this be acceptable?
and comm exe, yes. Anything you were basing off of current has to go. The
audit rule logging was reduced to the credentials that are carried along in
the netlink packet since that's all you can trust. The sending process could
be gone by the time you get to this point in the code.
+ audit_log_format(audit_buf, comm=);
+ audit_log_untrustedstring(audit_buf, audit_comm);
+ if (current-mm) {
+ down_read(current-mm-mmap_sem);
+ vma = current-mm-mmap;
+ while (vma) {
+ if ((vma-vm_flags VM_EXECUTABLE)
+ vma-vm_file) {
+ audit_log_d_path(audit_buf,
+ exe=,
+ vma-vm_file-f_dentry,
+ vma-vm_file-f_vfsmnt);
+ break;
+ }
+ vma = vma-vm_next;
+ }
+ up_read(current-mm-mmap_sem);
+ }
+
If this function was moved inside auditsc.c you could use a function
there that does this. But the question remains why all this data?
In the ideal world would you prefer this to be removed?
Yes.
-Steve
--
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][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
[BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present.
MSI is defined to be 32-bit write. The 5706 does 64-bit MSI writes
with byte enables disabled on the unused 32-bit word. This is legal
but causes problems on the AMD 8132 which will eventually stop
responding after a while.
Without this patch, the MSI test done by the driver during open will
pass, but MSI will eventually stop working after a few MSIs are
written by the device.
AMD believes this incompatibility is unique to the 5706, and
prefers to locally disable MSI rather than globally disabling it
using pci_msi_quirk.
Update version to 1.4.45.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 7fcf015..a65a697 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -56,8 +56,8 @@
#define DRV_MODULE_NAMEbnx2
#define PFX DRV_MODULE_NAME:
-#define DRV_MODULE_VERSION 1.4.44
-#define DRV_MODULE_RELDATE August 10, 2006
+#define DRV_MODULE_VERSION 1.4.45
+#define DRV_MODULE_RELDATE September 29, 2006
#define RUN_AT(x) (jiffies + (x))
@@ -5805,6 +5805,34 @@ bnx2_init_board(struct pci_dev *pdev, st
bp-cmd_ticks_int = bp-cmd_ticks;
}
+ /* Disable MSI on 5706 if AMD 8132 bridge is found.
+*
+* MSI is defined to be 32-bit write. The 5706 does 64-bit MSI writes
+* with byte enables disabled on the unused 32-bit word. This is legal
+* but causes problems on the AMD 8132 which will eventually stop
+* responding after a while.
+*
+* AMD believes this incompatibility is unique to the 5706, and
+* prefers to locally disable MSI rather than globally disabling it
+* using pci_msi_quirk.
+*/
+ if (CHIP_NUM(bp) == CHIP_NUM_5706 disable_msi == 0) {
+ struct pci_dev *amd_8132 = NULL;
+
+ while ((amd_8132 = pci_get_device(PCI_VENDOR_ID_AMD,
+ PCI_DEVICE_ID_AMD_8132_BRIDGE,
+ amd_8132))) {
+ u8 rev;
+
+ pci_read_config_byte(amd_8132, PCI_REVISION_ID, rev);
+ if (rev = 0x10 rev = 0x13) {
+ disable_msi = 1;
+ pci_dev_put(amd_8132);
+ break;
+ }
+ }
+ }
+
bp-autoneg = AUTONEG_SPEED | AUTONEG_FLOW_CTRL;
bp-req_line_speed = 0;
if (bp-phy_flags PHY_SERDES_FLAG) {
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 2cead40..59e52cb 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -506,6 +506,7 @@
#define PCI_DEVICE_ID_AMD_8151_0 0x7454
#define PCI_DEVICE_ID_AMD_8131_BRIDGE 0x7450
#define PCI_DEVICE_ID_AMD_8131_APIC0x7451
+#define PCI_DEVICE_ID_AMD_8132_BRIDGE 0x7458
#define PCI_DEVICE_ID_AMD_CS5536_ISA0x2090
#define PCI_DEVICE_ID_AMD_CS5536_FLASH 0x2091
#define PCI_DEVICE_ID_AMD_CS5536_AUDIO 0x2093
-
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
[MLSXFRM] Fix mis-labelling of child sockets
Accepted connections of types other than AF_INET, AF_INET6, AF_UNIX won't have an appropriate label derived from the peer, so don't use it. Signed-off-by: David Woodhouse [EMAIL PROTECTED] Acked-by: Stephen Smalley [EMAIL PROTECTED] --- linux-2.6.18.ppc/security/selinux/hooks.c~ 2006-09-28 14:37:20.0 +0100 +++ linux-2.6.18.ppc/security/selinux/hooks.c 2006-09-29 19:00:25.0 +0100 @@ -3604,7 +3604,9 @@ void selinux_sock_graft(struct sock* sk, struct inode_security_struct *isec = SOCK_INODE(parent)-i_security; struct sk_security_struct *sksec = sk-sk_security; - isec-sid = sksec-sid; + if (sk-sk_family == PF_INET || sk-sk_family == PF_INET6 || + sk-sk_family == PF_UNIX) + isec-sid = sksec-sid; selinux_netlbl_sock_graft(sk, parent); } -- dwmw2 - 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] NetLabel: secid reconciliation support
@@ -3672,16 +3674,20 @@ static int selinux_skb_flow_in(struct sk
if (err)
goto out;
- if (xfrm_sid) {
- err = security_transition_sid(xfrm_sid, skb-secmark,
-
SECCLASS_PACKET, trans_sid);
- if (err)
- goto out;
+ if (xfrm_sid)
+ skb-secmark = xfrm_sid;
- skb-secmark = trans_sid;
- }
+ err = selinux_netlbl_skb_sid(skb, skb-secmark, nlbl_sid);
I take it nlbl_sid here will be 0 if netlabel is NOT configured
for the traffic correct?
--- net-2.6.orig/security/selinux/ss/mls.c
+++ net-2.6/security/selinux/ss/mls.c
@@ -547,7 +547,7 @@ int mls_compute_sid(struct context *scon
rtr-target_range);
}
}
- else if (tclass == SECCLASS_PACKET)
+ if (tclass == SECCLASS_PACKET)
What's the purpose of getting rid of else above?
I haven't reviewed the netlbl native changes, but the hooks.c changes
seem ok to me.
-
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] tcp-lp: prevent chance for oops
From: Wong Edison [EMAIL PROTECTED] Date: Sat, 30 Sep 2006 03:27:00 +0800 I do this since i have a sourceforge homepage for it. I update the CVS version there, test, and then submit to netdev. As I sync code in both side, this $Id$ is keeped. May you just let it be? I think it will let my maintenance become more simple... You could not even generate a clean patch to me, it just gets in the way and causes more work for me and anyone else who tries to use your patches. If you want to use versioning, use MODULE_VERSION() just like everyone else in the kernel does. - 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
What's new in wireless-dev today? (29 September 2006)
Here is today's batch -- I'm still playing catch-up in the
wireless-dev tree. Please bear with me...
---
The following changes since commit 0888451bf4108fbaa07b221649b1289d8f79ef0f:
John W. Linville:
Merge branch 'from-linus'
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
David Kimdon:
d80211: fix multiple device ap support
d80211: Fix type of prism2_hostapd_param crypt.alg
d80211: allow vlan interfaces to receive ToDS frames
Hong Liu:
d80211: fix wpa_supplicant reassoc problem
d80211: add hardware scan callback
d80211: fix iwconfig key [x] behavior
Ivo van Doorn:
rt2x00: remove hardware button support
Jiri Benc:
d80211: fix invalid pointer dereference
Johannes Berg:
d80211: use BUILD_BUG_ON
d80211: clean up those huge else if statements
d80211: use list_for_each_entry{,_safe}
d80211: LED triggers
John W. Linville:
Merge branch 'fixes-for-linville' of http://bu3sch.de/git/wireless-dev
Merge branch 'up' of rsync://rsync.kernel.org/.../jbenc/dscape
mabbas:
d80211: diplay supported rates in readable format
Michael Buesch:
ssb: fix init sprom read/write race
add bcm43xx-d80211 MAINTAINERS entry
Michael Wu:
d80211: fix WEP on big endian cpus
Mohamed Abbas:
d80211: getting wrong freq value if we did hardware scan
MAINTAINERS|8 +
drivers/misc/ssb.c | 29 +++--
drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c |6 +
drivers/net/wireless/d80211/rt2x00/Kconfig | 27 -
drivers/net/wireless/d80211/rt2x00/rt2400pci.c | 36 --
drivers/net/wireless/d80211/rt2x00/rt2500pci.c | 36 --
drivers/net/wireless/d80211/rt2x00/rt2x00.h|8 -
drivers/net/wireless/d80211/rt2x00/rt2x00pci.h | 111
drivers/net/wireless/d80211/rt2x00/rt61pci.c | 36 --
include/linux/ssb.h| 15 +++
include/net/d80211.h | 46 ++--
net/d80211/Kconfig |9 ++
net/d80211/Makefile| 10 +-
net/d80211/hostapd_ioctl.h |2
net/d80211/ieee80211.c | 73 +
net/d80211/ieee80211_dev.c |7 +
net/d80211/ieee80211_i.h |6 +
net/d80211/ieee80211_iface.c |2
net/d80211/ieee80211_ioctl.c | 108 ++-
net/d80211/ieee80211_led.c | 93 ++---
net/d80211/ieee80211_led.h | 32 ++
net/d80211/ieee80211_sta.c | 107 +++
net/d80211/sta_info.c | 26 ++---
net/d80211/wep.c | 10 +-
24 files changed, 371 insertions(+), 472 deletions(-)
create mode 100644 net/d80211/ieee80211_led.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3748cb1..2f06c7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -464,6 +464,14 @@ L: linux-hams@vger.kernel.org
W: http://www.baycom.org/~tom/ham/ham.html
S: Maintained
+BCM43XX WIRELESS DRIVER (DEVICESCAPE BASED VERSION)
+P: Michael Buesch
+M: [EMAIL PROTECTED]
+P: Stefano Brivio
+M: [EMAIL PROTECTED]
+W: http://bcm43xx.berlios.de/
+S: Maintained
+
BCM43XX WIRELESS DRIVER (SOFTMAC BASED VERSION)
P: Larry Finger
M: [EMAIL PROTECTED]
diff --git a/drivers/misc/ssb.c b/drivers/misc/ssb.c
index 44ab647..6087977 100644
--- a/drivers/misc/ssb.c
+++ b/drivers/misc/ssb.c
@@ -516,8 +516,6 @@ int ssb_init(struct ssb *ssb,
int (*device_suspend)(struct ssb *ssb),
int (*device_resume)(struct ssb *ssb))
{
- int err;
-
if (!ssb || !pci_dev || !mmio ||
!device_suspend || !device_resume)
return -EINVAL;
@@ -535,19 +533,12 @@ int ssb_init(struct ssb *ssb,
list_add(ssb-list, ssb_list);
mutex_unlock(ssb_list_mutex);
- err = device_create_file(pci_dev-dev, dev_attr_ssb_sprom);
- if (err)
- goto out;
-
-out:
- return err;
+ return 0;
}
EXPORT_SYMBOL_GPL(ssb_init);
void ssb_exit(struct ssb *ssb)
{
- device_remove_file(ssb-pci_dev-dev, dev_attr_ssb_sprom);
-
mutex_lock(ssb_list_mutex);
list_del(ssb-list);
mutex_unlock(ssb_list_mutex);
@@ -558,6 +549,24 @@ void ssb_exit(struct ssb *ssb)
}
EXPORT_SYMBOL_GPL(ssb_exit);
+int ssb_start(struct ssb *ssb)
+{
+ int err;
+
+ err = device_create_file(ssb-pci_dev-dev,
+dev_attr_ssb_sprom);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(ssb_start);
+
+void ssb_stop(struct ssb *ssb)
+{
+ device_remove_file(ssb-pci_dev-dev,
+
Re: [PATCH][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
Michael Chan wrote: AMD believes this incompatibility is unique to the 5706, and prefers to locally disable MSI rather than globally disabling it using pci_msi_quirk. Why is it unique to the 5706? Is this just a guess on AMD and Broadcom's part? Jeff - 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: rewriting skb-truesize... good or bad idea
From: Vlad Yasevich [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 14:16:57 -0400 I've attached the patch, in case people want to look at the code. However, we question if this is a good idea or if this is going to break things... Modification of skb-truesize is very dangerous and is only legal in a very limited set of circumstances. The core problem is that if any other reference exists to the skb you could corrupt existing socket accounting by changing skb-truesize. Let's say that the packet went into a network tap like tcpdump and the packet has been charged to an AF_PACKET socket via skb-truesize. If you modify skb-truesize then when the AF_PACKET socket releases it's reference it will subtract the wrong amount of skb-truesize from the socket receive buffer. If, on the other hand, you know you have exclusive access to the skb and there are no other references, setting skb-truesize can be OK. However setting it to sizeof(struct sk_buff) doesn't make sense since there is at least: sizeof(struct sk_buff) + sizeof(struct skb_shared_info) memory assosciated with any SKB whatsoever in the kernel. That is, even for a zero length skb-data buffer, we still always allocate the skb_shared_info area which must be accounted for. BTW, I think the whole chunking mechanism in the SCTP code is the largest source of problems and maintainability issues in that stack. Any time I want to make major modifications to SKBs to make them smaller or whatever, the most difficult piece of code to adjust is this code. - 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: [MLSXFRM] Fix mis-labelling of child sockets
On Fri, 29 Sep 2006, David Woodhouse wrote: Accepted connections of types other than AF_INET, AF_INET6, AF_UNIX won't have an appropriate label derived from the peer, so don't use it. Signed-off-by: David Woodhouse [EMAIL PROTECTED] Acked-by: Stephen Smalley [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] Please apply as a bugfix. -- 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][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
On Fri, 2006-09-29 at 17:28 -0400, Jeff Garzik wrote: Michael Chan wrote: AMD believes this incompatibility is unique to the 5706, and prefers to locally disable MSI rather than globally disabling it using pci_msi_quirk. Why is it unique to the 5706? Is this just a guess on AMD and Broadcom's part? I just took AMD's word for it. It doesn't matter to me whether we disable it locally or globally. Since this is AMD's bridge, I just follow their recommendation. They probably haven't seen this issue on any other devices except ours. - 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] NetLabel: secid reconciliation support
Venkat Yekkirala wrote:
@@ -3672,16 +3674,20 @@ static int selinux_skb_flow_in(struct sk
if (err)
goto out;
- if (xfrm_sid) {
- err = security_transition_sid(xfrm_sid, skb-secmark,
-
SECCLASS_PACKET, trans_sid);
- if (err)
- goto out;
+ if (xfrm_sid)
+ skb-secmark = xfrm_sid;
- skb-secmark = trans_sid;
- }
+ err = selinux_netlbl_skb_sid(skb, skb-secmark, nlbl_sid);
I take it nlbl_sid here will be 0 if netlabel is NOT configured
for the traffic correct?
That would be the desired behavior yes, however, in verifying this
against the
patch I posted I noticed that the dummy function in
security/selinux/include/selinux_netlabel.h is wrong - it should be replaced
with the following (I mistakenly set it to SECINITSID_UNLABELED):
static inline int selinux_netlbl_skb_sid(struct sk_buff *skb,
u32 base_sid,
u32 *sid)
{
*sid = 0;
return 0;
}
--- net-2.6.orig/security/selinux/ss/mls.c
+++ net-2.6/security/selinux/ss/mls.c
@@ -547,7 +547,7 @@ int mls_compute_sid(struct context *scon
rtr-target_range);
}
}
- else if (tclass == SECCLASS_PACKET)
+ if (tclass == SECCLASS_PACKET)
What's the purpose of getting rid of else above?
Fix a compile problem - the braces above the else belong to a for loop.
Feel free to disregard this, it was one of the changes I had to make to
your patch to get it to compile against the latest net-2.6 tree.
I haven't reviewed the netlbl native changes, but the hooks.c changes
seem ok to me.
Okay, if you have any other questions you know where to find me.
--
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 7/7] secid reconciliation-v03: Enforcement for SELinux
Venkat, With xfrm labeling, the external packets are always going to be protocol ESP or AH, and we can't connection track the inner protocols. So, Are you sure? This doesn't compare to what my limited testing seems to have turned up (normal netfiltering of inner protos followed by xfrms, interspersed with their own netfiltering). external labeling when using xfrm labeling seems somewhat superfluous, except for the case of setting a label based on the interface the packets arrived on. Correct? If so, all you can realistically do with the flow permissions is bind the ESP/AH packets to types of interfaces (which does seem useful for some folk). - 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] b44: fix multicast with 32 groups
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); - 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 7/7] secid reconciliation-v03: Enforcement for SELinux
It seems more of a pain to actually prevent their use at the same time and/or explain strange/unnatural behavior. Agreed, the solution that we agreed upon is much easier to implement and explain than a lot of the alternatives. Ok, can you please explain it further? i.e. show me what the policy looks like, exactly what the user is trying to achieve, and explain what happens to each packet exactly in terms of labeling on the input and output paths. Also, why can't this be done just with xfrm labeling? I believe the issue Venkat and I were discussing was how to handle the case of multiple external labeling protocols, i.e. what to do if we get a packet through labeled SA which has a CIPSO option. As I've said before, I don't believe this is something we will see much in practice but I think we need to decide what to do: handle it somehow or just punt on the problem and drop it. Several people with experience with external labeling have commented on how supporting both external labeling protocols would be a good idea so Venkat and I are trying to come up with a solution that works. Here's the scoop on using xfrm and cipso at the same time: JUST REDUNDANT I was only paying attention to the inbound side when I was saying a ranged SA could be used in conjunction with fine-grained cipso labeling. In actuality, this isn't possible because of the change we are instituting for SA selection to be based on the context of the sock (specifically, the sock's MLS range must equal the range on the SA, and cipso at this point would be representing this same range). So, if someone were to configure CIPSO along with labeled ipsec, BOTH mechanisms will be used, with BOTH labels carrying the same MLS range, and with CIPSO always overriding the SA (after a flow_in check) on the inbound. Should just be additional overhead, that's all. - 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/3] myri10ge Large Receive Offload
Jeff Garzik a écrit : Brice Goglin wrote: This is a complete rework of the myri10ge receive path. The first patch converts skb allocation to use physical pages. The second one adds a software implementation of Large Receive Offload. The third one updates the driver version to 1.1.0. The complete driver code in our CVS actually also supports high-order allocations instead of single physical pages since it significantly increase the performance. Order=2 allows us to receive standard frames at line rate even on low-end hardware such as an AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2.0GHz). Some customer might not care a lot about memory fragmentation if the performance is better. But, since high-order allocations are generally considered a bad idea, we do not include the relevant code in the following patch for inclusion in Linux. Here, we simply pass order=0 to all page allocation routines. If necessary, I could drop the remaining reference to high-order (especially replace alloc_pages() with alloc_page()) but I'd rather keep it as is. If high-order allocations are ever considered OK under some circum- stances, we could send an additional patch (a module parameter would be used to switch from single physical pages to high-order pages). As Herbert's already done, I would rather let the net core people comment on this. The code implementation doesn't look scary, but we may want to be smarter about this in the core net stack, rather than implementing it inside multiple drivers. Ok, makes sense. We look forward to see this. Could we get patch #1 merged anyway (page-based skb allocation)? Any comments about what I was saying about high-order allocations above? thanks, Brice - 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
Johannes Berg wrote: * Should the userspace daemon be allowed to unilaterally update the regulatory information if it learns something new (via the user)? Many countries forbid users (root is still a user) being enabled to override the parameters set up by the hardware vendor as tested for use with a specific device. If the hardware and/or driver for the hardware advertises a set of operating parameters, user space should honor those settings and the kernel should enforce them. User space should be able to shrink the set of available spectrum parameters but should not expand it. Or why not even just publish the regulatory information APs might broadcast in the scan results, and let the userspace daemon pick that apart? Then the kernel need not ask for anything at all... I think exposing this information to the user would be useful, and indicate which capabilities are restricted based on information provided by the kernel and/or hardware driver. When channel 13 doesn't work, it should be clear to the user why so they know who to get mad at. * I seem to have read between the lines that the EEPROM data is pretty much useless. Is that generally true, or should the userspace daemon be told what it contains (somehow)? The EEPROM contents typically represent the configuration and operating parameters which have been tested and certified to be operational. These would represent the only settings which a user can operate with and still be covered by existing certifications. Regardless of which country you are operating a device in, the device was intended for sale within a specific geographic and regulatory region -- it was tested and certified accordingly. The EEPROM contents typically provide the information on what was tested and what the approved operating parameters are for that device. * Should the kernel perform some kind of validation on the regulatory data the daemon gives it as well? The kernel should enforce the parameters as specified by the hardware/driver. In the event that a driver does not advertise a set of capabilities, the kernel should select the minimal safe set, which would be a subset of the 2.4Ghz spectrum and likely exclude all of 5.2Ghz. Right now I'd think that it would make sense to just leave the whole task to our userspace daemon, iow. nl80211 just provides a command to update the kernel's knowledge about regulory and the daemon periodically checks the scan results for country information, asks the user for the country, or similar. If it's not running, the kernel simply starts from a generic no-frills set. With hardware that restricts operation to the capabilities it was tested and calibrated for, this will likely result in a broken user experience -- if they try and use a device on channel 13 and the device restricts operation to channels 1 - 11, tuning operations will fail. James - 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: [MLSXFRM] Fix mis-labelling of child sockets
James Morris wrote: On Fri, 29 Sep 2006, David Woodhouse wrote: Accepted connections of types other than AF_INET, AF_INET6, AF_UNIX won't have an appropriate label derived from the peer, so don't use it. Signed-off-by: David Woodhouse [EMAIL PROTECTED] Acked-by: Stephen Smalley [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] Please apply as a bugfix. Sorry for the late response. Acked-by: Paul Moore [EMAIL PROTECTED] -- 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][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 14:39:23 -0700 On Fri, 2006-09-29 at 17:28 -0400, Jeff Garzik wrote: Michael Chan wrote: AMD believes this incompatibility is unique to the 5706, and prefers to locally disable MSI rather than globally disabling it using pci_msi_quirk. Why is it unique to the 5706? Is this just a guess on AMD and Broadcom's part? I just took AMD's word for it. It doesn't matter to me whether we disable it locally or globally. Since this is AMD's bridge, I just follow their recommendation. They probably haven't seen this issue on any other devices except ours. I really think this is a reasonable thing to do. It's absolutely rediculious to disable MSI for every card just because one decided to use a masked 64-bit transaction for what's supposed to be a 32-bit one. Jeff, I totally understand your knee-jerk reaction to per-device MSI validation checks, but in this case I find that knee-jerk reaction to be totally unreasonable. :-) - 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: Bcm43xx softMac Driver in 2.6.18
(re-adding linux-kernel.) Larry Finger wrote: Would you please test the attached patch that should be applied to a vanilla 2.6.18? I'm currently running it, but only for a few minutes. It comes up fine and I ran it through several ifdown/ifup cycles without any problem. Okay, this is far better than vanilla 2.6.18 (or your other patch). I've been running this for six hours so far with no troubles, when before I'd have a hard system freeze within a minute or two of associating (or trying to associate) with an access point. As for -stable, the patch is sorta, y'know, ginormous: bcm43xx.h | 181 +- bcm43xx_debugfs.c | 80 bcm43xx_debugfs.h |1 bcm43xx_dma.c | 583 +++--- bcm43xx_dma.h | 296 + bcm43xx_leds.c| 10 bcm43xx_main.c| 905 +++--- bcm43xx_main.h|6 bcm43xx_phy.c | 48 +- bcm43xx_pio.c |4 bcm43xx_sysfs.c | 46 +- bcm43xx_wx.c | 121 +++ 12 files changed, 1426 insertions(+), 855 deletions(-) OTOH, the current version is completely unusable on this system, so I don't know if the right path is to revert the driver to 2.6.17's version, or to try to move forward with the patch when it's had hard review and testing. I'm heading out on vacation for the next two weeks. I'll catch up with any mail directed to me for more things to try (or report about this specific system), if requested, when I get back. (Or catch me today.) Thank you very much for your help, Ray - 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][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
David Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 14:39:23 -0700 On Fri, 2006-09-29 at 17:28 -0400, Jeff Garzik wrote: Michael Chan wrote: AMD believes this incompatibility is unique to the 5706, and prefers to locally disable MSI rather than globally disabling it using pci_msi_quirk. Why is it unique to the 5706? Is this just a guess on AMD and Broadcom's part? I just took AMD's word for it. It doesn't matter to me whether we disable it locally or globally. Since this is AMD's bridge, I just follow their recommendation. They probably haven't seen this issue on any other devices except ours. I really think this is a reasonable thing to do. It's absolutely rediculious to disable MSI for every card just because one decided to use a masked 64-bit transaction for what's supposed to be a 32-bit one. Jeff, I totally understand your knee-jerk reaction to per-device MSI validation checks, but in this case I find that knee-jerk reaction to be totally unreasonable. :-) How it is unreasonable to clarify a completely vague description of the problem? The patch and description provided no information about whether or not it would be better to blacklist 8132 globally, as we have already done with the 8131. Jeff - 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][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 19:00:15 -0400 The patch and description provided no information about whether or not it would be better to blacklist 8132 globally, as we have already done with the 8131. It absolutely was not vague, it gave an explicit description of what the problem was, down to the transaction type being used by 5706 and what the stated rules are in the PCI spec, and it also gave a clear indication that the 5706 was in the wrong and that this was believed to be a unique situation. - 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][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
David Miller wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 19:00:15 -0400 The patch and description provided no information about whether or not it would be better to blacklist 8132 globally, as we have already done with the 8131. It absolutely was not vague, it gave an explicit description of what the problem was, down to the transaction type being used by 5706 and what the stated rules are in the PCI spec, and it also gave a clear indication that the 5706 was in the wrong and that this was believed to be a unique situation. It was completely vague as to why this incompatibility was specific to the 5706, when -- as the description noted -- the behavior is legal. Re-read the patch. At no time does it say 5706 was in the wrong. Jeff - 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][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
On Fri, 2006-09-29 at 19:15 -0400, Jeff Garzik wrote: It was completely vague as to why this incompatibility was specific to the 5706, when -- as the description noted -- the behavior is legal. The description is a bit vague in that one aspect that Jeff pointed out, but otherwise very complete in my opinion. Re-read the patch. At no time does it say 5706 was in the wrong. The behavior is legal but AMD believes that it is unique to the 5706. I cannot make this less vague since it is a recommendation from AMD. I just trust their opinion on 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: [PATCH][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 19:15:14 -0400 It was completely vague as to why this incompatibility was specific to the 5706, when -- as the description noted -- the behavior is legal. Re-read the patch. At no time does it say 5706 was in the wrong. True, but it does indicate that using a masked 64-bit transaction for MSI instead of a true 32-bit one is considered to be quite rare. Do you wish to put a table of all devices that do this, and at PCI quirk time disable PCI for everyone on the AMD chipset if even one such device is found in the device? That doesn't make any sense to me. - 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][BNX2]: Disable MSI on 5706 if AMD 8132 bridge is present
It absolutely was not vague, it gave an explicit description of what the problem was, down to the transaction type being used by 5706 and what the stated rules are in the PCI spec, and it also gave a clear indication that the 5706 was in the wrong and that this was believed to be a unique situation. I'm not disagreeing with a per-driver check at the moment, but I thought that Michael told us that the masking being attempted by the 5706 was legal: Michael Chan wrote: MSI is defined to be 32-bit write. The 5706 does 64-bit MSI writes with byte enables disabled on the unused 32-bit word. This is legal but causes problems on the AMD 8132 which will eventually stop responding after a while. ... MSI is defined to be 32-bit write. The 5706 does 64-bit MSI writes with byte enables disabled on the unused 32-bit word. This is legal but causes problems on the AMD 8132 which will eventually stop responding after a while. rick jones - 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/4] [SCTP]: Use correct mask when disabling PMTUD.
From: Sridhar Samudrala [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 13:00:29 -0700 [SCTP]: Use correct mask when disabling PMTUD. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [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 6/8][ATM]: [lec] use work queue instead of timer for lec arp expiry
From: chas williams - CONTRACTOR [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 12:44:35 -0400 please consider for 2.6.19 -- thanks! [ATM]: [lec] use work queue instead of timer for lec arp expiry Signed-off-by: Chas Williams [EMAIL PROTECTED] Applied. - 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 4/4] [SCTP]: Do not timestamp every SCTP packet.
From: Sridhar Samudrala [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 13:00:37 -0700 [SCTP]: Do not timestamp every SCTP packet. We only need the timestamp on COOKIE-ECHO chunks, so instead of always timestamping every SCTP packet, let common code timestamp if the socket option is set. For COOKIE-ECHO, simply get the time of day if we don't have a timestamp. This introduces a small possibility that the cookie may be considered expired, but it will be renegotiated. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] Also applied, 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 4/8][ATM]: [lec] convert lec_arp_table to hlist
From: chas williams - CONTRACTOR [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 12:40:47 -0400 please consider for 2.6.19 -- thanks! [ATM]: [lec] convert lec_arp_table to hlist Signed-off-by: Chas Williams [EMAIL PROTECTED] Applied. - 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/8][ATM]: [lec] indent, comment and whitespace cleanup
From: chas williams - CONTRACTOR [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 12:37:26 -0400 [ATM]: [lec] indent, comment and whitespace cleanup Signed-off-by: Chas Williams [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
