[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191024151054.GJ9902@redhat.com>
Date: Thu, 24 Oct 2019 11:10:54 -0400
From: Andrea Arcangeli <aarcange@...hat.com>
To: Mike Rapoport <rppt@...ux.ibm.com>
Cc: Andy Lutomirski <luto@...nel.org>, Jann Horn <jannh@...gle.com>,
Daniel Colascione <dancol@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Pavel Emelyanov <xemul@...tuozzo.com>,
Lokesh Gidra <lokeshgidra@...gle.com>,
Nick Kralevich <nnk@...gle.com>,
Nosh Minwalla <nosh@...gle.com>,
Tim Murray <timmurray@...gle.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
Linux API <linux-api@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API.
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 in
> experimental and I believe that's not indexed by the code search.
>
> 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
Powered by blists - more mailing lists