Re: [RFC PATCH v3 00/10] an introduction of library operating system for Linux (LibOS)

Hi! Am 24.04.2015 um 10:22 schrieb Hajime Tazaki: You *really* need to shape up wrt the build process. at the moment, the implementation of libos can't automate to follow such changes in the build process. but good news is it's a trivial task to follow up the latest function. my

Re: [RFC PATCH v3 00/10] an introduction of library operating system for Linux (LibOS)

messages changes from v1: - Patch 01/11 (sysctl: make some functions unstatic to access by arch/lib): * add prefix ctl_table_ to newly publiced functions (commented by Joe Perches) - Patch 08/11 (lib: other kernel glue layer code): * significantly reduce glue codes (stubs) (commented by Richard

Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib

Am 17.04.2015 um 14:17 schrieb Christoph Lameter: On Fri, 17 Apr 2015, Hajime Tazaki wrote: add header includion for CONFIG_LIB to wrap kmalloc and co. This will bring malloc(3) based allocator used by arch/lib. Maybe add another allocator insteadl? SLLB which implements memory management

Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib

Am 17.04.2015 um 17:02 schrieb Hajime Tazaki: Hi Christoph, Richard, At Fri, 17 Apr 2015 14:44:35 +0200, Richard Weinberger wrote: Am 17.04.2015 um 14:17 schrieb Christoph Lameter: On Fri, 17 Apr 2015, Hajime Tazaki wrote: add header includion for CONFIG_LIB to wrap kmalloc and co

Re: [PATCH] lib: test_bpf: purge CPP register redefinitions

Am 22.06.2015 um 08:52 schrieb Richard Weinberger: Am 22.06.2015 um 08:05 schrieb Alexei Starovoitov: to get rid of warning you proposing to do 1k line renames?! Just add: +#undef R8 +#undef R9 +#undef R10 #define R0 BPF_REG_0 This would be also just another hack. Though

Re: [PATCH] lib: test_bpf: purge CPP register redefinitions

Am 22.06.2015 um 08:05 schrieb Alexei Starovoitov: to get rid of warning you proposing to do 1k line renames?! Just add: +#undef R8 +#undef R9 +#undef R10 #define R0 BPF_REG_0 This would be also just another hack. Though I think the better fix woud be to clean up:

Re: kmalloc panic

On Thu, May 28, 2015 at 9:21 AM, pavani pavani.muthy...@redpinesignals.com wrote: Hi Cong , Thanks for the response. Where we need to fix the bug ?I mean in the driver or kernel source code or hardware level. The more interesting question is, is this a recent and pristine kernel from

Re: [Intel-wired-lan] [PATCH 1/1] igb: Use ARRAY_SIZE instead fo sizeof(a)/sizeof(a[0])

Hi! Am 30.06.2015 um 22:16 schrieb Fujinaka, Todd: Sorry for the top-posting, but I'm provided with the tools they give me and bottom posting from Outlook just confuses email threads. Plus, this was crossposted all over creation and cc-ed to anyone with an intel address. I still would say

Re: [Intel-wired-lan] [PATCH 1/1] igb: Use ARRAY_SIZE instead fo sizeof(a)/sizeof(a[0])

On Tue, Jun 30, 2015 at 4:53 PM, Fujinaka, Todd todd.fujin...@intel.com wrote: I don't see the reason this is needed so I'm going to say NAK. Using generic functions is always better than open coded stuff. Linux's ARRAY_SIZE also makes sure that the passed variable is actually an array. --

Re: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event

On Mon, Jun 23, 2014 at 10:10 PM, David Miller wrote: > From: Haiyang Zhang > Date: Mon, 23 Jun 2014 16:09:59 + > >> So, what's the equivalent or similar command to "network restart" on SLES12? >> Could >> you update the command line for the

Re: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event

Am 30.10.2015 um 23:03 schrieb Haiyang Zhang: > > >> -Original Message- >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] >> Sent: Friday, October 30, 2015 6:56 AM >> To: Haiyang Zhang <haiya...@microsoft.com> >> Cc: Richard Weinberger &l

user controllable usermodehelper in br_stp_if.c

Hi! By spawning new network and user namesapces an unprivileged user is able to execute /sbin/bridge-stp within the initial mount namespace with global root rights. While this cannot directly be used to break out of a container or gain global root rights it could be used by exploit writers as

Re: bridge-utils: wrong sysfs path odds

