From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: [PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API. Date: Thu, 24 Oct 2019 11:10:54 -0400 Message-ID: <20191024151054.GJ9902@redhat.com> References: <20191012191602.45649-1-dancol@google.com> <20191012191602.45649-4-dancol@google.com> <20191023190959.GA9902@redhat.com> <20191024090258.GA9802@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20191024090258.GA9802@linux.ibm.com> Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org To: Mike Rapoport Cc: Andy Lutomirski , Jann Horn , Daniel Colascione , Linus Torvalds , Pavel Emelyanov , Lokesh Gidra , Nick Kralevich , Nosh Minwalla , Tim Murray , Mike Rapoport , Linux API , LKML List-Id: linux-api@vger.kernel.org Hello, On Thu, Oct 24, 2019 at 12:02:59PM +0300, Mike Rapoport wrote: > That's no the reason that UFFD_FEATURE_EVENT_FORK does not show up in > Debian code search, CRIU simply is not there. Debian packages CRIU only i= n > experimental and I believe that's not indexed by the code search. >=20 > As for the limitations, the races were fixed, I just forgot to update the > wiki. As for the supported memory types and COW pages, these only affect > efficiency of post-copy, but not the correctness. That's what I was hoping for. If the wiki information is stale and there are no races it is totally plausible that it's being actively used in production so we need to fix the kernel bug. I was just checking because I wasn't sure anymore of the status after I read the wiki. If the CRIU initialization code that issues the uffd syscall runs as global root the ABI breaking permission check from Andy sounds the simplest for a short term fix, because it will be unnoticed by any production usage with CIRU --lazy-pages. Then later we could add a UFFD_FEATURE_EVENT_FORK2 that will not require root permission. Thanks, Andrea