lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 13 Oct 2021 09:02:48 -0700 From: Nadav Amit <nadav.amit@...il.com> To: Peter Xu <peterx@...hat.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Andrea Arcangeli <aarcange@...hat.com>, Mike Rapoport <rppt@...ux.vnet.ibm.com> Subject: Re: [RFC PATCH] userfaultfd: support control over mm of remote PIDs > On Oct 12, 2021, at 7:18 PM, Peter Xu <peterx@...hat.com> wrote: > > On Sun, Sep 26, 2021 at 10:06:37AM -0700, Nadav Amit wrote: >> From: Nadav Amit <namit@...are.com> >> >> Non-cooperative mode is useful but only for forked processes. >> Userfaultfd can be useful to monitor, debug and manage memory of remote >> processes. >> >> To support this mode, add a new flag, UFFD_REMOTE_PID, and an optional >> second argument to the userfaultfd syscall. When the flag is set, the >> second argument is assumed to be the PID of the process that is to be >> monitored. Otherwise the flag is ignored. >> >> The syscall enforces that the caller has CAP_SYS_PTRACE to prevent >> misuse of this feature. >> >> Cc: Andrea Arcangeli <aarcange@...hat.com> >> Cc: Andrew Morton <akpm@...ux-foundation.org> >> Cc: Mike Rapoport <rppt@...ux.vnet.ibm.com> >> Cc: Peter Xu <peterx@...hat.com> >> Signed-off-by: Nadav Amit <namit@...are.com> > > I think this patch from one pov looks just likes the other patch of the > process_madvise on DONTNEED - the new interface definitely opens new way to do > things, however IMHO it would be great to discuss some detailed scenario that > we can do with it better than the existing facilities. > > The thing is uffd already provides some mechanism for doing things like > customized swapping, so that's not something new IMHO that this patch brings > (neither is what the DONTNEED patch brings), just like when I raised in the > other thread about umap. > > So IMHO it'll be great if there can be some elaboration on how the "remote" > capability could help us do things better (e.g., use cases that we may not > solve with linking against another uffd-supported library, or we can't do with > register uffd then fork()). > > (I skipped the security side of things, as I replied in the other thread that I > think I buy in your point on depending on PTRACE capability and also the > examples you gave on ptrace() and process_vm_writev() are persuasive to me, > but no expert on that..) Fair enough. Let me get back to you once I can provide more data. For now, I just ask you to have this patch in the back of your mind if any other change to userfaultfd syscall is proposed to prevent a potential conflict.
Powered by blists - more mailing lists