Date: Sat, 6 Apr 2019 16:52:40 +0200 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: HEAD'S UP: fusefs sysctls going away Message-ID: <2ce4c843-745b-76b9-cda9-4c83ab005110@plan-b.pwste.edu.pl> In-Reply-To: <CAOtMX2g3=d3S5jgU2=BuG%2BMAPzHCMFkNLuOvwRp3y5o-Tmok=g@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ohzWwbTIzmDnagtZd2tEVBqDygfyRq9uL Content-Type: multipart/mixed; boundary="ZwS85fZQjjVJ0QEDerVC5Ccd6RH7rgOf7"; protected-headers="v1" From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Message-ID: <2ce4c843-745b-76b9-cda9-4c83ab005110@plan-b.pwste.edu.pl> Subject: Re: HEAD'S UP: fusefs sysctls going away 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+1b1w3AyXwbFdb54w+FZA@mail.gmail.com> <49723980-27d7-1b2f-e583-5b6c10666ad3@plan-b.pwste.edu.pl> <CAOtMX2g3=d3S5jgU2=BuG+MAPzHCMFkNLuOvwRp3y5o-Tmok=g@mail.gmail.com> In-Reply-To: <CAOtMX2g3=d3S5jgU2=BuG+MAPzHCMFkNLuOvwRp3y5o-Tmok=g@mail.gmail.com> --ZwS85fZQjjVJ0QEDerVC5Ccd6RH7rgOf7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US W dniu 06.04.2019 o=C2=A015: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.o= rg> >> 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 us= e >>>>>> fusefs in very limited circumstances, so take what I'm about to sa= y >>>>>> 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 b= ugs >>>>>>> in particular fuse daemons. However, there is no indication as t= o >>>>>>> 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 disa= ble >>>>>> 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=3D0. This completely disables ca= ching >>>>> file data, which precludes mmap. >>>>> 2) Use the undocumented -o no_datacache mount option, which does th= e >>>>> same thing on a per-mount basis. >>>>> 3) Use the undocumented -o no_mmap mount option, which disables mma= p >>>>> 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 wit= h >>>> jails, and I let the customer mount a fusefs module in the jail (whi= ch >>>> 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=3D=3D= 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 =3D 3; apic id =3D 03 >> fault virtual address =3D 0x248 >> fault code =3D supervisor read data , page not present >> instruction pointer =3D 0x20:0xffffffff82d6250c >> stack pointer =3D 0x28:0xfffffe005dc2c630 >> frame pointer =3D 0x28:0xfffffe005dc2c7b0 >> code segment =3D base 0x0, limit 0xfffff, type 0x1b >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 >> current process =3D 2016 (mount_fusefs) >> trap number =3D 12 >> panic: page fault >> cpuid =3D 3 >> time =3D 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 =3D 0xffffffff82d6250c, rsp =3D 0xfffffe005dc2c630, = rbp =3D >> 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 0xfffffe005dc= 2cbf0 >> --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x8002d510a, rsp= =3D >> 0x7fffffffe128, rbp =3D 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 ha= sn't > been merged to head yet). If so, then it indicates that your fuse daem= on > 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. --=20 Marek Zarychta --ZwS85fZQjjVJ0QEDerVC5Ccd6RH7rgOf7-- --ohzWwbTIzmDnagtZd2tEVBqDygfyRq9uL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlyovTwACgkQdZ/s//1S jSzwnAgAtdtQBhDSGGVcBFpvR9KPpZqfKwccQzQhUgsfaR0+eFyt3Y3x3iKvEXVF xPIwDoErJF3JskXuKqMJtsGp6/G5ziY5ouqE7RGGVVZByiGUGeW93lQFJsAHV97h c1KBrutXbXfGW9IgAAWp2X2FiM0lrwwnGFKvUYc13urjtMPVtR3j2hiG6MUyOdEi 7LhOJwwg3agxIVyK3RZHfv34n28x0p4wP20qS3Q1iAqP6knzsFDxnKCb29nv6nF4 C0owhUAR+crcqleP2cnAt98e4eTNIF+qbar73Hjvh2oOQIjbf6moJN/pzW7jn4I4 340kdt5CEwHyVvL2JK9vhW00XXelEw== =QyuE -----END PGP SIGNATURE----- --ohzWwbTIzmDnagtZd2tEVBqDygfyRq9uL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2ce4c843-745b-76b9-cda9-4c83ab005110>