| Message ID | 20200423002632.224776-1-dancol@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Control over userfaultfd kernel-fault handling | expand |
On Wed, Apr 22, 2020 at 05:26:30PM -0700, Daniel Colascione wrote: > This small patch series adds a new flag to userfaultfd(2) that allows > callers to give up the ability to handle user-mode faults with the > resulting UFFD file object. In then add a new sysctl to require > unprivileged callers to use this new flag. > > The purpose of this new interface is to decrease the change of an > unprivileged userfaultfd user taking advantage of userfaultfd to > enhance security vulnerabilities by lengthening the race window in > kernel code. There are other ways to lengthen the race window, such as madvise MADV_DONTNEED, mmap of fuse files ... Could the patchset commit log include some discussion about why these are not the concern please? Multiple subsystems including vhost have come to rely on copy from/to user behaving identically to userspace access. Could the patchset please include discussion on what effect blocking these will have? E.g. I guess Android doesn't use vhost right now. Will it want to do it to run VMs in 2021? Thanks! > This patch series is split from [1]. > > [1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/ So in that series, Kees said: https://lore.kernel.org/lkml/202002112332.BE71455@keescook/#t What is the threat being solved? (I understand the threat, but detailing it in the commit log is important for people who don't know it.) Could you pls do that? > Daniel Colascione (2): > Add UFFD_USER_MODE_ONLY > Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only > > Documentation/admin-guide/sysctl/vm.rst | 13 +++++++++++++ > fs/userfaultfd.c | 18 ++++++++++++++++-- > include/linux/userfaultfd_k.h | 1 + > include/uapi/linux/userfaultfd.h | 9 +++++++++ > kernel/sysctl.c | 9 +++++++++ > 5 files changed, 48 insertions(+), 2 deletions(-) > > -- > 2.26.2.303.gf8c07b1a785-goog >
On Fri, Jul 24, 2020 at 7:01 AM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Wed, Apr 22, 2020 at 05:26:30PM -0700, Daniel Colascione wrote: > > This small patch series adds a new flag to userfaultfd(2) that allows > > callers to give up the ability to handle user-mode faults with the > > resulting UFFD file object. In then add a new sysctl to require > > unprivileged callers to use this new flag. > > > > The purpose of this new interface is to decrease the change of an > > unprivileged userfaultfd user taking advantage of userfaultfd to > > enhance security vulnerabilities by lengthening the race window in > > kernel code. > > There are other ways to lengthen the race window, such as madvise > MADV_DONTNEED, mmap of fuse files ... > Could the patchset commit log include some discussion about > why these are not the concern please? > > Multiple subsystems including vhost have come to rely on > copy from/to user behaving identically to userspace access. > > Could the patchset please include discussion on what effect blocking > these will have? E.g. I guess Android doesn't use vhost right now. > Will it want to do it to run VMs in 2021? > > Thanks! > > > This patch series is split from [1]. > > > > [1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/ > > So in that series, Kees said: > https://lore.kernel.org/lkml/202002112332.BE71455@keescook/#t > > What is the threat being solved? (I understand the threat, but detailing > it in the commit log is important for people who don't know it.) > Adding Android security folks, Nick and Jeff, to answer. > Could you pls do that? > > > Daniel Colascione (2): > > Add UFFD_USER_MODE_ONLY > > Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only > > > > Documentation/admin-guide/sysctl/vm.rst | 13 +++++++++++++ > > fs/userfaultfd.c | 18 ++++++++++++++++-- > > include/linux/userfaultfd_k.h | 1 + > > include/uapi/linux/userfaultfd.h | 9 +++++++++ > > kernel/sysctl.c | 9 +++++++++ > > 5 files changed, 48 insertions(+), 2 deletions(-) > > > > -- > > 2.26.2.303.gf8c07b1a785-goog > > >