* Re: [PATCH net 0/9] net/smc: bug fixes 2017-09-20
From: David Miller @ 2017-09-21 22:31 UTC (permalink / raw)
To: ubraun
Cc: netdev, linux-rdma, linux-s390, jwi, schwidefsky, heiko.carstens,
raspl
In-Reply-To: <20170921071634.16883-1-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Thu, 21 Sep 2017 09:16:25 +0200
> here is a collection of small smc-patches built for net fixing
> smc problems in different areas.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next ] net: Remove useless function skb_header_release
From: David Miller @ 2017-09-21 22:25 UTC (permalink / raw)
To: gfree.wind; +Cc: netdev
In-Reply-To: <1505968771-92232-1-git-send-email-gfree.wind@vip.163.com>
From: gfree.wind@vip.163.com
Date: Thu, 21 Sep 2017 12:39:31 +0800
> From: Gao Feng <gfree.wind@vip.163.com>
>
> There is no one which would invokes the function skb_header_release.
> So just remove it now.
>
> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
As Joe Perches mentioned, there are comment references remaining.
This should be removed too because they can be confusing for people.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: add port fdb dump
From: David Miller @ 2017-09-21 22:24 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170920233214.6936-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Wed, 20 Sep 2017 19:32:14 -0400
> Dumping a DSA port's FDB entries is not specific to a DSA slave, so add
> a dsa_port_fdb_dump function, similarly to dsa_port_fdb_add and
> dsa_port_fdb_del.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: better scoping of slave functions
From: David Miller @ 2017-09-21 22:24 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170920233157.6832-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Wed, 20 Sep 2017 19:31:57 -0400
> A few DSA slave functions take a dsa_slave_priv pointer as first
> argument, whereas the scope of the slave.c functions is the slave
> net_device structure. Fix this and rename dsa_netpoll_send_skb to
> dsa_slave_netpoll_send_skb.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied.
^ permalink raw reply
* Re: [PATCH v5 net 0/3] lan78xx: This series of patches are for lan78xx driver.
From: David Miller @ 2017-09-21 22:23 UTC (permalink / raw)
To: Nisar.Sayed; +Cc: UNGLinuxDriver, netdev
In-Reply-To: <20170920210638.11150-1-Nisar.Sayed@microchip.com>
From: Nisar Sayed <Nisar.Sayed@microchip.com>
Date: Thu, 21 Sep 2017 02:36:35 +0530
> This series of patches are for lan78xx driver.
>
> These patches fixes potential issues associated with lan78xx driver.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net 0/2] Bring back transceiver type for PHYLIB
From: David Miller @ 2017-09-21 22:20 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, linville, decot, tremyfr, andrew
In-Reply-To: <20170920225214.21974-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 20 Sep 2017 15:52:12 -0700
> With the introduction of the xLINKSETTINGS ethtool APIs, the transceiver type
> was deprecated, but in that process we lost some useful information that PHYLIB
> was consistently reporting about internal vs. external PHYs.
>
> This brings back transceiver as a read-only field that is only consumed in the
> legacy path where ETHTOOL_GET is called but the underlying drivers implement the
> new style klink_settings API.
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH] [RESEND][for 4.14] net: qcom/emac: add software control for pause frame mode
From: David Miller @ 2017-09-21 22:19 UTC (permalink / raw)
To: timur; +Cc: netdev
In-Reply-To: <1505939573-17335-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Wed, 20 Sep 2017 15:32:53 -0500
> The EMAC has the option of sending only a single pause frame when
> flow control is enabled and the RX queue is full. Although sending
> only one pause frame has little value, this would allow admins to
> enable automatic flow control without having to worry about the EMAC
> flooding nearby switches with pause frames if the kernel hangs.
>
> The option is enabled by using the single-pause-mode private flag.
>
> Signed-off-by: Timur Tabi <timur@codeaurora.org>
I guess this is fine. Applied, thanks.
^ permalink raw reply
* Re: [PATCH] hv_netvsc: fix send buffer failure on MTU change
From: David Miller @ 2017-09-21 22:18 UTC (permalink / raw)
To: stephen; +Cc: kys, netdev, alexng, sthemmin
In-Reply-To: <20170920181735.31316-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 20 Sep 2017 11:17:35 -0700
> From: Alex Ng <alexng@microsoft.com>
>
> If MTU is changed the host would reject the send buffer change.
> This problem is result of recent change to allow changing send
> buffer size.
>
> Every time we change the MTU, we store the previous net_device section
> count before destroying the buffer, but we don’t store the previous
> section size. When we reinitialize the buffer, its size is calculated
> by multiplying the previous count and previous size. Since we
> continuously increase the MTU, the host returns us a decreasing count
> value while the section size is reinitialized to 1728 bytes every
> time.
>
> This eventually leads to a condition where the calculated buf_size is
> so small that the host rejects it.
>
> Fixes: 8b5327975ae1 ("netvsc: allow controlling send/recv buffer size")
> Signed-off-by: Alex Ng <alexng@microsoft.com>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: use dedicated CPU port
From: David Miller @ 2017-09-21 22:16 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170920162805.29503-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Wed, 20 Sep 2017 12:28:05 -0400
> Each port in DSA has its own dedicated CPU port currently available in
> its parent switch's ds->ports[port].cpu_dp. Use it instead of getting
> the unique tree CPU port, which will be deprecated soon.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: avoid a full fib lookup when rp_filter is disabled.
From: David Miller @ 2017-09-21 22:15 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet, hannes
In-Reply-To: <597db26b5e57eb89d2ff27454cce997fa6c0f5aa.1505924560.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 20 Sep 2017 18:26:53 +0200
> Since commit 1dced6a85482 ("ipv4: Restore accept_local behaviour
> in fib_validate_source()") a full fib lookup is needed even if
> the rp_filter is disabled, if accept_local is false - which is
> the default.
>
> What we really need in the above scenario is just checking
> that the source IP address is not local, and in most case we
> can do that is a cheaper way looking up the ifaddr hash table.
>
> This commit adds a helper for such lookup, and uses it to
> validate the src address when rp_filter is disabled and no
> 'local' routes are created by the user space in the relevant
> namespace.
>
> A new ipv4 netns flag is added to account for such routes.
> We need that to preserve the same behavior we had before this
> patch.
>
> It also drops the checks to bail early from __fib_validate_source,
> added by the commit 1dced6a85482 ("ipv4: Restore accept_local
> behaviour in fib_validate_source()") they do not give any
> measurable performance improvement: if we do the lookup with are
> on a slower path.
>
> This improves UDP performances for unconnected sockets
> when rp_filter is disabled by 5% and also gives small but
> measurable performance improvement for TCP flood scenarios.
>
> v1 -> v2:
> - use the ifaddr lookup helper in __ip_dev_find(), as suggested
> by Eric
> - fall-back to full lookup if custom local routes are present
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Looks good, applied, thanks!
^ permalink raw reply
* Re: [Patch net] net_sched: remove cls_flower idr on failure
From: David Miller @ 2017-09-21 22:14 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, chrism, jiri
In-Reply-To: <20170920161845.28753-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 20 Sep 2017 09:18:45 -0700
> Fixes: c15ab236d69d ("net/sched: Change cls_flower to use IDR")
> Cc: Chris Mi <chrism@mellanox.com>
> Cc: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
From: Florian Fainelli @ 2017-09-21 22:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paweł Staszewski, Paolo Abeni, Jesper Dangaard Brouer,
Linux Kernel Network Developers, Alexander Duyck
In-Reply-To: <1506030895.29839.153.camel@edumazet-glaptop3.roam.corp.google.com>
On 09/21/2017 02:54 PM, Eric Dumazet wrote:
> On Thu, 2017-09-21 at 14:41 -0700, Florian Fainelli wrote:
>
>> Would not this apply to pretty much any stacked device setup though? It
>> seems like any network device that just queues up its packet on another
>> physical device for actual transmission may need that (e.g: DSA, bond,
>> team, more.?)
>
> We support bonding and team already.
Right, so that seems to mostly leave us with DSA at least. What about
other devices that also have IFF_NO_QUEUE set?
--
Florian
^ permalink raw reply
* [PATCH] e1000: avoid null pointer dereference on invalid stat type
From: Colin King @ 2017-09-21 22:01 UTC (permalink / raw)
To: Jeff Kirsher, intel-wired-lan, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently if the stat type is invalid then data[i] is being set
either by dereferencing a null pointer p, or it is reading from
an incorrect previous location if we had a valid stat type
previously. Fix this by nullify pointer p if a stat type is
invalid and only setting data if p is not null.
Detected by CoverityScan, CID#113385 ("Explicit null dereferenced")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index ec8aa4562cc9..2ef6f08b580b 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -1824,11 +1824,12 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
{
struct e1000_adapter *adapter = netdev_priv(netdev);
int i;
- char *p = NULL;
const struct e1000_stats *stat = e1000_gstrings_stats;
e1000_update_stats(adapter);
for (i = 0; i < E1000_GLOBAL_STATS_LEN; i++) {
+ char *p;
+
switch (stat->type) {
case NETDEV_STATS:
p = (char *)netdev + stat->stat_offset;
@@ -1837,12 +1838,13 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
p = (char *)adapter + stat->stat_offset;
break;
default:
+ p = NULL;
WARN_ONCE(1, "Invalid E1000 stat type: %u index %d\n",
stat->type, i);
break;
}
- if (stat->sizeof_stat == sizeof(u64))
+ if (p && stat->sizeof_stat == sizeof(u64))
data[i] = *(u64 *)p;
else
data[i] = *(u32 *)p;
--
2.14.1
^ permalink raw reply related
* [RFC PATCH 2/2] userns: control capabilities of some user namespaces
From: Mahesh Bandewar @ 2017-09-21 21:56 UTC (permalink / raw)
To: LKML, Netdev
Cc: Kees Cook, Serge Hallyn, Eric W . Biederman, Eric Dumazet,
David Miller, Mahesh Bandewar, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
With this new notion of "controlled" user-namespaces, the controlled
user-namespaces are marked at the time of their creation while the
capabilities of processes that belong to them are controlled using the
global mask.
Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
that belongs to uncontrolled user-ns can create another (child) user-
namespace that is uncontrolled. Any other process (that either does
not have SYS_ADMIN or belongs to a controlled user-ns) can only
create a user-ns that is controlled.
global-capability-whitelist (controlled_userns_caps_whitelist) is used
at the capability check-time and keeps the semantics for the processes
that belong to uncontrolled user-ns as it is. Processes that belong to
controlled user-ns however are subjected to different checks-
(a) if the capability in question is controlled and process belongs
to controlled user-ns, then it's always denied.
(b) if the capability in question is NOT controlled then fall back
to the traditional check.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
include/linux/capability.h | 1 +
include/linux/user_namespace.h | 20 ++++++++++++++++++++
kernel/capability.c | 5 +++++
kernel/user_namespace.c | 3 +++
security/commoncap.c | 8 ++++++++
5 files changed, 37 insertions(+)
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 6c0b9677c03f..b8c6cac18658 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -250,6 +250,7 @@ extern bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns);
extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
int proc_douserns_caps_whitelist(struct ctl_table *table, int write,
void __user *buff, size_t *lenp, loff_t *ppos);
+bool is_capability_controlled(int cap);
extern int cap_convert_nscap(struct dentry *dentry, void **ivalue, size_t size);
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index c18e01252346..e890fe81b47e 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -22,6 +22,7 @@ struct uid_gid_map { /* 64 bytes -- 1 cache line */
};
#define USERNS_SETGROUPS_ALLOWED 1UL
+#define USERNS_CONTROLLED 2UL
#define USERNS_INIT_FLAGS USERNS_SETGROUPS_ALLOWED
@@ -102,6 +103,16 @@ static inline void put_user_ns(struct user_namespace *ns)
__put_user_ns(ns);
}
+static inline bool is_user_ns_controlled(const struct user_namespace *ns)
+{
+ return ns->flags & USERNS_CONTROLLED;
+}
+
+static inline void mark_user_ns_controlled(struct user_namespace *ns)
+{
+ ns->flags |= USERNS_CONTROLLED;
+}
+
struct seq_operations;
extern const struct seq_operations proc_uid_seq_operations;
extern const struct seq_operations proc_gid_seq_operations;
@@ -160,6 +171,15 @@ static inline struct ns_common *ns_get_owner(struct ns_common *ns)
{
return ERR_PTR(-EPERM);
}
+
+static inline bool is_user_ns_controlled(const struct user_namespace *ns)
+{
+ return false;
+}
+
+static inline void mark_user_ns_controlled(struct user_namespace *ns)
+{
+}
#endif
#endif /* _LINUX_USER_H */
diff --git a/kernel/capability.c b/kernel/capability.c
index 62dbe3350c1b..40a38cc4ff43 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -510,6 +510,11 @@ bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns)
}
/* Controlled-userns capabilities routines */
+bool is_capability_controlled(int cap)
+{
+ return !cap_raised(controlled_userns_caps_whitelist, cap);
+}
+
#ifdef CONFIG_SYSCTL
int proc_douserns_caps_whitelist(struct ctl_table *table, int write,
void __user *buff, size_t *lenp, loff_t *ppos)
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index c490f1e4313b..f393ea5108f0 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -53,6 +53,9 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns)
cred->cap_effective = CAP_FULL_SET;
cred->cap_ambient = CAP_EMPTY_SET;
cred->cap_bset = CAP_FULL_SET;
+ if (!ns_capable(user_ns->parent, CAP_SYS_ADMIN) ||
+ is_user_ns_controlled(user_ns->parent))
+ mark_user_ns_controlled(user_ns);
#ifdef CONFIG_KEYS
key_put(cred->request_key_auth);
cred->request_key_auth = NULL;
diff --git a/security/commoncap.c b/security/commoncap.c
index 6bf72b175b49..26f41602da10 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -73,6 +73,14 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
{
struct user_namespace *ns = targ_ns;
+ /* If the capability is controlled and user-ns that process
+ * belongs-to is 'controlled' then return EPERM and no need
+ * to check the user-ns hierarchy.
+ */
+ if (is_user_ns_controlled(cred->user_ns) &&
+ is_capability_controlled(cap))
+ return -EPERM;
+
/* See if cred has the capability in the target user namespace
* by examining the target user namespace and all of the target
* user namespace's parents.
--
2.14.1.821.g8fa685d3b7-goog
^ permalink raw reply related
* [RFC PATCH 1/2] capability: introduce sysctl for controlled user-ns capability whitelist
From: Mahesh Bandewar @ 2017-09-21 21:56 UTC (permalink / raw)
To: LKML, Netdev
Cc: Kees Cook, Serge Hallyn, Eric W . Biederman, Eric Dumazet,
David Miller, Mahesh Bandewar, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
Add a sysctl variable kernel.controlled_userns_caps_whitelist. This
takes input as capability mask expressed as two comma separated hex
u32 words. The mask, however, is stored in kernel as kernel_cap_t type.
Any capabilities that are not part of this mask will be controlled and
will not be allowed to processes in controlled user-ns.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
CC: Serge Hallyn <serge@hallyn.com>
CC: Kees Cook <keescook@chromium.org>
CC: "Eric W. Biederman" <ebiederm@xmission.com>
---
Documentation/sysctl/kernel.txt | 21 ++++++++++++++++++
include/linux/capability.h | 3 +++
kernel/capability.c | 47 +++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 5 +++++
4 files changed, 76 insertions(+)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index ce61d1fe08ca..ec0d74476f48 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -25,6 +25,7 @@ show up in /proc/sys/kernel:
- bootloader_version [ X86 only ]
- callhome [ S390 only ]
- cap_last_cap
+- controlled_userns_caps_whitelist
- core_pattern
- core_pipe_limit
- core_uses_pid
@@ -186,6 +187,26 @@ CAP_LAST_CAP from the kernel.
==============================================================
+controlled_userns_caps_whitelist
+
+Capability mask that is whitelisted for "controlled" user namespaces.
+Any capability that is missing from this mask will not be allowed to
+any process that is attached to a controlled-userns. e.g. if CAP_NET_RAW
+is not part of this mask, then processes running inside any controlled
+userns's will not be allowed to perform action that needs CAP_NET_RAW
+capability. However, processes that are attached to a parent user-ns
+hierarchy that is *not* controlled and has CAP_NET_RAW can continue
+performing those actions. User-namespaces are marked "controlled" at
+the time of their creation based on the capabilities of the creator.
+A process that does not have CAP_SYS_ADMIN will create user-namespaces
+that are controlled.
+
+The value is expressed as two comma separated hex words (u32). This
+sysctl is avaialble in init-ns and users with CAP_SYS_ADMIN in init-ns
+are allowed to make changes.
+
+==============================================================
+
core_pattern:
core_pattern is used to specify a core dumpfile pattern name.
diff --git a/include/linux/capability.h b/include/linux/capability.h
index b52e278e4744..6c0b9677c03f 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -13,6 +13,7 @@
#define _LINUX_CAPABILITY_H
#include <uapi/linux/capability.h>
+#include <linux/sysctl.h>
#define _KERNEL_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_3
@@ -247,6 +248,8 @@ extern bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns);
/* audit system wants to get cap info from files as well */
extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
+int proc_douserns_caps_whitelist(struct ctl_table *table, int write,
+ void __user *buff, size_t *lenp, loff_t *ppos);
extern int cap_convert_nscap(struct dentry *dentry, void **ivalue, size_t size);
diff --git a/kernel/capability.c b/kernel/capability.c
index f97fe77ceb88..62dbe3350c1b 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -28,6 +28,8 @@ EXPORT_SYMBOL(__cap_empty_set);
int file_caps_enabled = 1;
+kernel_cap_t controlled_userns_caps_whitelist = CAP_FULL_SET;
+
static int __init file_caps_disable(char *str)
{
file_caps_enabled = 0;
@@ -506,3 +508,48 @@ bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns)
rcu_read_unlock();
return (ret == 0);
}
+
+/* Controlled-userns capabilities routines */
+#ifdef CONFIG_SYSCTL
+int proc_douserns_caps_whitelist(struct ctl_table *table, int write,
+ void __user *buff, size_t *lenp, loff_t *ppos)
+{
+ DECLARE_BITMAP(caps_bitmap, CAP_LAST_CAP);
+ struct ctl_table caps_table;
+ char tbuf[NAME_MAX];
+ int ret;
+
+ ret = bitmap_from_u32array(caps_bitmap, CAP_LAST_CAP,
+ controlled_userns_caps_whitelist.cap,
+ _KERNEL_CAPABILITY_U32S);
+ if (ret != CAP_LAST_CAP)
+ return -1;
+
+ scnprintf(tbuf, NAME_MAX, "%*pb", CAP_LAST_CAP, caps_bitmap);
+
+ caps_table.data = tbuf;
+ caps_table.maxlen = NAME_MAX;
+ caps_table.mode = table->mode;
+ ret = proc_dostring(&caps_table, write, buff, lenp, ppos);
+ if (ret)
+ return ret;
+ if (write) {
+ kernel_cap_t tmp;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ ret = bitmap_parse_user(buff, *lenp, caps_bitmap, CAP_LAST_CAP);
+ if (ret)
+ return ret;
+
+ ret = bitmap_to_u32array(tmp.cap, _KERNEL_CAPABILITY_U32S,
+ caps_bitmap, CAP_LAST_CAP);
+ if (ret != CAP_LAST_CAP)
+ return -1;
+
+ controlled_userns_caps_whitelist = tmp;
+ }
+ return 0;
+}
+#endif /* CONFIG_SYSCTL */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6648fbbb8157..9903cf0de287 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1229,6 +1229,11 @@ static struct ctl_table kern_table[] = {
.extra2 = &one,
},
#endif
+ {
+ .procname = "controlled_userns_caps_whitelist",
+ .mode = 0644,
+ .proc_handler = proc_douserns_caps_whitelist,
+ },
{ }
};
--
2.14.1.821.g8fa685d3b7-goog
^ permalink raw reply related
* [RFC PATCH 0/2] capability controlled user-namespaces
From: Mahesh Bandewar @ 2017-09-21 21:56 UTC (permalink / raw)
To: LKML, Netdev
Cc: Kees Cook, Serge Hallyn, Eric W . Biederman, Eric Dumazet,
David Miller, Mahesh Bandewar, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
TL;DR version
-------------
Creating a sandbox environment with namespaces is challenging
considering what these sandboxed processes can engage into. e.g.
CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc. just to name few.
Current form of user-namespaces, however, if changed a bit can allow
us to create a sandbox environment without locking down user-
namespaces.
Detailed version
----------------
Problem
-------
User-namespaces in the current form have increased the attack surface as
any process can acquire capabilities which are not available to them (by
default) by performing combination of clone()/unshare()/setns() syscalls.
#define _GNU_SOURCE
#include <stdio.h>
#include <sched.h>
#include <netinet/in.h>
int main(int ac, char **av)
{
int sock = -1;
printf("Attempting to open RAW socket before unshare()...\n");
sock = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW);
if (sock < 0) {
perror("socket() SOCK_RAW failed: ");
} else {
printf("Successfully opened RAW-Sock before unshare().\n");
close(sock);
sock = -1;
}
if (unshare(CLONE_NEWUSER | CLONE_NEWNET) < 0) {
perror("unshare() failed: ");
return 1;
}
printf("Attempting to open RAW socket after unshare()...\n");
sock = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW);
if (sock < 0) {
perror("socket() SOCK_RAW failed: ");
} else {
printf("Successfully opened RAW-Sock after unshare().\n");
close(sock);
sock = -1;
}
return 0;
}
The above example shows how easy it is to acquire NET_RAW capabilities
and once acquired, these processes could take benefit of above mentioned
or similar issues discovered/undiscovered with malicious intent. Note
that this is just an example and the problem/solution is not limited
to NET_RAW capability *only*.
The easiest fix one can apply here is to lock-down user-namespaces which
many of the distros do (i.e. don't allow users to create user namespaces),
but unfortunately that prevents everyone from using them.
Approach
--------
Introduce a notion of 'controlled' user-namespaces. Every process on
the host is allowed to create user-namespaces (governed by the limit
imposed by per-ns sysctl) however, mark user-namespaces created by
sandboxed processes as 'controlled'. Use this 'mark' at the time of
capability check in conjunction with a global capability whitelist.
If the capability is not whitelisted, processes that belong to
controlled user-namespaces will not be allowed.
Once a user-ns is marked as 'controlled'; all its child user-
namespaces are marked as 'controlled' too.
A global whitelist is list of capabilities governed by the
sysctl which is available to (privileged) user in init-ns to modify
while it's applicable to all controlled user-namespaces on the host.
Marking user-namespaces controlled without modifying the whitelist is
equivalent of the current behavior. The default value of whitelist includes
all capabilities so that the compatibility is maintained. However it gives
admins fine-grained ability to control various capabilities system wide
without locking down user-namespaces.
Please see individual patches in this series.
Mahesh Bandewar (2):
capability: introduce sysctl for controlled user-ns capability
whitelist
userns: control capabilities of some user namespaces
Documentation/sysctl/kernel.txt | 21 +++++++++++++++++
include/linux/capability.h | 4 ++++
include/linux/user_namespace.h | 20 ++++++++++++++++
kernel/capability.c | 52 +++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 5 ++++
kernel/user_namespace.c | 3 +++
security/commoncap.c | 8 +++++++
7 files changed, 113 insertions(+)
--
2.14.1.821.g8fa685d3b7-goog
^ permalink raw reply
* Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
From: Eric Dumazet @ 2017-09-21 21:54 UTC (permalink / raw)
To: Florian Fainelli
Cc: Paweł Staszewski, Paolo Abeni, Jesper Dangaard Brouer,
Linux Kernel Network Developers, Alexander Duyck
In-Reply-To: <6607c631-580d-825b-6205-6f6ee688ce32@gmail.com>
On Thu, 2017-09-21 at 14:41 -0700, Florian Fainelli wrote:
> Would not this apply to pretty much any stacked device setup though? It
> seems like any network device that just queues up its packet on another
> physical device for actual transmission may need that (e.g: DSA, bond,
> team, more.?)
We support bonding and team already.
^ permalink raw reply
* Re: [PATCH net] bpf: one perf event close won't free bpf program attached by another perf event
From: Alexei Starovoitov @ 2017-09-21 21:53 UTC (permalink / raw)
To: Peter Zijlstra, Yonghong Song; +Cc: Steven Rostedt, daniel, netdev, kernel-team
In-Reply-To: <20170921111706.343om7252gcagco6@hirez.programming.kicks-ass.net>
On 9/21/17 4:17 AM, Peter Zijlstra wrote:
> On Wed, Sep 20, 2017 at 10:20:13PM -0700, Yonghong Song wrote:
>>> (2). trace_event_call->perf_events are per cpu data structure, that
>>> means, some filtering logic is needed to avoid the same perf_event prog
>>> is executing twice.
>>
>> What I mean here is that the trace_event_call->perf_events need to be
>> checked on ALL cpus since bpf prog should be executed regardless of
>> cpu affiliation. It is possible that the same perf_event in different
>> per_cpu bucket and hence filtering is needed to avoid the same
>> perf_event bpf_prog is executed twice.
>
> An event will only ever be on a single CPU's list at any one time IIRC.
yes, but doing for_each_cpu there is not an option. too slow.
struct trace_event_call is the only stable argument in
perf_trace_##call(), so we gotta have a pointer there for stuff
we need to run.
This patch added another annoying pointer, since it's the simplest
bugfix for stable. For net-next we're going to remove it, since
we're working on multi-prog support for kprobes/tracepoints.
(right now there is only one prog allowed and that's very limiting)
With multi-prog that bpf_prog_owner pointer will be removed and
existing 'struct bpf_prog *prog' pointer will be replaced with
something else.
> Now, hysterically perf_event_set_bpf_prog used the tracepoint crud
> because that already had bpf bits in. But it might make sense to look at
> unifying the bpf stuff across all the different event types. Have them
> all use event->prog.
it sounds good in theory, but in practice we need a separate
'stuff to run' pointer in both perf_event and trace_even_call,
since that's what being passed to overflow_handle and perf_trace_##call.
> I suspect that would break a fair bunch of bpf proglets, since the data
> access to the trace data would be completely different, but it would be
> much nicer to not have this distinction based on event type.
such things are certainly an abi.
kprobe+bpf has to see struct pt_regs
perf_event+bpf has to see struct bpf_perf_event_data and
tracepoint+bpf has to see struct foo { fields }
The fields will change every time tracepoint is changed.
That's fine.
But we cannot unify kprobe with tracepoints with perf_event prog types.
And frankly I don't see the need.
Note that in pt_regs we don't need to populate everything.
The 'optimized fprobe' we were talking about at plumbers we
would populate di,si,dx,cx,sp since most of the kprobe+bpf progs
don't care about the other regs and especially cpu flags.
So plenty of room for tweaks and optimizations.
^ permalink raw reply
* Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
From: Paweł Staszewski @ 2017-09-21 21:43 UTC (permalink / raw)
To: Florian Fainelli, Eric Dumazet
Cc: Paolo Abeni, Jesper Dangaard Brouer,
Linux Kernel Network Developers, Alexander Duyck
In-Reply-To: <6607c631-580d-825b-6205-6f6ee688ce32@gmail.com>
W dniu 2017-09-21 o 23:41, Florian Fainelli pisze:
> On 09/21/2017 02:26 PM, Paweł Staszewski wrote:
>>
>> W dniu 2017-08-15 o 11:11, Paweł Staszewski pisze:
>>> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
>>> index
>>> 5e831de3103e2f7092c7fa15534def403bc62fb4..9472de846d5c0960996261cb2843032847fa4bf7
>>> 100644
>>> --- a/net/8021q/vlan_netlink.c
>>> +++ b/net/8021q/vlan_netlink.c
>>> @@ -143,6 +143,7 @@ static int vlan_newlink(struct net *src_net,
>>> struct net_device *dev,
>>> vlan->vlan_proto = proto;
>>> vlan->vlan_id = nla_get_u16(data[IFLA_VLAN_ID]);
>>> vlan->real_dev = real_dev;
>>> + dev->priv_flags |= (real_dev->priv_flags & IFF_XMIT_DST_RELEASE);
>>> vlan->flags = VLAN_FLAG_REORDER_HDR;
>>> err = vlan_check_real_dev(real_dev, vlan->vlan_proto,
>>> vlan->vlan_id);
>> Any plans for this patch to go normal into the kernel ?
> Would not this apply to pretty much any stacked device setup though? It
> seems like any network device that just queues up its packet on another
> physical device for actual transmission may need that (e.g: DSA, bond,
> team, more.?)
Some devices libe bond have it.
Just maybee when there was first patch vlans were not taken into account.
Did not checked all :)
But I know Eric will do :)
^ permalink raw reply
* Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
From: Florian Fainelli @ 2017-09-21 21:41 UTC (permalink / raw)
To: Paweł Staszewski, Eric Dumazet
Cc: Paolo Abeni, Jesper Dangaard Brouer,
Linux Kernel Network Developers, Alexander Duyck
In-Reply-To: <5d32f5cf-ca69-1f6b-5bca-cdcd4dc414e2@itcare.pl>
On 09/21/2017 02:26 PM, Paweł Staszewski wrote:
>
>
> W dniu 2017-08-15 o 11:11, Paweł Staszewski pisze:
>> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
>> index
>> 5e831de3103e2f7092c7fa15534def403bc62fb4..9472de846d5c0960996261cb2843032847fa4bf7
>> 100644
>> --- a/net/8021q/vlan_netlink.c
>> +++ b/net/8021q/vlan_netlink.c
>> @@ -143,6 +143,7 @@ static int vlan_newlink(struct net *src_net,
>> struct net_device *dev,
>> vlan->vlan_proto = proto;
>> vlan->vlan_id = nla_get_u16(data[IFLA_VLAN_ID]);
>> vlan->real_dev = real_dev;
>> + dev->priv_flags |= (real_dev->priv_flags & IFF_XMIT_DST_RELEASE);
>> vlan->flags = VLAN_FLAG_REORDER_HDR;
>> err = vlan_check_real_dev(real_dev, vlan->vlan_proto,
>> vlan->vlan_id);
>
> Any plans for this patch to go normal into the kernel ?
Would not this apply to pretty much any stacked device setup though? It
seems like any network device that just queues up its packet on another
physical device for actual transmission may need that (e.g: DSA, bond,
team, more.?)
--
Florian
^ permalink raw reply
* Re: [PATCH 2/2] ip_tunnel: add mpls over gre encapsulation
From: Amine Kherbouche @ 2017-09-21 21:39 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, xeb, roopa, equinox
In-Reply-To: <20170921212536.GA814@electric-eye.fr.zoreil.com>
Hi Francois,
Thanks for the feedback, I'll make it for the next version.
On 21/09/2017 23:25, Francois Romieu wrote:
> Amine Kherbouche <amine.kherbouche@6wind.com> :
> [...]
>> diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
>> index 36ea2ad..060ed07 100644
>> --- a/net/mpls/af_mpls.c
>> +++ b/net/mpls/af_mpls.c
> [...]
>> @@ -39,6 +40,40 @@ static int one = 1;
>> static int label_limit = (1 << 20) - 1;
>> static int ttl_max = 255;
>>
>> +size_t ipgre_mpls_encap_hlen(struct ip_tunnel_encap *e)
>> +{
>> + return sizeof(struct mpls_shim_hdr);
>> +}
>> +
>> +int ipgre_mpls_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
>> + u8 *protocol, struct flowi4 *fl4)
>> +{
>> + return 0;
>> +}
>> +
>> +static const struct ip_tunnel_encap_ops mpls_iptun_ops = {
>> + .encap_hlen = ipgre_mpls_encap_hlen,
>> + .build_header = ipgre_mpls_build_header,
>> +};
> Nit: af_mpls.c uses tab before '=' in such places.
>
>> +
>> +int ipgre_tunnel_encap_add_mpls_ops(void)
>> +{
>> + int ret;
>> +
>> + ret = ip_tunnel_encap_add_ops(&mpls_iptun_ops, TUNNEL_ENCAP_MPLS);
> ip_tunnel_encap_add_ops is CONFIG_NET_IP_TUNNEL dependant.
>
> Afaics CONFIG_MPLS does not enforce it.
>
> [...]
>> @@ -2486,6 +2521,7 @@ static int __init mpls_init(void)
>> 0);
>> rtnl_register(PF_MPLS, RTM_GETNETCONF, mpls_netconf_get_devconf,
>> mpls_netconf_dump_devconf, 0);
>> + ipgre_tunnel_encap_add_mpls_ops();
>> err = 0;
>> out:
>> return err;
> ipgre_tunnel_encap_add_mpls_ops status return code is not checked.
>
^ permalink raw reply
* Re: net: macb: fail when there's no PHY
From: Brandon Streiff @ 2017-09-21 21:35 UTC (permalink / raw)
To: Grant Edwards, Florian Fainelli; +Cc: netdev, Brandon Streiff
In-Reply-To: <20170921203608.GB30148@grante>
> On Thu, Sep 21, 2017 at 01:05:57PM -0700, Florian Fainelli wrote:
>
>>> It looks like the macb driver still can't handle boards that don't
>>> have a PHY. Is that correct?
>>
>> Not since:
>>
>> dacdbb4dfc1a1a1378df8ebc914d4fe82259ed46 ("net: macb: add fixed-link
>> node support")
>
> Yep, it's obvious now that I've got the diff in front of me.
>
> Thanks!
>
> [I just started working with device tree for the first time yesterday,
> and I must say it's way better than the "old days" which required all
> sorts of ugly to produce a kernel that could work on two slightly
> different boards.]
>
> --
> Grant
I have a board that's in a similar boat. My workaround was to undo
portions of dacdbb4dfc1a with the following patch; this lets me still
use fixed-link and have MDIO (to configure a switch), but not require
a PHY.
There was a patch set last year by Harini Katakam ("net: macb: Add MDIO
driver for accessing multiple PHY devices") that might ultimately be a
better approach to tackling this problem, although I haven't seen any
further chatter on it.
---
drivers/net/ethernet/cadence/macb_main.c | 38 +++++++++++++++-----------------
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 1741cda..a45848e 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -564,30 +564,28 @@ static int macb_mii_init(struct macb *bp)
goto err_out_unregister_bus;
}
bp->phy_node = of_node_get(np);
+ }
- err = mdiobus_register(bp->mii_bus);
- } else {
- /* try dt phy registration */
- err = of_mdiobus_register(bp->mii_bus, np);
+ /* try dt phy registration */
+ err = of_mdiobus_register(bp->mii_bus, np);
- /* fallback to standard phy registration if no phy were
- * found during dt phy registration
- */
- if (!err && !phy_find_first(bp->mii_bus)) {
- for (i = 0; i < PHY_MAX_ADDR; i++) {
- struct phy_device *phydev;
-
- phydev = mdiobus_scan(bp->mii_bus, i);
- if (IS_ERR(phydev) &&
- PTR_ERR(phydev) != -ENODEV) {
- err = PTR_ERR(phydev);
- break;
- }
+ /* fallback to standard phy registration if no phy were
+ * found during dt phy registration
+ */
+ if (!err && !phy_find_first(bp->mii_bus)) {
+ for (i = 0; i < PHY_MAX_ADDR; i++) {
+ struct phy_device *phydev;
+
+ phydev = mdiobus_scan(bp->mii_bus, i);
+ if (IS_ERR(phydev) &&
+ PTR_ERR(phydev) != -ENODEV) {
+ err = PTR_ERR(phydev);
+ break;
}
-
- if (err)
- goto err_out_unregister_bus;
}
+
+ if (err)
+ goto err_out_unregister_bus;
}
} else {
for (i = 0; i < PHY_MAX_ADDR; i++)
--
2.1.4
^ permalink raw reply related
* Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
From: Paweł Staszewski @ 2017-09-21 21:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paolo Abeni, Jesper Dangaard Brouer,
Linux Kernel Network Developers, Alexander Duyck
In-Reply-To: <1506029642.29839.151.camel@edumazet-glaptop3.roam.corp.google.com>
W dniu 2017-09-21 o 23:34, Eric Dumazet pisze:
> On Thu, 2017-09-21 at 23:26 +0200, Paweł Staszewski wrote:
>> W dniu 2017-08-15 o 11:11, Paweł Staszewski pisze:
>>> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
>>> index
>>> 5e831de3103e2f7092c7fa15534def403bc62fb4..9472de846d5c0960996261cb2843032847fa4bf7
>>> 100644
>>> --- a/net/8021q/vlan_netlink.c
>>> +++ b/net/8021q/vlan_netlink.c
>>> @@ -143,6 +143,7 @@ static int vlan_newlink(struct net *src_net,
>>> struct net_device *dev,
>>> vlan->vlan_proto = proto;
>>> vlan->vlan_id = nla_get_u16(data[IFLA_VLAN_ID]);
>>> vlan->real_dev = real_dev;
>>> + dev->priv_flags |= (real_dev->priv_flags & IFF_XMIT_DST_RELEASE);
>>> vlan->flags = VLAN_FLAG_REORDER_HDR;
>>> err = vlan_check_real_dev(real_dev, vlan->vlan_proto,
>>> vlan->vlan_id);
>> Any plans for this patch to go normal into the kernel ?
>>
>> So far im using it for about 3 weeks on all my linux based routers - and
>> no problems.
> Yes, I was about to submit it, as I mentioned it few hours ago to you ;)
>
>
>
>
Yes i saw Your point 2) in previous emails :)
But there was no patch in previous reply for this so was thinking that
maybee too many things to do and You forgot about it :)
Thanks
Paweł
^ permalink raw reply
* Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
From: Eric Dumazet @ 2017-09-21 21:34 UTC (permalink / raw)
To: Paweł Staszewski
Cc: Paolo Abeni, Jesper Dangaard Brouer,
Linux Kernel Network Developers, Alexander Duyck
In-Reply-To: <5d32f5cf-ca69-1f6b-5bca-cdcd4dc414e2@itcare.pl>
On Thu, 2017-09-21 at 23:26 +0200, Paweł Staszewski wrote:
>
> W dniu 2017-08-15 o 11:11, Paweł Staszewski pisze:
> > diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
> > index
> > 5e831de3103e2f7092c7fa15534def403bc62fb4..9472de846d5c0960996261cb2843032847fa4bf7
> > 100644
> > --- a/net/8021q/vlan_netlink.c
> > +++ b/net/8021q/vlan_netlink.c
> > @@ -143,6 +143,7 @@ static int vlan_newlink(struct net *src_net,
> > struct net_device *dev,
> > vlan->vlan_proto = proto;
> > vlan->vlan_id = nla_get_u16(data[IFLA_VLAN_ID]);
> > vlan->real_dev = real_dev;
> > + dev->priv_flags |= (real_dev->priv_flags & IFF_XMIT_DST_RELEASE);
> > vlan->flags = VLAN_FLAG_REORDER_HDR;
> > err = vlan_check_real_dev(real_dev, vlan->vlan_proto,
> > vlan->vlan_id);
>
> Any plans for this patch to go normal into the kernel ?
>
> So far im using it for about 3 weeks on all my linux based routers - and
> no problems.
Yes, I was about to submit it, as I mentioned it few hours ago to you ;)
^ permalink raw reply
* Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
From: Paweł Staszewski @ 2017-09-21 21:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paolo Abeni, Jesper Dangaard Brouer,
Linux Kernel Network Developers, Alexander Duyck
In-Reply-To: <4b1efff7-4f91-fd78-beb8-2c7ebcf18895@itcare.pl>
W dniu 2017-08-15 o 11:11, Paweł Staszewski pisze:
> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
> index
> 5e831de3103e2f7092c7fa15534def403bc62fb4..9472de846d5c0960996261cb2843032847fa4bf7
> 100644
> --- a/net/8021q/vlan_netlink.c
> +++ b/net/8021q/vlan_netlink.c
> @@ -143,6 +143,7 @@ static int vlan_newlink(struct net *src_net,
> struct net_device *dev,
> vlan->vlan_proto = proto;
> vlan->vlan_id = nla_get_u16(data[IFLA_VLAN_ID]);
> vlan->real_dev = real_dev;
> + dev->priv_flags |= (real_dev->priv_flags & IFF_XMIT_DST_RELEASE);
> vlan->flags = VLAN_FLAG_REORDER_HDR;
> err = vlan_check_real_dev(real_dev, vlan->vlan_proto,
> vlan->vlan_id);
Any plans for this patch to go normal into the kernel ?
So far im using it for about 3 weeks on all my linux based routers - and
no problems.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox