Re: siginfo pid not populated from ptrace?

2018-12-06 Thread Eric W. Biederman
Kees Cook writes: > On Thu, Dec 6, 2018 at 1:11 PM Eric W. Biederman > wrote: >> >> Tycho Andersen writes: >> >> > On Thu, Dec 06, 2018 at 10:48:39AM -0800, Linus Torvalds wrote: >> >> On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman >>

Re: [PATCH v4] signal: add taskfd_send_signal() syscall

2018-12-06 Thread Eric W. Biederman
Daniel Colascione writes: > On Thu, Dec 6, 2018 at 12:29 PM Eric W. Biederman > wrote: >> Christian Brauner writes: >> >> > [1]: You cannot replicate certain aspects of kill *yet*. We have >> > established this before. If we want process group support late

Re: [PATCH v4] signal: add taskfd_send_signal() syscall

2018-12-06 Thread Eric W. Biederman
s parameter or is the width of the target depending on the flags. That is fundamental to how the system call and it's extensions work. That is fundamental to my review. Until that is decided. Nacked-by: "Eric W. Biederman" There are a lot of fundamental maintenance issues and you

Re: siginfo pid not populated from ptrace?

2018-12-06 Thread Eric W. Biederman
Tycho Andersen writes: > On Thu, Dec 06, 2018 at 10:48:39AM -0800, Linus Torvalds wrote: >> On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman >> wrote: >> > >> > We have in the past had ptrace users that weren't just about debugging >> > so I

Re: [PATCH v4] signal: add taskfd_send_signal() syscall

2018-12-06 Thread Eric W. Biederman
Christian Brauner writes: > On Thu, Dec 06, 2018 at 01:17:24PM -0600, Eric W. Biederman wrote: >> Christian Brauner writes: >> >> > On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote: >> >>Christian Brauner writes: >> >&g

Re: [PATCH v4] signal: add taskfd_send_signal() syscall

2018-12-06 Thread Eric W. Biederman
Christian Brauner writes: > On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote: >>Christian Brauner writes: >> >>> The kill() syscall operates on process identifiers (pid). After a >>process >>> has exited its pid can be reused by another process. If a caller >>sends a >>>

Re: [PATCH v4] signal: add taskfd_send_signal() syscall

2018-12-06 Thread Eric W. Biederman
Daniel Colascione writes: > On Thu, Dec 6, 2018 at 7:02 AM Eric W. Biederman > wrote: >> >> Christian Brauner writes: >> >> > The kill() syscall operates on process identifiers (pid). After a process >> > has exited its pid can be reused by anothe

Re: [PATCH v4] signal: add taskfd_send_signal() syscall

