From owner-freebsd-current@freebsd.org Sat Apr 6 15:29:08 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10412156206F for ; Sat, 6 Apr 2019 15:29:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 655B685EC4 for ; Sat, 6 Apr 2019 15:29:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f173.google.com with SMTP id q66so7670250ljq.7 for ; Sat, 06 Apr 2019 08:29:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8T1kHVjz7G6sNXk0droLCBRXkERQx/Ttps8dx/F2caQ=; b=Jn7Ru+1512m7xZyCrWa7w37k0nesTHktXU+WqgTWqbQH2b/IP23VsvKD8A4UxvKvTN 9wpWmPehyWy9XYKH3G/YhpiXFRzNgvirya6KpT4aEYYl/xVS36BJ9WojixRM3ksUhmZs Pxymqy3bKv5u7Hfldg58QnNaXORkMJlPs2kN4SkuwFoBExq/DBAM6XEMSeEjYUgHsxFU ptUTJzM3nb2bQ0DfbRhd1bDcgQiAACaHDqqxORadnv0XvhXiTsTAsikpAz1LsD3KgoSP GUN0XQPzzjiKLPMgpGBA0SiYP7ehkmdLVtgpUBEKl5/tL0GfHvCu7+IbvdotFHXKa7FR +xFA== X-Gm-Message-State: APjAAAUds5WIx18g93fheUrZwd9dfDmRRTvlz/nI/kavoB/ja3+uANDS 0a58xjESfRuSmH4Fv70C0thLtCZIYpXbB7BcKPI= X-Google-Smtp-Source: APXvYqxjGH8R9tPSajz5NNfCE5XblVx+OC9O8qSQ/ii1yy0SrFC8ThveUp5rcA/ddo1As4xNwMknxWR+6tfMnc0+hyE= X-Received: by 2002:a2e:94c7:: with SMTP id r7mr10270577ljh.91.1554564545490; Sat, 06 Apr 2019 08:29:05 -0700 (PDT) MIME-Version: 1.0 References: <20190321154817.2lgwjzl4o2urlmdw@mutt-hbsd> <20190321155922.rdsnvyztssgmms2x@mutt-hbsd> <49723980-27d7-1b2f-e583-5b6c10666ad3@plan-b.pwste.edu.pl> <2ce4c843-745b-76b9-cda9-4c83ab005110@plan-b.pwste.edu.pl> In-Reply-To: <2ce4c843-745b-76b9-cda9-4c83ab005110@plan-b.pwste.edu.pl> From: Alan Somers Date: Sat, 6 Apr 2019 09:28:53 -0600 Message-ID: Subject: Re: HEAD'S UP: fusefs sysctls going away To: Marek Zarychta Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 655B685EC4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 15:29:08 -0000 On Sat, Apr 6, 2019 at 8:52 AM Marek Zarychta wrote: > > W dniu 06.04.2019 o 15:39, Alan Somers pisze: > > On Fri, Apr 5, 2019 at 11:48 PM Marek Zarychta < > > zarychtam@plan-b.pwste.edu.pl> wrote: > > > >> W dniu 21.03.2019 o 17:03, Alan Somers pisze: > >>> On Thu, Mar 21, 2019 at 10:00 AM Shawn Webb < > shawn.webb@hardenedbsd.org> > >> wrote: > >>>> On Thu, Mar 21, 2019 at 09:55:15AM -0600, Alan Somers wrote: > >>>>> On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb < > shawn.webb@hardenedbsd.org> > >> wrote: > >>>>>> Hey Alan, > >>>>>> > >>>>>> Thank you very much for your work in maintaining fusefs. I only use > >>>>>> fusefs in very limited circumstances, so take what I'm about to say > >>>>>> with a grain of salt. > >>>>>> > >>>>>> On Thu, Mar 21, 2019 at 09:43:07AM -0600, Alan Somers wrote: > >>>>>>> fusefs has several sysctl knobs that seem to be workarounds for > bugs > >>>>>>> in particular fuse daemons. However, there is no indication as to > >>>>>>> which those daemons are, neither in the code nor in SVN. All of > the > >>>>>>> workarounds are at least 6.5 years old, so the original bugs may > have > >>>>>>> been fixed already. Since the original bugs aren't documented, I > >>>>>>> consider these workarounds to be unmaintainable, and I'm planning > to > >>>>>>> delete them unless anybody objects. Please pipe up if you still > use > >>>>>>> them! > >>>>>>> > >>>>>>> vfs.fusefs.mmap_enable: If non-zero, and data_cache_mode is also > >>>>>>> non-zero, enable mmap(2) of FUSE files > >>>>>> I'm curious if the security impacts of removing the toggle to > disable > >>>>>> mmap support for fusefs. Is there a per-fusefs replacement for > >>>>>> mmap_enable? From a security perspective, it would be nice to keep > the > >>>>>> ability to disable mapping of files mounted on a fusefs. > >>>>> As a matter of fact, there are three other ways to disable mmap: > >>>>> 1) Set vfs.fusefs.data_cache_mode=0. This completely disables > caching > >>>>> file data, which precludes mmap. > >>>>> 2) Use the undocumented -o no_datacache mount option, which does the > >>>>> same thing on a per-mount basis. > >>>>> 3) Use the undocumented -o no_mmap mount option, which disables mmap > >>>>> on a per-mount basis. > >>>> Awesome! I wasn't aware of these. Thanks! > >>>> > >>>>> Are you aware of any general security problems with using mmap? > >>>>> Anything that would apply to fusefs but not other filesystems? > >>>> Primarily because I trust the filesystems natively implemented in my > >>>> OS more than I trust some (potentially random) fusefs module. > >>>> > >>>> For example, if I'm in a shared hosting environment, implemented with > >>>> jails, and I let the customer mount a fusefs module in the jail (which > >>>> is now possible, if I remember right), then I must trust that the > >>>> module's mmap integration is properly implemented. I'm not sure I > >>>> personally am okay with that level of trust. > >>> Ah, well you needn't worry about that. mmap is handled entirely > >>> within the kernel. The userland fusefs module only sees writes and > >>> reads. From userland's perspective, the only real difference is that > >>> mmap()ed writes don't identify the pid of the originating process, > >>> whereas direct writes do (except when vfs.fusefs.data_cache_mode==2). > >>> > >>>> However, the point is moot now that you documented the three ways to > >>>> disable mmap (two of which work on a per-mount basis). > >> After recent changes in fusefs code I am getting such panics regularly > >> on amd64: > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 3; apic id = 03 > >> fault virtual address = 0x248 > >> fault code = supervisor read data , page not present > >> instruction pointer = 0x20:0xffffffff82d6250c > >> stack pointer = 0x28:0xfffffe005dc2c630 > >> frame pointer = 0x28:0xfffffe005dc2c7b0 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> current process = 2016 (mount_fusefs) > >> trap number = 12 > >> panic: page fault > >> cpuid = 3 > >> time = 1554528396 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> 0xfffffe005dc2c2e0 > >> vpanic() at vpanic+0x19d/frame 0xfffffe005dc2c330 > >> panic() at panic+0x43/frame 0xfffffe005dc2c390 > >> trap_fatal() at trap_fatal+0x394/frame 0xfffffe005dc2c3f0 > >> trap_pfault() at trap_pfault+0x49/frame 0xfffffe005dc2c450 > >> trap() at trap+0x29f/frame 0xfffffe005dc2c560 > >> calltrap() at calltrap+0x8/frame 0xfffffe005dc2c560 > >> --- trap 0xc, rip = 0xffffffff82d6250c, rsp = 0xfffffe005dc2c630, rbp = > >> 0xfffffe005dc2c7b0 --- > >> fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfffffe005dc2c7b0 > >> vfs_domount() at vfs_domount+0xace/frame 0xfffffe005dc2c9e0 > >> vfs_donmount() at vfs_donmount+0x934/frame 0xfffffe005dc2ca80 > >> sys_nmount() at sys_nmount+0x69/frame 0xfffffe005dc2cac0 > >> amd64_syscall() at amd64_syscall+0x36e/frame 0xfffffe005dc2cbf0 > >> fast_syscall_common() at fast_syscall_common+0x101/frame > 0xfffffe005dc2cbf0 > >> --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp = > >> 0x7fffffffe128, rbp = 0x7fffffffe730 --- > >> KDB: enter: panic > >> > >> Last time I have checked it happened on FreeBSD 13.0-CURRENT #21 > >> r345948: Fri Apr 5 17:12:53 CEST 2019. > >> > >> As a workaround loading fusefs.ko and fuse.ko modules can be disabled. > >> > >> -- > >> Marek Zarychta > > Thanks for the bug report. This is probably fixed by r345419 (which > hasn't > > been merged to head yet). If so, then it indicates that your fuse daemon > > is doing something wrong. What fuse file system are you trying to use, > and > > what command are you using to start it? > > -Alan > > XFCE4 desktop environment seems to be the culprit of the whole anxiety. > It has installed fusefs-libs-2.9.9 as a dependency. I get these panics > during the XFCE session startup. Furthermore, I haven't any fusefs > packages installed beside mentioned fusefs-libs. > > -- > > Marek Zarychta Then the culprit is probably /usr/local/libexec/gvfsd-fuse. But on my XFCE4 system, that command never runs. I don't know why not. Try this patch: https://reviews.freebsd.org/D19836 -Alan