Date: Sat, 6 Apr 2019 07:47:01 +0200 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: freebsd-current@freebsd.org Subject: Re: HEAD'S UP: fusefs sysctls going away Message-ID: <49723980-27d7-1b2f-e583-5b6c10666ad3@plan-b.pwste.edu.pl> In-Reply-To: <CAOtMX2hVnDzReKOzaHNS_SZPOy9=x%2B1b1w3AyXwbFdb54w%2BFZA@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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pg7kAYhy6sEi9tXoLrPQVD6McF5JNszXq Content-Type: multipart/mixed; boundary="z6wT2axPnmTARZ5tyOretUAHfHV9v9O3W"; protected-headers="v1" From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: freebsd-current@freebsd.org Message-ID: <49723980-27d7-1b2f-e583-5b6c10666ad3@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> In-Reply-To: <CAOtMX2hVnDzReKOzaHNS_SZPOy9=x+1b1w3AyXwbFdb54w+FZA@mail.gmail.com> --z6wT2axPnmTARZ5tyOretUAHfHV9v9O3W Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US W dniu 21.03.2019 o=C2=A017: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.or= g> 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 bug= s >>>>> in particular fuse daemons. However, there is no indication as to >>>>> which those daemons are, neither in the code nor in SVN. All of th= e >>>>> workarounds are at least 6.5 years old, so the original bugs may ha= ve >>>>> been fixed already. Since the original bugs aren't documented, I >>>>> consider these workarounds to be unmaintainable, and I'm planning t= o >>>>> delete them unless anybody objects. Please pipe up if you still us= e >>>>> 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 disabl= e >>>> mmap support for fusefs. Is there a per-fusefs replacement for >>>> mmap_enable? From a security perspective, it would be nice to keep t= he >>>> 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 cach= ing >>> 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=3D=3D2= ). > >> 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=C2=A0=C2=A0=C2=A0 =3D 0x248 fault code=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =3D supervisor read data=C2= =A0 , page not present instruction pointer=C2=A0=C2=A0=C2=A0 =3D 0x20:0xffffffff82d6250c stack pointer=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =3D 0x28:0xfffffe005dc2c630 frame pointer=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =3D 0x28:0xfffffe005dc2c7b0 code segment=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =3D base 0x0, limit 0xf= ffff, type 0x1b =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =3D DPL 0, pres = 1, long 1, def32 0, gran 1 processor eflags=C2=A0=C2=A0=C2=A0 =3D interrupt enabled, resume, IOPL =3D= 0 current process=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =3D 2016 (mount_fuse= fs) trap number=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =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 0xfffffe005dc2cb= f0 --- 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=C2=A0 5 17:12:53 CEST 2019. As a workaround loading fusefs.ko and fuse.ko modules can be disabled. --=20 Marek Zarychta --z6wT2axPnmTARZ5tyOretUAHfHV9v9O3W-- --pg7kAYhy6sEi9tXoLrPQVD6McF5JNszXq 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//1SjSwFAlyoPVkACgkQdZ/s//1S jSxaaQf7BMqw5+7qQ/mdg/aKEVvV9PlhMQd0n4ShhvpH6Xs3Pl8qj0m7zkCTnDsZ AGn5bv23QzmSiivGNMQFTdY5GfOXngKMxnLY/qhQ597JEciPxAYdidTK7wgq13Sg rlLPbFiB5sSlii7C4r/FtPku9ckcz/qQbXOyAAID4oYX7fW56QBK4x+UdxXE0yYb DQEkza+uCdR+oLrZbTweJXOMcI0BvW/oxOriZdEKfIcC6/ZEPr+X/xSSH+yq9bTH Fmwtcsyk4EAB+IRsUG+z1AIV1uQfFspOohZv+kkJNSkegg+2u7JoDaqLem4/csPf 8QF4b+TkJAn0xk/7rvJN+I6mE5889A== =q8wI -----END PGP SIGNATURE----- --pg7kAYhy6sEi9tXoLrPQVD6McF5JNszXq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49723980-27d7-1b2f-e583-5b6c10666ad3>