From owner-freebsd-current@freebsd.org Sat Apr 6 14:52:52 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 53742155FFCB for ; Sat, 6 Apr 2019 14:52:52 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 844A884EE5; Sat, 6 Apr 2019 14:52:51 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu ([IPv6:2001:470:71:d47:89e0:9791:aa76:705b]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id x36EqjpY026748 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 6 Apr 2019 16:52:46 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1554562366; bh=Tb+5GZ8qOAjnVOeTv3bbK5XHoAHc2+p4LseoHjcBxlM=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=YDn/VmVBEZk1ISEqab7rgq+RVbtU2YxyFGz7re8srvBMy8boLaHFHtimzOS9beIkt 6pXeupr5G+r3rtKGJ5K8+KdwXK4Fe2hPwcAG+m40C4BFuajPibFdD4pMgRKI2omLmS 14JDY465AX3VuFlCc7o3JJxM7a9juP+OhiXF6xB/dvL4u6P1r9p4yr7UTVnzN/m4bk ici6zIeVZqoONeO4xKIlzuCLYV8g+d4EtduYUHQDxHMT13QSGWllagROzKFPF9izIG OKLcA9HvwNCc05Zgu2khQqobDILTOfz8PQ1hsq4NdMj8to4HtCe7WNa5x4fO8U7Dvb kgJXLlGRGqY/Q== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:470:71:d47:89e0:9791:aa76:705b] claimed to be fomalhaut.potoki.eu To: Alan Somers Cc: FreeBSD CURRENT References: <20190321154817.2lgwjzl4o2urlmdw@mutt-hbsd> <20190321155922.rdsnvyztssgmms2x@mutt-hbsd> <49723980-27d7-1b2f-e583-5b6c10666ad3@plan-b.pwste.edu.pl> From: Marek Zarychta Openpgp: preference=signencrypt Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; prefer-encrypt=mutual; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Subject: Re: HEAD'S UP: fusefs sysctls going away Message-ID: <2ce4c843-745b-76b9-cda9-4c83ab005110@plan-b.pwste.edu.pl> Date: Sat, 6 Apr 2019 16:52:40 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ohzWwbTIzmDnagtZd2tEVBqDygfyRq9uL" 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 14:52:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ohzWwbTIzmDnagtZd2tEVBqDygfyRq9uL Content-Type: multipart/mixed; boundary="ZwS85fZQjjVJ0QEDerVC5Ccd6RH7rgOf7"; protected-headers="v1" From: Marek Zarychta To: Alan Somers Cc: FreeBSD CURRENT Message-ID: <2ce4c843-745b-76b9-cda9-4c83ab005110@plan-b.pwste.edu.pl> Subject: Re: HEAD'S UP: fusefs sysctls going away References: <20190321154817.2lgwjzl4o2urlmdw@mutt-hbsd> <20190321155922.rdsnvyztssgmms2x@mutt-hbsd> <49723980-27d7-1b2f-e583-5b6c10666ad3@plan-b.pwste.edu.pl> In-Reply-To: --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 >> 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 >> 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--