Am 25.11.2015 um 01:37 schrieb Stephen Hemminger: > On Wed, 25 Nov 2015 01:24:47 +0100 > Richard Weinberger <rich...@nod.at> wrote: > >> Am 25.11.2015 um 01:15 schrieb Richard Weinberger: >>> Hi! >>> >>> Today I was hunting down an issue where &

bridge-utils: wrong sysfs path odds

Hi! Today I was hunting down an issue where "brctl stp br0 off" always failed on mips64be with n32 userland. It turned out that the ioctl(fd, SIOCDEVPRIVATE, ) with BRCTL_SET_BRIDGE_STP_STATE returned -EOPNOTSUPP. First I thought that this is a plain ABI issue on mips as in old_dev_ioctl() the

Re: bridge-utils: wrong sysfs path odds

Am 25.11.2015 um 23:38 schrieb Florian Fainelli: > On 25/11/15 01:21, Richard Weinberger wrote: >> Am 25.11.2015 um 01:37 schrieb Stephen Hemminger: >>> On Wed, 25 Nov 2015 01:24:47 +0100 >>> Richard Weinberger <rich...@nod.at> wrote: >>> >>>

Re: bridge-utils: wrong sysfs path odds

Hi! Am 25.11.2015 um 23:30 schrieb Santiago Garcia Mantinan: > Hi! > >> Ask Debian maintainer to send his patches, I don't go patch hunting. > > > While looking what other distros do I came across this patch: > >

Re: bridge-utils: wrong sysfs path odds

Am 25.11.2015 um 01:37 schrieb Stephen Hemminger: > On Wed, 25 Nov 2015 01:24:47 +0100 > Richard Weinberger <rich...@nod.at> wrote: > >> Am 25.11.2015 um 01:15 schrieb Richard Weinberger: >>> Hi! >>> >>> Today I was hunting down an issue where &

Re: bridge-utils: wrong sysfs path odds

Am 25.11.2015 um 01:15 schrieb Richard Weinberger: > Hi! > > Today I was hunting down an issue where "brctl stp br0 off" > always failed on mips64be with n32 userland. > > It turned out that the ioctl(fd, SIOCDEVPRIVATE, ) with > BRCTL_SET_BRIDGE_STP_STATE &g

Re: [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace

Am 30.11.2015 um 22:38 schrieb Eric W. Biederman: > > There is no defined mechanism to pass network namespace information > into /sbin/bridge-stp therefore don't even try to invoke it except > for bridge devices in the initial network namespace. > > It is possible for unprivileged users to cause

Re: user controllable usermodehelper in br_stp_if.c

Am 30.11.2015 um 21:14 schrieb Kees Cook: > On Sun, Nov 29, 2015 at 2:43 PM, Richard Weinberger <rich...@nod.at> wrote: >> Hi! >> >> By spawning new network and user namesapces an unprivileged user >> is able to execute /sbin/bridge-stp within the initial mount nam

Re: [PATCH] net:ppp: replace too strict capability restriction on opening /dev/ppp

ed container. > > Cc: Hannes Frederic Sowa <han...@stressinduktion.org> > Cc: Richard Weinberger <richard.weinber...@gmail.com> > Cc: Guillaume Nault <g.na...@alphalink.fr> > Cc: Miao Wang <shankerwangm...@gmail.com> > Signed-off-by: Miao Wang <miao.w...@tu

Re: [PATCH] net:ppp: replace too strict capability restriction on opening /dev/ppp

Am 19.06.2016 um 12:36 schrieb Shanker Wang: > >> 在 2016年6月19日，12:13，Richard Weinberger <rich...@nod.at> 写道： >> >> Am 19.06.2016 um 07:21 schrieb Shanker Wang: >>> This patch removes the check for CAP_NET_ADMIN in the initial namespace >>> when opening

Re: [PATCH] net:ppp: replace too strict capability restriction on opening /dev/ppp

Am 20.06.2016 um 07:02 schrieb Andi Kleen: > Shanker Wang writes: > >> This patch removes the check for CAP_NET_ADMIN in the initial namespace >> when opening /dev/open. Instead, CAP_NET_ADMIN is checked in the user >> namespace the net namespace was created so that

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

Am 23.06.2016 um 09:40 schrieb David Miller: > From: Richard Weinberger <richard.weinber...@gmail.com> > Date: Thu, 23 Jun 2016 00:15:04 +0200 > >> On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert <t...@herbertland.com> wrote: >>> Transports over UDP is intended to

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert wrote: > Transports over UDP is intended to encapsulate TCP and other transport > protocols directly and securely in UDP. > > The goal of this work is twofold: > > 1) Allow applications to run their own transport layer stack