2018-12-06 Thread Eric W. Biederman
ml/20181121213946.ga10...@mail.hallyn.com/ > [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/ > [7]: > https://lore.kernel.org/lkml/36323361-90bd-41af-ab5b-ee0d7ba02...@amacapital.net/ > [8]: https://lore.kernel.org/lkml/87tvjxp8pc@xmission.com/ > [9]: h

Re: siginfo pid not populated from ptrace?

2018-12-06 Thread Eric W. Biederman
Kees Cook writes: > On Sat, Dec 1, 2018 at 7:04 AM Eric W. Biederman > wrote: >> >> Kees Cook writes: >> >> > On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman >> > wrote: >> >> >> >> Kees Cook writes: >&g

Re: [PATCH v4] signal: add taskfd_send_signal() syscall

2018-12-06 Thread Eric W. Biederman
Florian Weimer writes: > * Eric W. Biederman: > >> Floriam are you seeing a problem with this behavior or the way Christian >> was describing it? > > My hope is that you could use taskfd_send_signal one day to send a > signal to a process which you *known* (based

Re: [PATCH v4] signal: add taskfd_send_signal() syscall

2018-12-06 Thread Eric W. Biederman
Florian Weimer writes: > * Jürg Billeter: > >> On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote: >>> * Christian Brauner: >>> >>> > /* zombies */ >>> > Zombies can be signaled just as any other process. No special error will >>> > be >>> > reported since a zombie state is an unreliable

Re: [PATCH v3] signal: add procfd_send_signal() syscall

2018-12-05 Thread Eric W. Biederman
@brauner.io/ > [4]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru...@brauner.io/ > [5]: https://lore.kernel.org/lkml/20181121213946.ga10...@mail.hallyn.com/ > [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/ > [7]: > https://lore.kernel.or

Re: [PATCH v3] signal: add procfd_send_signal() syscall

2018-12-05 Thread Eric W. Biederman
@brauner.io/ > [4]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru...@brauner.io/ > [5]: https://lore.kernel.org/lkml/20181121213946.ga10...@mail.hallyn.com/ > [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/ > [7]: > https://lore.kernel.or

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-12-01 Thread Eric W. Biederman
Andy Lutomirski writes: >> On Dec 1, 2018, at 7:28 AM, Eric W. Biederman wrote: >> >> >> It just occurs to me that the simple way to implement >> procfd_sigqueueinfo info is like: >> >> int copy_siginfo_from_user_any(kernel_siginfo_t *info, sigi

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-12-01 Thread Eric W. Biederman
It just occurs to me that the simple way to implement procfd_sigqueueinfo info is like: int copy_siginfo_from_user_any(kernel_siginfo_t *info, siginfo_t *uinfo) { #ifdef CONFIG_COMPAT if (in_compat_syscall) return copy_siginfo_from_user32(info, uinfo); #endif

Re: siginfo pid not populated from ptrace?

2018-12-01 Thread Eric W. Biederman
Kees Cook writes: > On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman > wrote: >> >> Kees Cook writes: >> >> > On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook wrote: >> >> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote: >> >>> On

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-12-01 Thread Eric W. Biederman
Arnd Bergmann writes: > On Fri, Nov 30, 2018 at 7:56 AM Christian Brauner > wrote: >> On Thu, Nov 29, 2018 at 11:13:57PM -0600, Eric W. Biederman wrote: >> > Arnd Bergmann writes: >> > > On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski >> > >

Re: [PATCH] fs: Make /proc/sys inodes be owned by global root.

2018-12-01 Thread Eric W. Biederman
Radoslaw Burny writes: > On Tue, Nov 27, 2018 at 6:29 AM Eric W. Biederman > wrote: > > Luis Chamberlain writes: > > > On Mon, Nov 26, 2018 at 06:26:07PM +0100, Radoslaw Burny wrote: > >> Due to a recent commit (d151ddc00498 - fs: Update i_[ug]id_(read|writ

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-12-01 Thread Eric W. Biederman
Andy Lutomirski writes: > On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote: >> siginfo_t as it is now still has a number of other downsides, and Andy in >> particular didn't like the idea of having three new variants on x86 >> (depending on how you count). His alternative suggestion of

Re: dcache_readdir NULL inode oops

2018-11-30 Thread Eric W. Biederman
"gre...@linuxfoundation.org" writes: > Adding Eric as he touched this code last :) > > On Thu, Nov 29, 2018 at 07:25:48PM +, Jan Glauber wrote: >> On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote: >> > I spent some more time looking at this today... >> > >> > On Fri, Nov 23, 2018

Re: [PATCH] fs: Make /proc/sys inodes be owned by global root.

2018-11-30 Thread Eric W. Biederman
Luis Chamberlain writes: > On Mon, Nov 26, 2018 at 11:29:40PM -0600, Eric W. Biederman wrote: >> Luis Chamberlain writes: >> > Thanks for the description of how to run into the issue described but >> > is there also a practical use case today where this is happen

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-11-29 Thread Eric W. Biederman
Arnd Bergmann writes: > On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote: >> > On Nov 29, 2018, at 11:55 AM, Christian Brauner >> > wrote: >> >> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote: >> >>> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner >> >>> wrote: >>

Re: [PATCH] prctl: add PR_{GET,SET}_KILL_DESCENDANTS_ON_EXIT

2018-11-28 Thread Eric W. Biederman
Oleg Nesterov writes: > On 11/27, Jürg Billeter wrote: >> >> @@ -704,6 +713,9 @@ static void exit_notify(struct task_struct *tsk, int >> group_dead) >> struct task_struct *p, *n; >> LIST_HEAD(dead); >> >> +if (group_dead && tsk->signal->kill_descendants_on_exit) >> +

Re: siginfo pid not populated from ptrace?

2018-11-27 Thread Eric W. Biederman
; info._sifields._kill.si_pid (0) >>> global.syscall_restart: Test failed at step #22 >> >> This fails every time for me -- is it still racey for you? >> >> I'm attempting a bisect, hoping it doesn't _become_ racey for me. ;) > > This bisect to here for me: >

Re: BUG: corrupted list in freeary

2018-11-27 Thread Eric W. Biederman
syzbot writes: > Hello, > > syzbot found the following crash on: > > HEAD commit:e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=10d3e6a340 > kernel config:

Re: [PATCH] fs: Make /proc/sys inodes be owned by global root.

2018-11-26 Thread Eric W. Biederman
_gid that is correct in the general case. That default value is not corect for sysctl, because proc is weird. As the sysctl permission check in test_perm are all against GLOBAL_ROOT_UID and GLOBAL_ROOT_GID we did not notice that i_uid and i_gid were being set wrong. So all this patch does

Re: [PATCH v1 2/2] signal: add procfd_signal() syscall

2018-11-19 Thread Eric W. Biederman
Daniel Colascione writes: > On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner > wrote: >> >> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote: >> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner >> > wrote: >> > > That can be done without a loop by comparing the level

Re: [PATCH v1 2/2] signal: add procfd_signal() syscall

2018-11-19 Thread Eric W. Biederman
Christian Brauner writes: > On Mon, Nov 19, 2018 at 07:59:24AM -0800, Daniel Colascione wrote: >> You never addressed my comment on the previous patch about your use of > > Sorry, that thread exploded so quickly that I might have missed it. > >> private_data here. Why can't you use the struct

Re: [PATCH] proc: allow killing processes via file descriptors (Larger pids)

2018-11-19 Thread Eric W. Biederman
Dmitry Safonov <0x7f454...@gmail.com> writes: > > So, I just wanted to gently remind about procfs with netlink socket[1]. > It seems to me that whenever you receive() pid information, you > can request some uniq 64(?) bit number and kill the process using it. > Whenever uniqueness of 64-bit number

Re: [PATCH] proc: allow killing processes via file descriptors

2018-11-18 Thread Eric W. Biederman
Daniel Colascione writes: > On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski wrote: >> On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione wrote: >>> >>> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote: >>> > On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione >>> > wrote: >>> >> >>> >>

Re: siginfo pid not populated from ptrace?

2018-11-12 Thread Eric W. Biederman
Tycho Andersen writes: > On Mon, Nov 12, 2018 at 12:30:25PM -0600, Eric W. Biederman wrote: >> Tycho Andersen writes: >> >> > Hi Oleg, >> > >> > I've been running some tests on my seccomp series, and in one of the >>

Re: siginfo pid not populated from ptrace?

2018-11-12 Thread Eric W. Biederman
Tycho Andersen writes: > Hi Oleg, > > I've been running some tests on my seccomp series, and in one of the > tests on v4.20-rc2, I noticed, > > [ RUN ] global.syscall_restart > seccomp_bpf.c:2784:global.syscall_restart:Expected getpid() (1492) == > info._sifields._kill.si_pid (0) >

[GIT PULL] namespace fix for v4.20-rc3

2018-11-12 Thread Eric W. Biederman
Linus, Please pull the for-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus HEAD: 1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00 mnt: fix __detach_mounts infinite loop Benjamin Coddington noticed an unkillable busy loop in

Re: [git pull] mount API series

2018-11-11 Thread Eric W. Biederman
Steven Whitehouse writes: > Hi, > > > On 31/10/18 15:38, Eric W. Biederman wrote: >> Al Viro writes: >> >>> mount API series from David Howells. Last cycle's objections >>> had been of the "I'd do it differently" variety and wi

Re: [PATCH v3] Implement /proc/pid/kill

2018-11-11 Thread Eric W. Biederman
David Laight writes: > From: Daniel Colascione >> Sent: 31 October 2018 19:33 > ... >> You can't do it today with kill. The idea that keeping a open file >> descriptor to a /proc/pid or a file within it prevents PID reuse is >> widespread, but incorrect. > > Is there a real good reason why that

[GIT PULL] namespace fixes for v4.20-rc2

2018-11-10 Thread Eric W. Biederman
correct I have spot tested these changes as well and in my testing the fixes are working. I have let these changes sit on my branch for a few days as well and none of the automated testing has found any problems either. Eric W. Biederman (3): mount: Retest MNT_LOCKED in do_umount mount

Re: x86_64 INIT/SIPI Bug

2018-11-08 Thread Eric W. Biederman
Rian Quinn writes: > I apologize upfront if this is the wrong place to post this, pretty new to > this. > > We are working on the Bareflank Hypervisor (www.bareflank.org), and we > are passing through the INIT/SIPI process (similar to how a VMX > rootkit from EFI might boot the OS) and we

Re: [PATCH v6 0/1] ns: introduce binfmt_misc namespace

2018-11-01 Thread Eric W. Biederman
Laurent Vivier writes: > On 01/11/2018 04:51, Jann Horn wrote: >> On Thu, Nov 1, 2018 at 3:59 AM James Bottomley >> wrote: >>> >>> On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote: Hi, Any comment on this last version? Any chance to be merged? >>> >>> I've got a

Re: [git pull] mount API series

2018-10-31 Thread Eric W. Biederman
ebied...@xmission.com (Eric W. Biederman) writes: > I am going to stop there. I believe there are more issues in the code. > I am relieved that I am not seeing the loss of some of the security > hooks that I thought I saw last time I looked at the code. Bah. Now I see the missing secu

Re: [git pull] mount API series

2018-10-31 Thread Eric W. Biederman
Al Viro writes: > mount API series from David Howells. Last cycle's objections > had been of the "I'd do it differently" variety and with no such > differently done variants having ever materialized over several > cycles... Absolutely not. My objections fundamentally is that I can find

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Eric W. Biederman
Christian Brauner writes: > On Tue, Oct 30, 2018 at 12:12 PM Daniel Colascione wrote: >> >> On Tue, Oct 30, 2018 at 11:04 AM, Christian Brauner >> wrote: >> > On Tue, Oct 30, 2018 at 11:48 AM Daniel Colascione >> > wrote: >> >> >> >> Why not? >> >> >> >> Does your proposed API allow for a

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Eric W. Biederman
Aleksa Sarai writes: > On 2018-10-29, Daniel Colascione wrote: >> Add a simple proc-based kill interface. To use /proc/pid/kill, just >> write the signal number in base-10 ASCII to the kill file of the >> process to be killed: for example, 'echo 9 > /proc/$$/kill'. >> >> Semantically,

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Eric W. Biederman
Daniel Colascione writes: > Add a simple proc-based kill interface. To use /proc/pid/kill, just > write the signal number in base-10 ASCII to the kill file of the > process to be killed: for example, 'echo 9 > /proc/$$/kill'. > > Semantically, /proc/pid/kill works like kill(2), except that the >

Re: [PATCH v2] proc: use ns_capable instead of capable for timerslack_ns

2018-10-30 Thread Eric W. Biederman
s controlled by CAP_SYS_NICE inside a > namespace, it should also be able to adjust timerslack_ns. Acked-by: "Eric W. Biederman" I don't see any fundamental probess with how the processes user namespace is being accessed. You can race with setns and that may result in a descendent user name

Re: [RFC 00/20] ns: Introduce Time Namespace

2018-10-29 Thread Eric W. Biederman
Thomas Gleixner writes: > Andrei, > > On Sat, 20 Oct 2018, Andrei Vagin wrote: >> When a container is migrated to another host, we have to restore its >> monotonic and boottime clocks, but we still expect that the container >> will continue using the host real-time clock. >> >> Before stating

Re: [PATCH v2] kernel/signal: Signal-based pre-coredump notification

2018-10-25 Thread Eric W. Biederman
Jann Horn writes: > On Wed, Oct 24, 2018 at 3:30 PM Eric W. Biederman > wrote: >> Enke Chen writes: >> > For simplicity and consistency, this patch provides an implementation >> > for signal-based fault notification prior to the coredump of a child >

Re: [PATCH] proc: use ns_capable instead of capable for timerslack_ns

2018-10-25 Thread Eric W. Biederman
bmgor...@google.com writes: > From: Benjamin Gordon > > Access to timerslack_ns is controlled by a process having CAP_SYS_NICE > in its effective capability set, but the current check looks in the root > namespace instead of the process' user namespace. Since a process is > allowed to do other

Re: [PATCH] ARM: mm: Facilitate debugging CONFIG_KUSER_HELPERS disabled

2018-10-25 Thread Eric W. Biederman
Florian Fainelli writes: > Some software such as perf makes unconditional use of the special > [vectors] page which is only provided when CONFIG_KUSER_HELPERS is > enabled in the kernel. > > Facilitate the debugging of such situations by printing a debug message > to the kernel log showing the

Re: [PATCH v2] kernel/signal: Signal-based pre-coredump notification

2018-10-25 Thread Eric W. Biederman
Enke Chen writes: > Hi, Eric: > > Thanks for your comments. Please see my replies inline. > > On 10/24/18 6:29 AM, Eric W. Biederman wrote: >> Enke Chen writes: >> >>> For simplicity and consistency, this patch provides an implementation >>&

Re: [PATCH v2] kernel/signal: Signal-based pre-coredump notification

2018-10-24 Thread Eric W. Biederman
Enke Chen writes: > For simplicity and consistency, this patch provides an implementation > for signal-based fault notification prior to the coredump of a child > process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can > be used by an application to express its interest and to

[GIT PULL] siginfo updates for 4.20-rc1

2018-10-22 Thread Eric W. Biederman
ves a conflict from removing a unnecessary pkey parameter on the siginfo side and a some small refactoring on the x86 side. Eric W. Biederman (80): signal: Always ignore SIGKILL and SIGSTOP sent to the global init signal: Properly deliver SIGILL from uprobes signal: Properly deli

Re: Interrupts, smp_load_acquire(), smp_store_release(), etc.

2018-10-22 Thread Eric W. Biederman
"Paul E. McKenney" writes: > On Sat, Oct 20, 2018 at 04:18:37PM -0400, Alan Stern wrote: >> On Sat, 20 Oct 2018, Paul E. McKenney wrote: >> >> > The second (informal) litmus test has a more interesting Linux-kernel >> > counterpart: >> > >> >void t1_interrupt(void) >> >{ >> >

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

2018-10-21 Thread Eric W. Biederman
David Howells writes: > From: Al Viro > > Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be > attached by move_mount(2). > > If by the time of final fput() of OPEN_TREE_CLONE-opened file its tree is > not detached anymore, it won't be dissolved. move_mount(2) is adjusted >

Re: [PATCH 01/34] vfs: syscall: Add open_tree(2) to reference or clone a mount [ver #12]

2018-10-21 Thread Eric W. Biederman
David Howells writes: > From: Al Viro > > open_tree(dfd, pathname, flags) > > Returns an O_PATH-opened file descriptor or an error. > dfd and pathname specify the location to open, in usual > fashion (see e.g. fstatat(2)). flags should be an OR of > some of the following: > *

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

2018-10-17 Thread Eric W. Biederman
David Howells writes: > Eric W. Biederman wrote: > >> Davids check will work for bind mounts as well. It just won't work it >> just won't work for files or subdirectories of some mountpoint. > > Bind mounts have to be done with open_tree() and move_mount(). Yo

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

2018-10-17 Thread Eric W. Biederman
Alan Jenkins writes: > On 17/10/2018 14:20, David Howells wrote: >> David Howells wrote: >> >>> I should probably check that the picked point is actually a mountpoint. >> The root of the mount object at the path specified, that is, perhaps with >> something like the attached. >> >> David > > >

Re: [PATCH v3 1/2] sysctl: handle overflow in proc_get_long

2018-10-16 Thread Eric W. Biederman
Christian Brauner writes: > proc_get_long() is a funny function. It uses simple_strtoul() and for a > good reason. proc_get_long() wants to always succeed the parse and return > the maybe incorrect value and the trailing characters to check against a > pre-defined list of acceptable trailing

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

2018-10-16 Thread Eric W. Biederman
Enke Chen writes: > Hi, Eric: > > On 10/15/18 4:28 PM, Eric W. Biederman wrote: >> With that said I think the best solution would be to figure out how to >> allow the coredump to run in parallel with the usual exit signal, and >> exit code reaping of the pr

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

2018-10-16 Thread Eric W. Biederman
Oleg Nesterov writes: > On 10/15, Enke Chen wrote: >> >> > I don't understand why we need valid_predump_signal() at all. >> >> Most of the signals have well-defined semantics, and would not be appropriate >> for this purpose. > > you are going to change the rules anyway. I will just add that

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

2018-10-15 Thread Eric W. Biederman
Enke Chen writes: > For simplicity and consistency, this patch provides an implementation > for signal-based fault notification prior to the coredump of a child > process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can > be used by an application to express its interest and to

Re: [RFC] Allow user namespace inside chroot

2018-10-15 Thread Eric W. Biederman
Jann Horn writes: > On Mon, Oct 15, 2018 at 7:10 PM wrote: >> @@ -1281,7 +1285,7 @@ static int userns_install(struct nsproxy *nsproxy, >> struct ns_common *ns) >> return -ENOMEM; >> >> put_user_ns(cred->user_ns); >> - set_cred_user_ns(cred, get_user_ns(user_ns));

Re: [RFC] Allow user namespace inside chroot

2018-10-15 Thread Eric W. Biederman
Have you considered using pivot_root to drop all of the pieces of the filesystem you don't want to be visible? That should be a much better solution overall. It is must a matter of: mount --bind /path/you/would/chroot/to pivot_root /path/you/would/chroot/to /put/old umount -l /put/old You

Re: linux-next: manual merge of the userns tree with the tip tree

2018-10-14 Thread Eric W. Biederman
Stephen Rothwell writes: > Hi all, > > On Mon, 15 Oct 2018 15:11:59 +1100 Stephen Rothwell > wrote: >> >> Today's linux-next merge of the userns tree got a conflict in: >> >> arch/x86/mm/fault.c >> >> between commit: >> >> 164477c2331b ("x86/mm: Clarify hardware vs. software

Re: [tip:x86/mm] x86/mm: Break out user address space handling

2018-10-14 Thread Eric W. Biederman
tip-bot for Dave Hansen writes: > Commit-ID: aa37c51b9421d66f7931c5fdcb9ce80c450974be > Gitweb: > https://git.kernel.org/tip/aa37c51b9421d66f7931c5fdcb9ce80c450974be > Author: Dave Hansen > AuthorDate: Fri, 28 Sep 2018 09:02:23 -0700 > Committer: Peter Zijlstra > CommitDate: Tue, 9

Re: [LKP] 601d5abfea [ 13.686356] BUG: unable to handle kernel paging request at 34ca027e

2018-10-12 Thread Eric W. Biederman
branch where these fixes exist was tested. I have not problem with that sequence of events it is just a little surprising. If I have not read this test report correctly please let me know. Eric > commit 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0 > Author: Eric W. Biederman >

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

2018-10-11 Thread Eric W. Biederman
David Howells writes: > Okay, this appears to fix the cycle-creation problem. > > It could probably be improved by comparing sequence numbers as Alan suggests, > but I need to work out how to get at that. It should just be a matter of replacing the test "if (p->mnt.mnt_sb->s_type == )" with "if

Re: [LKP] 4ce5f9c9e7 [ 1.323881] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:1031 kmalloc_slab

2018-10-10 Thread Eric W. Biederman
ebied...@xmission.com (Eric W. Biederman) writes: > Sean Christopherson writes: > >> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote: >>> ebied...@xmission.com (Eric W. Biederman) writes: >>> >>> > So I am flummoxed. I a

Re: [LKP] 4ce5f9c9e7 [ 1.323881] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:1031 kmalloc_slab

2018-10-10 Thread Eric W. Biederman
Sean Christopherson writes: > On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote: >> ebied...@xmission.com (Eric W. Biederman) writes: >> >> > So I am flummoxed. I am reading through the code and I don't see >> > anything that could trigger

Re: [Ksummit-discuss] [PATCH v2 0/3] code of conduct fixes

2018-10-10 Thread Eric W. Biederman
James Bottomley writes: > Resend to show accumulated tags and also to add a third patch listing > the TAB as the reporting point as a few people seem to want. If it > gets the same level of support, I'll send it in with the other two. There is also: > Our Responsibilities >

Re: [Ksummit-discuss] [PATCH v2 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

2018-10-10 Thread Eric W. Biederman
ption clause for email addresses ordinarily collected by > the project to correct this ambiguity. Acked-by: "Eric W. Biederman" > > Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.") > Acked-by: Geert Uytterhoeven > Acked-by: Shuah Khan > Acked-by:

Re: [LKP] 4ce5f9c9e7 [ 1.323881] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:1031 kmalloc_slab

2018-10-10 Thread Eric W. Biederman
ebied...@xmission.com (Eric W. Biederman) writes: > So I am flummoxed. I am reading through the code and I don't see > anything that could trigger this, and when I ran the supplied reproducer > it did not reproduce for me. Even more so. With my tool chain the line that reports th

Re: [LKP] 4ce5f9c9e7 [ 1.323881] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:1031 kmalloc_slab

2018-10-10 Thread Eric W. Biederman
to work. Eric kernel test robot writes: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > commit 4ce5f9c9e7546915c559ffae594e6d73f918db00 > Autho

[REVIEW][PATCH 7/6] signal: In sigqueueinfo prefer sig not si_signo

2018-10-05 Thread Eric W. Biederman
l sets the si_signo field to the value specified >in sig, so that the receiver of the signal can also obtain the signal >number via that field. > > On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote: >> >> If there is some application that call

Re: [REVIEW][PATCH 2/6] signal: Fail sigqueueinfo if si_signo != sig

2018-10-05 Thread Eric W. Biederman
Andrei Vagin writes: > On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote: >> The kernel needs to validate that the contents of struct siginfo make >> sense as siginfo is copied into the kernel, so that the proper union >> members can be put in the

Re: [REVIEW][PATCH 2/6] signal: Fail sigqueueinfo if si_signo != sig

2018-10-05 Thread Eric W. Biederman
Andrei Vagin writes: > On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote: >> The kernel needs to validate that the contents of struct siginfo make >> sense as siginfo is copied into the kernel, so that the proper union >> members can be put in the

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

2018-10-04 Thread Eric W. Biederman
Pavel Snajdr writes: > > We started our organization (vpsFree.org) on top of OpenVZ patch set and are > now > working to get vanilla up to the task of replacing the venerable 2.6.32-based > OpenVZ 6 Linux-like thing. The new Code of Conduct is a guarantee for us, that > we won't be laughed out

Re: linux-next: manual merge of the userns tree with the y2038 tree

2018-10-04 Thread Eric W. Biederman
Stephen Rothwell writes: > Hi Eric, > > Today's linux-next merge of the userns tree got a conflict in: > > kernel/signal.c > > between commit: > > 49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use > __kernel_timespec") > > from the y2038 tree and commit: > > ae7795bc6187

Re: Setting monotonic time?

2018-10-03 Thread Eric W. Biederman
Thomas Gleixner writes: > On Wed, 3 Oct 2018, Eric W. Biederman wrote: >> Direct access to hardware/drivers and not through an abstraction like >> the vfs (an abstraction over block devices) can legitimately be handled >> by hotplug events. I unplug one keyboard I plug

Re: [RFC v2 v2 1/1] ns: add binfmt_misc to the mount namespace

2018-10-03 Thread Eric W. Biederman
Laurent Vivier writes: > This patch allows to have a different binftm_misc configuration > in each container we mount binfmt_misc filesystem with mount namespace > enabled. > > A container started without the CLONE_NEWNS will use the host binfmt_misc > configuration, otherwise the container

Re: Setting monotonic time?

2018-10-02 Thread Eric W. Biederman
Thomas Gleixner writes: > On Tue, 2 Oct 2018, Arnd Bergmann wrote: >> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote: >> > >> > On Mon, 1 Oct 2018, Eric W. Biederman wrote: >> > > In the context of process migration there is a simpler subproblem th

Setting monotonic time?

2018-10-01 Thread Eric W. Biederman
In the context of process migration there is a simpler subproblem that I think it is worth exploring if we can do something about. For a cluster of machines all running with synchronized clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between machines. Not having a matching

Re: [RFC 00/20] ns: Introduce Time Namespace

2018-10-01 Thread Eric W. Biederman
Thomas Gleixner writes: > Eric, > > On Fri, 28 Sep 2018, Eric W. Biederman wrote: >> Thomas Gleixner writes: >> > On Wed, 26 Sep 2018, Eric W. Biederman wrote: >> >> At the same time using the techniques from the nohz work and a little >> >>

Re: [RFC 0/2] ns: introduce binfmt_misc namespace

2018-10-01 Thread Eric W. Biederman
Laurent Vivier writes: > Le 01/10/2018 à 09:21, Eric W. Biederman a écrit : >> Andy Lutomirski writes: >> >>> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier wrote: >>>> >>>> This series introduces a new namespace for binfmt_misc. >>>&g

Re: [RFC 0/2] ns: introduce binfmt_misc namespace

2018-10-01 Thread Eric W. Biederman
Andy Lutomirski writes: > On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier wrote: >> >> This series introduces a new namespace for binfmt_misc. >> > > This seems conceptually quite reasonable, but I'm wondering if the > number of namespace types is getting out of hand given the current > API.

Re: [RFC 00/20] ns: Introduce Time Namespace

2018-09-28 Thread Eric W. Biederman
Thomas Gleixner writes: > On Wed, 26 Sep 2018, Eric W. Biederman wrote: >> Reading the code the calling sequence there is: >> tick_sched_do_timer >>tick_do_update_jiffies64 >> update_wall_time >> timekeeping_advance >>

Re: [PATCH V6 08/33] csky: Process management and Signal

2018-09-27 Thread Eric W. Biederman
Guo Ren writes: > --- /dev/null > +++ b/arch/csky/abiv2/fpu.c > +void fpu_fpe(struct pt_regs * regs) > +{ > + int sig; > + unsigned int fesr; > + siginfo_t info; > + > + fesr = mfcr("cr<2, 2>"); > + > + if(fesr & FPE_ILLE){ > + info.si_code = ILL_ILLOPC; > +

Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX

2018-09-27 Thread Eric W. Biederman
Jarkko Sakkinen writes: > From: Sean Christopherson > > Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the > error code. The PF_SGX bit is set if and only if the #PF is detected > by the Enclave Page Cache Map (EPCM), which is consulted only after > an access walks the kernel's

Re: [PATCH v14 08/19] signal: x86/sgx: Add SIGSEGV siginfo code for SGX EPCM fault

2018-09-27 Thread Eric W. Biederman
Jarkko Sakkinen writes: > From: Sean Christopherson > > The SGX Enclave Page Cache Map (EPCM) is a hardware-managed table > that enforces accesses to an enclave's EPC page in addition to the > software-managed kernel page tables, i.e. the effective permissions > for an EPC page are a logical

Re: [REVIEW][PATCH 00/15] signal/arm64: siginfo cleanups

2018-09-27 Thread Eric W. Biederman
Catalin Marinas writes: > Hi Eric, > > On Mon, Sep 24, 2018 at 11:07:05AM +0200, Eric W. Biederman wrote: >> This is the continuation of my work to sort out signaling of exceptions >> with siginfo. The old signal sending functions by taking a siginfo >> argument resul

Re: [RFC 00/20] ns: Introduce Time Namespace

2018-09-26 Thread Eric W. Biederman
Andrey Vagin writes: > On Tue, Sep 25, 2018 at 12:02:32AM +0200, Eric W. Biederman wrote: >> Andrey Vagin writes: >> >> > On Fri, Sep 21, 2018 at 02:27:29PM +0200, Eric W. Biederman wrote: >> >> Dmitry Safonov writes: >> >> >> >> &

[REVIEW][PATCH 5/6] signal: Distinguish between kernel_siginfo and siginfo

2018-09-25 Thread Eric W. Biederman
as siginfo. The reduction in size comes in a following change. Signed-off-by: "Eric W. Biederman" --- arch/x86/include/asm/compat.h | 2 +- drivers/usb/core/devio.c | 4 +- fs/binfmt_elf.c | 6 +- fs/coredump.c | 2 +- fs/fcntl.c|

[REVIEW][PATCH 6/6] signal: Use a smaller struct siginfo in the kernel

2018-09-25 Thread Eric W. Biederman
signals the kernel has sent. Reducing the stack footprint and the work to copy siginfo around from 2 cachelines to 1 cachelines seems worth doing even if I don't have benchmarks to show a performance difference. Suggested-by: Linus Torvalds Signed-off-by: "Eric W. Biederman" --- inc

[REVIEW][PATCH 3/6] signal: Remove the need for __ARCH_SI_PREABLE_SIZE and SI_PAD_SIZE

2018-09-25 Thread Eric W. Biederman
Rework the defintion of struct siginfo so that the array padding struct siginfo to SI_MAX_SIZE can be placed in a union along side of the rest of the struct siginfo members. The result is that we no longer need the __ARCH_SI_PREAMBLE_SIZE or SI_PAD_SIZE definitions. Signed-off-by: "E

[REVIEW][PATCH 4/6] signal: Introduce copy_siginfo_from_user and use it's return value

2018-09-25 Thread Eric W. Biederman
. This is a necessary prerequisite for using a smaller siginfo in the kernel than the kernel exports to userspace. Signed-off-by: "Eric W. Biederman" --- include/linux/signal.h | 1 + kernel/ptrace.c| 12 +--- kernel/signal.c| 25 - 3 files c

[REVIEW][PATCH 2/6] signal: Fail sigqueueinfo if si_signo != sig

2018-09-25 Thread Eric W. Biederman
CRIU just returns to the kernel what the kernel gave to it. If there is some application that calls sigqueueinfo directly that has a problem with this added sanity check we can revisit this when we see what kind of crazy that application is doing. Signed-off-by: "Eric W. Biederman" ---

[REVIEW][PATCH 1/6] signal/sparc: Move EMT_TAGOVF into the generic siginfo.h

2018-09-25 Thread Eric W. Biederman
When moving all of the architectures specific si_codes into siginfo.h, I apparently overlooked EMT_TAGOVF. Move it now. Remove the now redundant test in siginfo_layout for SIGEMT as now NSIGEMT is always defined. Signed-off-by: "Eric W. Biederman" --- arch/sparc/include/uapi/asm/sig

[REVIEW][PATCH 0/6] signal: Shrinking the kernel's siginfo structure

2018-09-25 Thread Eric W. Biederman
is a kernel that only uses 48 bytes for siginfo internally when the ABI defines siginfo to be 128 bytes. The first EMT_TAGOVF change is not necesssary to strinking siginfo. Eric W. Biederman (6): signal/sparc: Move EMT_TAGOVF into the generic siginfo.h signal: Fail sigqueueinfo if si_signo

Re: [RFC 00/20] ns: Introduce Time Namespace

2018-09-24 Thread Eric W. Biederman
Andrey Vagin writes: > On Fri, Sep 21, 2018 at 02:27:29PM +0200, Eric W. Biederman wrote: >> Dmitry Safonov writes: >> >> > Discussions around time virtualization are there for a long time. >> > The first attempt to implement time namespace was in 2006

[REVIEW][PATCH 1/3] signal/unicore32: Use send_sig_fault where appropriate

2018-09-24 Thread Eric W. Biederman
Signed-off-by: "Eric W. Biederman" --- arch/unicore32/kernel/fpu-ucf64.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/arch/unicore32/kernel/fpu-ucf64.c b/arch/unicore32/kernel/fpu-ucf64.c index 8594b168f25e..fc5dad32a982 100644 --- a/arch/unicore32/

[REVIEW][PATCH 3/3] signal/unicore32: Use force_sig_fault where appropriate

2018-09-24 Thread Eric W. Biederman
Signed-off-by: "Eric W. Biederman" --- arch/unicore32/mm/fault.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/arch/unicore32/mm/fault.c b/arch/unicore32/mm/fault.c index a942776110a0..b9a3a50644c1 100644 --- a/arch/unicore32/mm/fault.c +++ b/arch/un

  1   2   3   4   5   6   7   8   9   10   >