Date: Sat, 6 Apr 2019 09:28:53 -0600 From: Alan Somers <asomers@freebsd.org> To: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: HEAD'S UP: fusefs sysctls going away Message-ID: <CAOtMX2hh2ZrDhU7HiNYKy1ruZ1aLEkw3S-xBxNasNyirshPuPQ@mail.gmail.com> In-Reply-To: <2ce4c843-745b-76b9-cda9-4c83ab005110@plan-b.pwste.edu.pl> References: <CAOtMX2i9qwhNTdCgNxxUOmf=FZAOmD7w=T8vmvyF-9-P0iw-CQ@mail.gmail.com> <20190321154817.2lgwjzl4o2urlmdw@mutt-hbsd> <CAOtMX2gqmVAZumDsB9_6YaOeZsFF5m3NN4aibL=8CYNWDGo3OA@mail.gmail.com> <20190321155922.rdsnvyztssgmms2x@mutt-hbsd> <CAOtMX2hVnDzReKOzaHNS_SZPOy9=x%2B1b1w3AyXwbFdb54w%2BFZA@mail.gmail.com> <49723980-27d7-1b2f-e583-5b6c10666ad3@plan-b.pwste.edu.pl> <CAOtMX2g3=d3S5jgU2=BuG%2BMAPzHCMFkNLuOvwRp3y5o-Tmok=g@mail.gmail.com> <2ce4c843-745b-76b9-cda9-4c83ab005110@plan-b.pwste.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 6, 2019 at 8:52 AM Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2hh2ZrDhU7HiNYKy1ruZ1aLEkw3S-xBxNasNyirshPuPQ>