From owner-freebsd-current@freebsd.org Sat Apr 6 05:47:20 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 BFEF2156D7F1 for ; Sat, 6 Apr 2019 05:47:20 +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 F13828EE5D for ; Sat, 6 Apr 2019 05:47:19 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu ([IPv6:2001:470:71:d47:288b:35ad:1929:c8f7]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id x365l6na029878 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 6 Apr 2019 07:47:15 +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=1554529635; bh=fe5Uc83vMGvSKjv5FknMPeANTE8+VDUM+iP8XHUdOR4=; h=To:References:From:Subject:Date:In-Reply-To; b=pTW9mHYzX/vRoN+f4kRneD5+Q5481b4u9vrVo5TfZ6W5nZS5u6PaFab3Dte8+oAXf KImQqTn4ZvBe2ZembxppHDkx979IlrOPoqZ2zjDGot9dyyBTM4muw55muxfq6qs+GI GrwA8yU0yVNUrUHEGMZpZPikEvFS/jJW0P7yr8mOS6RvHrqj26caz0Qbcg/jRYaM/O eGlgSr+6yWU7rxN5KdZ1N3vTIp96/8dHDpj9AmAPLq5LG+gTfKT8FTbJTHa2Prd76T kOU9Ix7cVXx8Vqe6qUl1LLvUWDxPIRVL2zRIANGJ9pjlaUlppqtD5HkUJ7zLiXtOcf kwKtBufhqwSzw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:470:71:d47:288b:35ad:1929:c8f7] claimed to be fomalhaut.potoki.eu To: freebsd-current@freebsd.org References: <20190321154817.2lgwjzl4o2urlmdw@mutt-hbsd> <20190321155922.rdsnvyztssgmms2x@mutt-hbsd> 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: <49723980-27d7-1b2f-e583-5b6c10666ad3@plan-b.pwste.edu.pl> Date: Sat, 6 Apr 2019 07:47:01 +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="pg7kAYhy6sEi9tXoLrPQVD6McF5JNszXq" 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 05:47:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pg7kAYhy6sEi9tXoLrPQVD6McF5JNszXq Content-Type: multipart/mixed; boundary="z6wT2axPnmTARZ5tyOretUAHfHV9v9O3W"; protected-headers="v1" From: Marek Zarychta 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: <20190321154817.2lgwjzl4o2urlmdw@mutt-hbsd> <20190321155922.rdsnvyztssgmms2x@mutt-hbsd> In-Reply-To: --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 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 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--