Re: HEAD'S UP: fusefs sysctls going away

On Fri, Apr 5, 2019 at 11:48 PM Marek Zarychta <
zarychtam_at_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_at_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_at_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