Re: Computer fails to resume from suspend unless I rmmod jme before initiating the suspend

Diego, On Sun, Feb 14, 2016 at 9:16 PM, Diego Viola wrote: > Can someone please help? as I wrote on IRC, please wait at least a full week. -- Thanks, //richard

[PATCH 13/22] net: Fix dependencies for !HAS_IOMEM archs

Not every arch has io memory. So, unbreak the build by fixing the dependencies. Signed-off-by: Richard Weinberger <rich...@nod.at> --- drivers/net/ethernet/ezchip/Kconfig | 1 + drivers/net/phy/Kconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/net/ethernet/

Re: [PATCH -next 0/5] netlink: remove mmapped netlink support

On Thu, Feb 18, 2016 at 3:03 PM, Florian Westphal wrote: > As discussed during netconf 2016 in Seville, this series removes > CONFIG_NETLINK_MMAP. Sorry for hopping in so^Wtoo late. I always thought mmaped netlink is the way to go for userspace packet processing. Sure, the

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault wrote: > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: >> static int ppp_open(struct inode *inode, struct file *file) >> { >> /* >>* This could (should?) be enforced by the permissions on

Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM

Sargun, On Thu, Aug 4, 2016 at 9:11 AM, Sargun Dhillon wrote: > I distributed this patchset to linux-security-mod...@vger.kernel.org earlier, > but based on the fact that the archive is down, and this is a fairly > broad-sweeping proposal, I figured I'd grow the audience a

Re: [RFC] WireGuard: next generation secure network tunnel

On Tue, Jun 28, 2016 at 4:49 PM, Jason A. Donenfeld wrote: > WireGuard acts as a virtual interface, doing layer 3 IP tunneling, > addable with "ip link add dev wg0 type wireguard". You can set the > interface's local IP and routes using the usual ip-address and So every logical

Re: [RFC] WireGuard: next generation secure network tunnel

Jason, Am 01.07.2016 um 16:25 schrieb Jason A. Donenfeld: > Hi Richard, > > On Fri, Jul 1, 2016 at 1:42 PM, Richard Weinberger > <richard.weinber...@gmail.com> wrote: >> So every logical tunnel will allocate a new net device? >> Doesn't this scale badly? I have i

Re: [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*()

Michal, Am 05.04.2017 um 13:31 schrieb Michal Hocko: > On Wed 05-04-17 09:47:00, Vlastimil Babka wrote: >> Nandsim has own functions set_memalloc() and clear_memalloc() for robust >> setting and clearing of PF_MEMALLOC. Replace them by the new generic helpers. >> No functional change. > > This

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Florian, Am 01.07.2017 um 12:35 schrieb Florian Westphal: >>> Perhaps we can place that in a new extension (its not needed in any >>> fastpath ops)? >> >> To get rid of the infoleak we have to re-introduce the id field in struct >> nf_conn >> and struct nf_conntrack_expect. > > Why will this

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Florian, Am 30.06.2017 um 21:35 schrieb Florian Westphal: > Richard Weinberger <rich...@nod.at> wrote: >> Hi! >> >> I noticed that nf_conntrack leaks kernel addresses, it uses the memory >> address >> as identifier used for generating conntrack and e

nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Hi! I noticed that nf_conntrack leaks kernel addresses, it uses the memory address as identifier used for generating conntrack and expect ids.. Since these ids are also visible to unprivileged users via network namespaces I suggest reverting these commits: commit

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Florian, Am 30.06.2017 um 21:55 schrieb Florian Westphal: >>> Why not use a hash of the address? >> >> Would also work. Or xor it with a random number. >> >> On the other hand, for user space it would be more useful when the conntrack >> id >> does not repeat that often. That's why I favor the

Re: [PATCH v3 net-next 0/4] kernel TLS

Dave, On Wed, Jun 14, 2017 at 8:36 PM, Dave Watson wrote: > Documentation/networking/tls.txt | 135 +++ > MAINTAINERS| 10 + > include/linux/socket.h | 1 + > include/net/inet_connection_sock.h | 4 + > include/net/tcp.h

Re: [PATCH] bpf: devmap: Check attr->max_entries more carefully

Am Montag, 16. Oktober 2017, 00:00:20 CEST schrieb Richard Weinberger: > max_entries is user controlled and used as input for __alloc_percpu(). > This function expects that the allocation size is a power of two and > less than PCPU_MIN_UNIT_SIZE. > Otherwise a WARN() is triggered.

[PATCH] bpf: devmap: Check attr->max_entries more carefully

: Shankara Pailoor <sp3...@columbia.edu> Reported-by: syzkaller <syzkal...@googlegroups.com> Signed-off-by: Richard Weinberger <rich...@nod.at> --- kernel/bpf/devmap.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/devmap.c b/kernel/bpf

[PATCH 2/3] bpf: Remove dead variable

task is never used in bpf_get_current_uid_gid(), kill it. Signed-off-by: Richard Weinberger <rich...@nod.at> --- kernel/bpf/helpers.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index e8845adcd15e..511c9d522cfc 100644 --- a/kernel/bpf/hel

[PATCH 3/3] bpf: Make sure that ->comm does not change under us.

Sadly we cannot use get_task_comm() since bpf_get_current_comm() allows truncation. Signed-off-by: Richard Weinberger <rich...@nod.at> --- kernel/bpf/helpers.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index 511c9d522cfc..4b042b

[PATCH 1/3] bpf: Don't check for current being NULL

current is never NULL. Signed-off-by: Richard Weinberger <rich...@nod.at> --- kernel/bpf/helpers.c | 12 1 file changed, 12 deletions(-) diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index 3d24e238221e..e8845adcd15e 100644 --- a/kernel/bpf/helpers.c +++ b/kern

Re: [PATCH 1/3] bpf: Don't check for current being NULL

Alexei, Am Dienstag, 17. Oktober 2017, 00:06:08 CEST schrieb Alexei Starovoitov: > On Mon, Oct 16, 2017 at 11:18 AM, Richard Weinberger <rich...@nod.at> wrote: > > current is never NULL. > > > > Signed-off-by: Richard Weinberger <rich...@nod.at> > >

Re: [PATCH 3/3] bpf: Make sure that ->comm does not change under us.

Am Montag, 16. Oktober 2017, 22:50:43 CEST schrieb Daniel Borkmann: > > struct task_struct *task = current; > > > > + task_lock(task); > > > > strncpy(buf, task->comm, size); > > > > + task_unlock(task); > > Wouldn't this potentially lead to a deadlock? E.g. you attach yourself >

Re: [PATCH 3/3] bpf: Make sure that ->comm does not change under us.

Am Montag, 16. Oktober 2017, 23:02:06 CEST schrieb Daniel Borkmann: > On 10/16/2017 10:55 PM, Richard Weinberger wrote: > > Am Montag, 16. Oktober 2017, 22:50:43 CEST schrieb Daniel Borkmann: > >>> struct task_struct *task = current; > >

Re: [PATCH 2/3] bpf: Remove dead variable

Am Montag, 16. Oktober 2017, 20:54:36 CEST schrieb Daniel Borkmann: > On 10/16/2017 08:18 PM, Richard Weinberger wrote: > > task is never used in bpf_get_current_uid_gid(), kill it. > > > > Signed-off-by: Richard Weinberger <rich...@nod.at> > > --- > > &

Re: [PATCH 2/3] bpf: Remove dead variable

Am Montag, 16. Oktober 2017, 21:11:47 CEST schrieb Daniel Borkmann: > > I can squash it into 1/3, I kept it that way because > > even without 1/3 this variable is unused. > > Hmm, the helper looks like the below. In patch 1/3 you removed > the 'if (unlikely(!task))' test where the variable was

WARNING: kernel stack frame pointer at ffff880156a5fea0 in bash:2103 has bad value 00007ffec7d87e50

Hi! While playing with bcc's opensnoop tool on Linux 4.14-rc2 I managed to trigger this splat: [ 297.629773] WARNING: kernel stack frame pointer at 880156a5fea0 in bash:2103 has bad value 7ffec7d87e50 [ 297.629777] unwind stack type:0 next_sp: (null) mask:0x6 graph_idx:0 [

Re: WARNING: kernel stack frame pointer at ffff880156a5fea0 in bash:2103 has bad value 00007ffec7d87e50

Alexei, CC'ing Josh and Ingo. Am Dienstag, 26. September 2017, 06:09:02 CEST schrieb Alexei Starovoitov: > On Mon, Sep 25, 2017 at 11:23:31PM +0200, Richard Weinberger wrote: > > Hi! > > > > While playing with bcc's opensnoop tool on Linux 4.14-rc2 I managed to &

Re: WARNING: kernel stack frame pointer at ffff880156a5fea0 in bash:2103 has bad value 00007ffec7d87e50

Josh, Am Mittwoch, 27. September 2017, 16:14:30 CEST schrieb Josh Poimboeuf: > On Wed, Sep 27, 2017 at 08:51:22AM +0200, Richard Weinberger wrote: > > Am Mittwoch, 27. September 2017, 00:42:46 CEST schrieb Josh Poimboeuf: > > > > Here is another variant of the warning, it

Re: WARNING: kernel stack frame pointer at ffff880156a5fea0 in bash:2103 has bad value 00007ffec7d87e50

Am Mittwoch, 27. September 2017, 00:42:46 CEST schrieb Josh Poimboeuf: > > Here is another variant of the warning, it matches the attached .config: > I can take a look at it. Unfortunately, for these types of issues I > often need the vmlinux file to be able to make sense of the unwinder > dump.

Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)

Randy, Am Montag, 11. Dezember 2017, 03:42:12 CET schrieb Randy Dunlap: > On 12/10/2017 06:08 PM, Linus Torvalds wrote: > > Another week, another rc. > > um (uml) won't build on i386 or x86_64: > > CC init/main.o > In file included from ../include/linux/perf_event.h:18:0, >

Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)

Am Montag, 11. Dezember 2017, 18:27:40 CET schrieb Randy Dunlap: > On 12/11/2017 02:19 AM, Daniel Borkmann wrote: > > Hi Randy, hi Richard, [ +Hendrik for c895f6f703ad7dd2f ] > > > > On 12/11/2017 09:32 AM, Richard Weinberger wrote: > >> Randy, > >> >

Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)

Am Montag, 11. Dezember 2017, 11:19:54 CET schrieb Daniel Borkmann: > Hi Randy, hi Richard, [ +Hendrik for c895f6f703ad7dd2f ] > > On 12/11/2017 09:32 AM, Richard Weinberger wrote: > > Randy, > > > > Am Montag, 11. Dezember 2017, 03:42:12 CET schrieb Randy Dunlap:

Re: [PATCH bpf 2/3] bpf: fix build issues on um due to mising bpf_perf_event.h

api for BPF_PROG_TYPE_PERF_EVENT > program type") Reported-by: Randy Dunlap <rdun...@infradead.org> > Suggested-by: Richard Weinberger <rich...@sigma-star.at> > Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> > Tested-by: Randy Dunlap <rdun...@infradead.org

Re: [PATCH 3/5] mtd: Stop assuming mtd_erase() is asynchronous

ns > failure. > > Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com> Reviewed-by: Richard Weinberger <rich...@nod.at> Thanks, //richard

Re: [PATCH 5/5] mtd: Stop updating erase_info->state and calling mtd_erase_callback()

ck() calls and all > erase_info->state assignments. While at it, get rid of the > erase_info->state field, all MTD_ERASE_XXX definitions and the > mtd_erase_callback() function. > > Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com> Reviewed-by: Richard Weinberger <rich...@nod.at> Thanks, //richard

Re: [PATCH 4/5] mtd: Unconditionally update ->fail_addr and ->addr in part_erase()

e_info->mtd field which was only > needed to let mtd_erase_callback() get the partition device back. > > Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com> Reviewed-by: Richard Weinberger <rich...@nod.at> Thanks, //richard

Re: [PATCH 2/5] mtd: Get rid of unused fields in struct erase_info

; > u_char state; > - struct erase_info *next; > }; > > struct mtd_erase_region_info { Reviewed-by: Richard Weinberger <rich...@nod.at> Thanks, //richard

Re: [PATCH 1/5] mtd: Initialize ->fail_addr early in mtd_erase()

P; > > @@ -961,7 +963,6 @@ int mtd_erase(struct mtd_info *mtd, struct erase_info > *instr) if (!(mtd->flags & MTD_WRITEABLE)) > return -EROFS; > > - instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN; > if (!instr->len) { > inst

Re: [PATCH] net: hns: use put_device() if device_register fail

On Mon, Mar 12, 2018 at 5:27 PM, arvindY wrote: > > > On Monday 12 March 2018 08:13 PM, David Miller wrote: >> >> From: Arvind Yadav >> Date: Fri, 9 Mar 2018 16:11:17 +0530 >> >>> if device_register() returned an error! Always use