Hey, this is my first post to linux-kernel, so please be kind. :-)
Linus Torvalds wrote on May 31:
> I'm with Uli on this one. "Stateful" stuff is bad. It's essentially
> impossible to handle with libraries - either the library would have to
> explciitly always turn the state the way _it_ needs it
On Tue, Jun 19, 2018 at 9:32 PM, Joel Fernandes wrote:
> On Tue, Jun 19, 2018 at 05:57:35PM -0700, Alistair Strachan wrote:
> > The ashmem driver did not check that the size/offset of the vma passed
> > to its .mmap() function was not larger than the ashmem object being
> > mapped. This could caus
On Mon, Jul 30, 2018 at 5:45 PM, Jakub Kicinski
wrote:
> On Mon, 30 Jul 2018 17:33:39 -0700, Daniel Colascione wrote:
>> On Mon, Jul 30, 2018 at 5:26 PM, Jakub Kicinski wrote:
>> > On Mon, 30 Jul 2018 03:25:43 -0700, Daniel Colascione wrote:
>> > > On Mon, Jul 30, 20
On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
>
> * Daniel Colascione:
>
> > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> >> * Daniel Colascione:
> >>
> >>> If the kernel provides a system call, libc should provide a C wrapper
>
Yep. That's also what I was talking about, FWIW.
On Mon, Nov 19, 2018 at 11:31 AM, Christian Brauner
wrote:
> On Mon, Nov 19, 2018 at 01:02:06PM -0600, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Mon, Nov 19, 2018 at 07:59:24AM -0800, Danie
On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner wrote:
> That can be done without a loop by comparing the level counter for the
> two pid namespaces.
>
>>
>> And you can rewrite pidns_get_parent to use it. So you would instead be
>> doing:
>>
>> if (pidns_is_descendant(proc_pid_ns, task_act
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 counter for t
On Mon, Nov 19, 2018 at 2:40 PM Tycho Andersen wrote:
> Can I just register an objection here that I think using a syscall
> just for this is silly?
Yes, you can argue that the bikeshed should be ioctl-colored and not
syscall-colored.
> My understanding is that the concern is that some code migh
On Mon, Nov 19, 2018 at 4:28 PM Andy Lutomirski wrote:
>
> On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > These tools also care about ioctls. Adding a system call is a pain,
> > > but the solution is to make adding system calls less of a pain, not to
> > > permanently make the Linux
I had been led to believe that the proposal would be a comprehensive
process API, not an ioctl basically equivalent to my previous patch.
If you had a more comprehensive proposal, please just share it on LKML
instead of limiting the discussion to those able to attend these
various conferences. If t
On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
> I fully agree that a more comprehensive, less expensive API for
> managing processes would be nice. But I also think that this patch
> (using the directory fd and ioctl) is better from a security
> perspective than using a new file in /pro
On Sun, Nov 18, 2018 at 3:17 AM, Christian Brauner wrote:
> +static int proc_tgid_open(struct inode *inode, struct file *file)
> +{
> + /* grab reference to struct pid */
> + file->private_data = get_pid(proc_pid(inode));
Why grab another reference to the struct pid when the inode alr
On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione wrote:
>>
>> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
>> > I fully agree that a more comprehensive, less expensive API for
>> > managin
On Sun, Nov 18, 2018 at 8:33 AM, Randy Dunlap wrote:
> On 11/18/18 8:17 AM, Andy Lutomirski wrote:
>> On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione wrote:
>>>
>>> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
>>>> I fully agree that a mor
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:
>> >>
On Sun, Nov 18, 2018 at 9:09 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 8:49 AM Daniel Colascione wrote:
>>
>> On Sun, Nov 18, 2018 at 8:33 AM, Randy Dunlap wrote:
>> > On 11/18/18 8:17 AM, Andy Lutomirski wrote:
>> >> On Sun, Nov 18, 2018 at 7:5
On Sun, Nov 18, 2018 at 9:42 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 9:24 AM Daniel Colascione wrote:
>> Assuming we don't broaden exit status readability (which would make a
>> lot of things simpler), the exit notification mechanism must work like
>> this
On Sun, Nov 18, 2018 at 9:43 AM, Eric W. Biederman
wrote:
> 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 A
On Sun, Nov 18, 2018 at 9:41 AM, Christian Brauner wrote:
> On Sun, Nov 18, 2018 at 07:38:09AM -0800, Andy Lutomirski wrote:
>> On Sun, Nov 18, 2018 at 5:59 AM Daniel Colascione wrote:
>> >
>> > I had been led to believe that the proposal would be a comprehensive
>
On Sun, Nov 18, 2018 at 10:15 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 10:07 AM Daniel Colascione wrote:
>> Next, I want to merge my exithand proposal, or something like it. It's
>> likewise a simple change that, in a minimal way, addresses a
>> longstandin
On Sun, Nov 18, 2018 at 10:28 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 9:51 AM Daniel Colascione wrote:
>>
>> > I'm not entirely sure that ship has sailed. In the kernel, we already
>> > have a bit of a distinction between a pid (and tid, etc -- I
On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
> On 2018-11-18, Daniel Colascione wrote:
>> > Here's my point: if we're really going to make a new API to manipulate
>> > processes by their fd, I think we should have at least a decent idea
>> >
On Sun, Nov 18, 2018 at 12:15 PM, Christian Brauner
wrote:
>> That is, I'm proposing an API that looks like this:
>>
>> int process_kill(int procfs_dfd, int signo, const union sigval value)
>
> I've started a second tree with process_signal(int procpid_dfd, int sig)
Thanks.
> instead of an ioctl
On Sun, Nov 18, 2018 at 12:28 PM, Andy Lutomirski wrote:
>> That is, I'm proposing an API that looks like this:
>>
>> int process_kill(int procfs_dfd, int signo, const union sigval value)
>>
>> If, later, process_kill were to *also* accept process-capability FDs,
>> nothing would break.
>
> Except
On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
wrote:
> On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
>>
>>
>> > On Nov 18, 2018, at 12:44 PM, Daniel Colascione wrote:
>> >
>>
>> >
>> > That is, I'm proposi
On Sun, Nov 18, 2018 at 1:30 PM, Christian Brauner wrote:
> On Sun, Nov 18, 2018 at 10:23:36PM +0100, Christian Brauner wrote:
>> On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
>> > On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
>> > wrote:
>
On Sun, Nov 18, 2018 at 4:09 PM, Aleksa Sarai wrote:
> On 2018-11-18, Daniel Colascione wrote:
>> On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
>> > On 2018-11-18, Daniel Colascione wrote:
>> >> > Here's my point: if we're really going to mak
On Sun, Nov 18, 2018 at 4:08 PM, Aleksa Sarai wrote:
> On 2018-11-18, Daniel Colascione wrote:
>> > The gist is to have file descriptors for processes which is obviously not
>> > a new
>> > idea. This has been done before in other OSes and it has been tried befo
On Sun, Nov 18, 2018 at 4:53 PM, Daniel Colascione wrote:
>> Sure, I'd propose that ptrace_may_access() is what we should use for
>> operation permission checks.
>
> The tricky part is that ptrace_may_access takes a struct task. We want
> logic that's *like* pt
On Mon, Nov 19, 2018 at 7:45 AM, Andy Lutomirski wrote:
> On Mon, Nov 19, 2018 at 2:33 AM Christian Brauner
> wrote:
>>
>> The kill() syscall operates on process identifiers. After a process has
>> exited its pid can be reused by another process. If a caller sends a signal
>> to a reused pid it
On Mon, Nov 19, 2018 at 2:32 AM, Christian Brauner wrote:
> The kill() syscall operates on process identifiers. After a process has
> exited its pid can be reused by another process. If a caller sends a signal
> to a reused pid it will end up signaling the wrong process. This issue has
> often sur
On Mon, Nov 19, 2018 at 2:54 AM, Pavel Machek wrote:
> On Mon 2018-11-05 13:22:05, Daniel Colascione wrote:
>> State explicitly that holding a /proc/pid file descriptor open does
>> not reserve the PID. Also note that in the event of PID reuse, these
>> open file descriptors
On Mon, Nov 19, 2018 at 8:13 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
> I wonder how fast it would be holding a pid with another open()ed fd.
> And then you need to read comm (or how you filter whom to kill).
> It seems to me that procfs will be even slower with this safe-way.
> But I might
On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> * Daniel Colascione:
>
>> If the kernel provides a system call, libc should provide a C wrapper
>> for it, even if in the opinion of the libc maintainers, that system
>> call is flawed.
>
> It's no
On Mon, Nov 12, 2018 at 6:35 AM, Theodore Y. Ts'o wrote:
> On Mon, Nov 12, 2018 at 12:45:26PM +, Szabolcs Nagy wrote:
>> >> A lot of the new system calls lack clear specifications or are just
>> >> somewhat misdesigned. For example, pkey_alloc
>> > [snip]
>> >> getrandom still causes boot del
On Mon, Nov 12, 2018 at 9:24 AM, Zack Weinberg wrote:
> Daniel Colascione wrote:
>> >> If the kernel provides a system call, libc should provide a C wrapper
>> >> for it, even if in the opinion of the libc maintainers, that system
>> >> call is flawed.
&g
On Mon, Nov 12, 2018 at 11:11 AM, Florian Weimer wrote:
> * Daniel Colascione:
>
>> What about off_t differences? Again, it doesn't matter. From the
>> *kernel's* point of view, there's one width of offset parameter per
>> system call per architecture.
On Mon, Nov 12, 2018 at 2:51 PM, Joseph Myers wrote:
> I see no obvious reason why a kernel-provided
> library, with all the problems that entails, should need to be involved,
> rather than putting new APIs either in libc
I initially wanted to put the APIs in libc. I still do. But that's
proving
On Wed, Nov 14, 2018 at 3:58 AM, Szabolcs Nagy wrote:
> On 13/11/18 19:39, Dave Martin wrote:
>> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>>> We should adopt a similar approach. Shipping a lower-level
>>> "liblinux.so" tightly bound
On Wed, Nov 14, 2018 at 10:15 AM, Joseph Myers wrote:
> Any
> feature (e.g. syscall library) with a design coming solely from the kernel
> rather than a cooperative process is also likely to have an unsuitable
> design meaning it doesn't get used.
Is that so? membarrier came directly from the ker
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 another process. If a caller sends a
> > signal to a reused pid it will end up signaling th
On Thu, Dec 6, 2018 at 12:29 PM Eric W. Biederman wrote:
> 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
On Thu, Dec 6, 2018 at 1:47 PM Eric W. Biederman wrote:
>
> Christian Brauner writes:
>
> >> Your intention is to add the thread case to support pthreads once the
> >> process case is sorted out. So this is something that needs to be made
> >> clear. Did I miss how you plan to handle threads?
>
On Thu, Dec 6, 2018 at 2:22 PM Eric W. Biederman wrote:
>
> 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
On Thu, Dec 6, 2018 at 4:31 PM Serge E. Hallyn wrote:
>
> On Fri, Dec 07, 2018 at 12:17:45AM +0100, Christian Brauner wrote:
> > On Thu, Dec 06, 2018 at 11:39:48PM +0100, Christian Brauner wrote:
> > > On Thu, Dec 06, 2018 at 03:46:53PM -0600, Eric W. Biederman wrote:
> > > > Christian Brauner wr
On Thu, Dec 6, 2018 at 4:59 PM Serge E. Hallyn wrote:
>
> On Thu, Dec 06, 2018 at 04:34:54PM -0800, Daniel Colascione wrote:
> > On Thu, Dec 6, 2018 at 4:31 PM Serge E. Hallyn wrote:
> > >
> > > On Fri, Dec 07, 2018 at 12:17:45AM +0100, Christian Brauner wrote:
>
On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner wrote:
>
> On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann
> wrote:
> >On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski
> >wrote:
> >>
> >> On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote:
> >> > siginfo_t as it is now still has a n
On Fri, Nov 9, 2018 at 1:06 PM, Jann Horn wrote:
>
> +linux-api for API addition
> +hughd as FYI since this is somewhat related to mm/shmem
>
> On Fri, Nov 9, 2018 at 9:46 PM Joel Fernandes (Google)
> wrote:
> > Android uses ashmem for sharing memory regions. We are looking forward
> > to migrati
On Fri, Nov 9, 2018 at 2:37 PM, Andy Lutomirski wrote:
>> Another, more general fix might be to prevent /proc/pid/fd/N opens
>> from "upgrading" access modes. But that'd be a bigger ABI break.
>
> I think we should fix that, too. I consider it a bug fix, not an ABI break,
> personally.
Someone,
On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes wrote:
> Thanks Andy for your thoughts, my comments below:
>
> On Fri, Nov 09, 2018 at 10:05:14PM -0800, Andy Lutomirski wrote:
>>
>>
>> > On Nov 9, 2018, at 7:20 PM, Joel Fernandes wrote:
>> >
>> >> On Fri, Nov 09, 2018 at 10:19:03PM +0100, Jann H
Now that glibc is basically not adding any new system call wrappers,
how about publishing an "official" system call glue library as part of
the kernel distribution, along with the uapi headers? I don't think
it's reasonable to expect people to keep using syscall(__NR_XXX) for
all new functionality,
On Sat, Nov 10, 2018 at 11:01 AM, Willy Tarreau wrote:
> On Sat, Nov 10, 2018 at 10:52:06AM -0800, Daniel Colascione wrote:
>> Now that glibc is basically not adding any new system call wrappers,
>> how about publishing an "official" system call glue library as part of
&
On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione wrote:
> On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes
> wrote:
>> Thanks Andy for your thoughts, my comments below:
[snip]
>> I don't see it as warty, different seals will work differently. It works
>> quite we
On Sun, Nov 11, 2018 at 12:17 AM, Willy Tarreau wrote:
>
> On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote:
> > [1] https://sourceware.org/
>
>
> Bah, after all, this
>
> wipes quite a bit of the shame I feel every time I do something to
>
> bypass it :-/
>
>
> The sad
On Sun, Nov 11, 2018 at 12:09 AM, Joel Fernandes wrote:
> On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:
> [...]
>> >>> I see two reasonable solutions:
>> >>>
>> >>> 1. Don’t fiddle with the struct file at all. Instead make the inode
>> >>> flag
>> >>> work b
On Sun, Nov 11, 2018 at 3:09 AM, Florian Weimer wrote:
> We had a patch for the membarrier system call, but the kernel developers
> could not tell us what the system call does in therms of the C/C++
> memory model
[snip]
> A lot of the new system calls lack clear specifications or are just
> somew
to wait for any BPF programs using the old map to
complete, and then drain the old map without fear that BPF programs
may still be updating it.
Signed-off-by: Daniel Colascione
---
include/uapi/linux/bpf.h | 1 +
kernel/bpf/syscall.c | 14 ++
2 files changed, 15 insertions(+)
d
On Tue, Jul 3, 2018 at 12:36 AM, Vlastimil Babka wrote:
> +CC
>
> On 07/01/2018 08:31 PM, Thomas Lindroth wrote:
>> While looking around in /proc on my v4.14.52 system I noticed that
>> all processes got a lot of "Locked" memory in /proc/*/smaps. A lot
>> more memory than a regular user can usuall
On Sat, Dec 22, 2018 at 8:46 PM Theodore Y. Ts'o wrote:
>
> On Sat, Dec 22, 2018 at 08:10:07PM -0800, Matthew Wilcox wrote:
> > Pretty much every file format has the ability to put arbitrary blocks
> > of information into a file somewhere the tools which don't know about
> > it will skip it. For
On Mon, Jan 7, 2019 at 5:32 PM Dave Chinner wrote:
>
> On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
> > As newer systems have more and more IRQs and CPUs available in their
> > system, the performance of reading /proc/stat frequently is getting
> > worse and worse.
>
> Because the
ntry. This interface allow lmkd to give up polling and instead block
and wait for process death.
Signed-off-by: Daniel Colascione
---
fs/proc/Makefile | 1 +
fs/proc/base.c | 1 +
fs/proc/exithand.c | 117 +++
fs/proc/intern
stem pid
entry. This interface allow lmkd to give up polling and instead block
and wait for process death.
Signed-off-by: Daniel Colascione
---
fs/proc/Makefile | 1 +
fs/proc/base.c | 1 +
fs/proc/exithand.c | 128 +++
fs/proc/intern
Thanks for taking a look.
On Mon, Oct 29, 2018 at 7:45 PM, Joel Fernandes wrote:
>
> On Mon, Oct 29, 2018 at 10:53 AM Daniel Colascione wrote:
> >
> > This patch adds a new file under /proc/pid, /proc/pid/exithand.
> > Attempting to read from an exithand f
n /proc/*/status; do (
cd $(dirname $proc_status)
readarray proc_argv -d'' < cmdline
if ((${#proc_argv[@]} > 0)) &&
[[ ${proc_argv[0]} = *$pat* ]];
then
echo 15 > kill
fi
) ||
On Mon, Oct 29, 2018 at 7:25 PM, Davidlohr Bueso wrote:
> This patch introduces a new /proc/stat2 file that is identical to the
> regular 'stat' except that it zeroes all hard irq statistics. The new
> file is a drop in replacement to stat for users that need performance.
For a while now, I've be
On Mon, Oct 29, 2018 at 11:34 PM, Alexey Dobriyan wrote:
>> I'd much rather move to a model in which userspace *explicitly* tells
>> the kernel which fields it wants, with the kernel replying with just
>> those particular fields, maybe in their raw binary representations.
>> The ASCII-text bag-of-
On Tue, Oct 30, 2018 at 3:21 AM, Joel Fernandes wrote:
> On Mon, Oct 29, 2018 at 3:11 PM 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
>> proces
On Tue, Oct 30, 2018 at 3:06 AM, Joel Fernandes wrote:
> On Mon, Oct 29, 2018 at 1:01 PM Daniel Colascione wrote:
>>
>> Thanks for taking a look.
>>
>> On Mon, Oct 29, 2018 at 7:45 PM, Joel Fernandes wrote:
>> >
>> > On Mon, Oct 29, 20
On Tue, Oct 30, 2018 at 5:00 AM, Aleksa Sarai wrote:
> 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, &#
On Tue, Oct 30, 2018 at 10:40 AM, Christian Brauner
wrote:
> On Tue, Oct 30, 2018 at 11:39:11AM +0100, Christian Brauner wrote:
>> On Tue, Oct 30, 2018 at 08:50:22AM +0000, Daniel Colascione wrote:
>> > On Tue, Oct 30, 2018 at 3:21 AM, Joel Fernandes wrote:
>> > > O
On Tue, Oct 30, 2018 at 11:04 AM, Christian Brauner
wrote:
> On Tue, Oct 30, 2018 at 11:48 AM Daniel Colascione wrote:
>>
>> On Tue, Oct 30, 2018 at 10:40 AM, Christian Brauner
>> wrote:
>> > On Tue, Oct 30, 2018 at 11:39:11AM +0100, Christian Brauner wrote:
>&
On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes wrote:
> On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
>> On 2018-10-30, Joel Fernandes wrote:
>> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote:
>> > [...]
>> > > > > (Unfortunately
>> > > > > there are lots of thin
On Tue, Oct 30, 2018 at 11:23 PM, Christian Brauner
wrote:
> On Wed, Oct 31, 2018 at 12:10 AM Daniel Colascione wrote:
>> I think Aleksa's larger point is that it's useful to treat processes
>> as other file-descriptor-named, poll-able, wait-able resources.
>> Cons
On Wed, Oct 31, 2018 at 12:57 AM, Joel Fernandes wrote:
> On Tue, Oct 30, 2018 at 11:10:47PM +0000, Daniel Colascione wrote:
>> On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes
>> wrote:
>> > On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
>> &g
On Wed, Oct 31, 2018 at 12:42 AM, Joel Fernandes wrote:
> On Wed, Oct 31, 2018 at 09:49:08AM +1100, Aleksa Sarai wrote:
>> On 2018-10-30, Joel Fernandes wrote:
>> > > > [...]
>> > > > > > > (Unfortunately
>> > > > > > > there are lots of things that make it a bit difficult to use
>> > > > > > >
On Wed, Oct 31, 2018 at 12:27 PM, David Laight wrote:
> From: Daniel Colascione
>> Sent: 29 October 2018 17:53
>>
>> This patch adds a new file under /proc/pid, /proc/pid/exithand.
>> Attempting to read from an exithand file will block until the
>> corresponding
On Wed, Oct 31, 2018 at 12:44 PM, Oleg Nesterov wrote:
> On 10/30, Eric W. Biederman wrote:
>>
>> At a bare minimum you need to perform the permission check using the
>> credentials of the opener of the file.Which means refactoring
>> kill_pid so that you can perform the permission check for k
27;' < cmdline
if ((${#proc_argv[@]} > 0)) &&
[[ ${proc_argv[0]} = *$pat* ]];
then
echo 15 > kill
fi
) || true; done
Signed-off-by: Daniel Colascione
---
Added a real-user-ID check to prevent confused deputy attacks.
fs/proc/
On Wed, Oct 31, 2018 at 2:25 PM, David Laight wrote:
> From: Daniel Colascione
>> Sent: 31 October 2018 12:56
>> On Wed, Oct 31, 2018 at 12:27 PM, David Laight
>> wrote:
>> > From: Daniel Colascione
>> >> Sent: 29 October 2018 17:53
>> >>
&
On Wed, Oct 31, 2018 at 3:10 PM, Oleg Nesterov wrote:
> On 10/31, Daniel Colascione wrote:
>>
>> > perhaps it would be simpler to do
>> >
>> > my_cred = override_creds(file->f_cred);
>> > kill_pid(...);
>> > rev
rray proc_argv -d'' < cmdline
if ((${#proc_argv[@]} > 0)) &&
[[ ${proc_argv[0]} = *$pat* ]];
then
echo 15 > kill
fi
) || true; done
Signed-off-by: Daniel Colascione
---
Turns out that checking struct user isn't sufficient, since
+ linux-api
On Mon, Oct 29, 2018 at 5:53 PM, Daniel Colascione wrote:
> This patch adds a new file under /proc/pid, /proc/pid/exithand.
> Attempting to read from an exithand file will block until the
> corresponding process exits, at which point the read will successfully
> compl
On Wed, Oct 31, 2018 at 5:25 PM, Andy Lutomirski wrote:
> I had an old patch to do much the same thing:
It's a perennial idea. :-)
> https://lore.kernel.org/patchwork/patch/345098/
>
> Can you comment as to how your API compares to my old patch?
Sure. Basically, my approach is sort-of eventfd-e
On Wed, Oct 31, 2018 at 5:54 PM, Tycho Andersen wrote:
> Why not just use an ioctl() like Jann suggested instead of this big
> security check? Then we avoid the whole setuid writer thing entirely,
Don't you think a system call would be better than a new ioctl? With
either an ioctl or a new system
On Wed, Oct 31, 2018 at 6:17 PM, Tycho Andersen wrote:
> On Wed, Oct 31, 2018 at 06:00:49PM +0000, Daniel Colascione wrote:
>> On Wed, Oct 31, 2018 at 5:54 PM, Tycho Andersen wrote:
>> > Why not just use an ioctl() like Jann suggested instead of this big
>> > securi
On Wed, Oct 17, 2018 at 5:08 AM, Christoph Hellwig wrote:
> On Wed, Oct 17, 2018 at 03:39:58AM -0700, Joel Fernandes wrote:
>> > > This usecase cannot be implemented with the existing F_SEAL_WRITE seal.
>> > > To support the usecase, this patch adds a new F_SEAL_FS_WRITE seal which
>> > > prevents
On Wed, Nov 7, 2018 at 10:03 AM, Miklos Szeredi wrote:
> On Wed, Nov 7, 2018 at 12:48 AM, Andrew Morton
> wrote:
>> On Mon, 29 Oct 2018 23:04:45 + Daniel Colascione
>> wrote:
>>
>>> On Mon, Oct 29, 2018 at 7:25 PM, Davidlohr Bueso wrote:
>>> >
On Wed, Nov 7, 2018 at 3:54 PM, Miklos Szeredi wrote:
> On Wed, Nov 7, 2018 at 4:42 PM, Daniel Colascione wrote:
>
>> configuration!" is something I've heard more than once. Who's to say
>> that sysfs is for exposing /proc/pid/stat,
>
> Patch is about
On Thu, Nov 1, 2018 at 7:00 AM, Aleksa Sarai wrote:
> On 2018-10-29, Daniel Colascione wrote:
>> This patch adds a new file under /proc/pid, /proc/pid/exithand.
>> Attempting to read from an exithand file will block until the
>> corresponding process exits, at whic
On Thu, Nov 1, 2018 at 10:47 AM, Aleksa Sarai wrote:
> On 2018-11-01, Daniel Colascione wrote:
>> On Thu, Nov 1, 2018 at 7:00 AM, Aleksa Sarai wrote:
>> > On 2018-10-29, Daniel Colascione wrote:
>> >> This patch adds a new file under /proc/pid, /proc/pid/exithand.
On Thu, Nov 1, 2018 at 11:53 AM, David Laight wrote:
> From: Sent: 31 October 2018 13:28
> ...
>> * I actually have a local variant of the patch that would have you
>> open "/proc/$PID/kill/$SIGNO" instead, since different signal numbers
>> have different permission checks.
>
> I think you'd need
On Sat, Jul 14, 2018 at 11:18 AM, Joel Fernandes wrote:
> On Tue, Jul 10, 2018 at 08:40:19PM -0700, Alexei Starovoitov wrote:
> [..]
>> > The kernel program might do:
>> >
>> > =
>> > const int current_map_key = 1;
>> > void *current_map = bpf_map_lookup_elem(outer_map, ¤t_map_key);
>> >
>> >
Hi Mathieu: this work looks very cool. See inline.
On Mon, Apr 30, 2018 at 3:48 PM Mathieu Desnoyers <
mathieu.desnoy...@efficios.com> wrote:
> Hi,
> Here is an updated RFC round of the Restartable Sequences patchset
> based on kernel 4.17-rc3. Based on feedback from Linus, I'm introducing
> onl
On Wed, May 2, 2018 at 9:03 AM Mathieu Desnoyers <
mathieu.desnoy...@efficios.com> wrote:
> - On May 1, 2018, at 11:53 PM, Daniel Colascione dan...@google.com
wrote:
> [...]
> >
> > I think a small enhancement to rseq would let us build a perfect
userspace
> >
On Wed, May 2, 2018 at 9:42 AM Steven Rostedt wrote:
> On Wed, 02 May 2018 16:07:48 +
> Daniel Colascione wrote:
> > Why couldn't we take a page fault just before schedule? The reason we
can't
> > take a page fault in atomic context is that doing so might ca
On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote:
>> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote:
> > Suppose we make a userspace mutex implemented with a lock word having
three
> > bits: acquired, sleep_mode, and wait_pending, with the rest of the
On Wed, May 2, 2018 at 1:23 PM Peter Zijlstra wrote:
> On Wed, May 02, 2018 at 06:27:22PM +0000, Daniel Colascione wrote:
> > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra
wrote:
> > >> On Wed, May 02, 2018 at 03:53:47AM +0000, Daniel Colascione wrote:
> > > >
On Mon, Apr 15, 2019 at 10:15 AM Jonathan Kowalski wrote:
> > Why else do we want pidfd?
>
> Apart from what others have already pointed out, there are two other
> things I am looking forward to:
Everything that Christian, Joel, and Jonathan have said is right.
If I can wax philosophical for a b
On Thu, Apr 18, 2019 at 10:26 AM Christian Brauner wrote:
>
> On April 18, 2019 7:23:38 PM GMT+02:00, Jann Horn wrote:
> >On Wed, Apr 17, 2019 at 3:09 PM Oleg Nesterov wrote:
> >> On 04/16, Joel Fernandes wrote:
> >> > On Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote:
> >> > >
> >>
On Thu, Apr 25, 2019 at 2:29 PM Christian Brauner wrote:
> This timing-based testing seems kinda odd to be honest. Can't we do
> something better than this?
Agreed. Timing-based tests have a substantial risk of becoming flaky.
We ought to be able to make these tests fully deterministic and not
su
1 - 100 of 228 matches
Mail list logo
