From owner-freebsd-arch@freebsd.org Mon Apr 16 16:10:13 2018 Return-Path: Delivered-To: freebsd-arch@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 358C0F8F66C for ; Mon, 16 Apr 2018 16:10:13 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4B046CA40 for ; Mon, 16 Apr 2018 16:10:12 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 28E285A9F13; Mon, 16 Apr 2018 16:10:12 +0000 (UTC) Date: Mon, 16 Apr 2018 16:10:12 +0000 From: Brooks Davis To: freebsd-arch@freebsd.org Subject: Do fuswintr/suswintr make sense? Message-ID: <20180416161012.GB44509@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NMuMz9nt05w80d4+" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 16:10:13 -0000 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The fuswintr() and suswintr() are intended to be safe in interrupt context. They are used in the profiling code and if they fail the code falls back to triggering a trap with appropriate fields in struct thread. This is fine as such, but amd64, arm, i386, and powerpc have implementations that always fail. arm64, mips, riscv, and sparc64 all add code to the trap handler to detect that this particular code has faulted and return to the handler before doing and processing that might result in a sleep. This optimization came from 4.4BSD. Does this optimization actually make sense in 2017, particularly given that we're not taking advantage of it on x86 (and worse, our implementations of return (-1) aren't inlined so they have cache impacts)? -- Brooks --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJa1MrjAAoJEKzQXbSebgfAHLAH/jFFiIiAB9NH0wQiLu8d1nLT ++fy2Ul9Gh4nqiDInBdyh8BpRpSd1ZipKhDgxo3NV+cGy6CH7OvTd+Y8G2py5N9v 3soc9GF+I1p9K/ByVEHco3bTbTOzhO5WEMHnjgCWyjFC7ZS46+taWGp4pqUMjvUO 3AWHNWJy/0hLcX9ecWSV91GRk1Um3CqZPB+G2fdF+ppitsYcRrNsnH98mUMFbttc xwnp+KPIxatNxcadZOc7elhaA5Asdoo+IbPK5erOefzKlukKlz60JJ/KWt5wv79+ qktA0x4EvwKRghYels7ffQcpDSWFPmCudfBC3DYpX/OqsEjMmZzJra3TQkHrXnY= =tbmI -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+-- From owner-freebsd-arch@freebsd.org Mon Apr 16 16:40:25 2018 Return-Path: Delivered-To: freebsd-arch@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 0B795F920C4 for ; Mon, 16 Apr 2018 16:40:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1CA7580B; Mon, 16 Apr 2018 16:40:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3GGeCWY009298 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Apr 2018 19:40:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3GGeCWY009298 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3GGeCjO009297; Mon, 16 Apr 2018 19:40:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Apr 2018 19:40:12 +0300 From: Konstantin Belousov To: Brooks Davis Cc: freebsd-arch@freebsd.org Subject: Re: Do fuswintr/suswintr make sense? Message-ID: <20180416164012.GJ1774@kib.kiev.ua> References: <20180416161012.GB44509@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180416161012.GB44509@spindle.one-eyed-alien.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 16:40:25 -0000 On Mon, Apr 16, 2018 at 04:10:12PM +0000, Brooks Davis wrote: > The fuswintr() and suswintr() are intended to be safe in interrupt > context. They are used in the profiling code and if they fail the code > falls back to triggering a trap with appropriate fields in struct > thread. This is fine as such, but amd64, arm, i386, and powerpc have > implementations that always fail. arm64, mips, riscv, and sparc64 all > add code to the trap handler to detect that this particular code has > faulted and return to the handler before doing and processing that might > result in a sleep. This optimization came from 4.4BSD. > > Does this optimization actually make sense in 2017, particularly > given that we're not taking advantage of it on x86 (and worse, our > implementations of return (-1) aren't inlined so they have cache > impacts)? I do not see a reason to keep them around. When I worked on copyin_nofault(), I specifically decided to not make it working from the interrupt handlers contexts. You need to be at the top of the kernel to be able to use it. So far there were no requests to change that. Since there is no other users of interrupt-safe usermode access, and since the only user cope with such access not working, I do not see a point. From owner-freebsd-arch@freebsd.org Mon Apr 16 18:47:58 2018 Return-Path: Delivered-To: freebsd-arch@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 11912F9C236 for ; Mon, 16 Apr 2018 18:47:58 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 83E626CE7B; Mon, 16 Apr 2018 18:47:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 0AA7C3C95FA; Tue, 17 Apr 2018 04:16:36 +1000 (AEST) Date: Tue, 17 Apr 2018 04:16:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Brooks Davis cc: freebsd-arch@freebsd.org Subject: Re: Do fuswintr/suswintr make sense? In-Reply-To: <20180416161012.GB44509@spindle.one-eyed-alien.net> Message-ID: <20180417031820.A6479@besplex.bde.org> References: <20180416161012.GB44509@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=cIaQihWN c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=Ea_Lx5TPYwStz69f7lMA:9 a=nxQliJHjNl0e4aVJ:21 a=4SXOs_RI4vWxyaE_:21 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:47:58 -0000 On Mon, 16 Apr 2018, Brooks Davis wrote: > The fuswintr() and suswintr() are intended to be safe in interrupt > context. They are used in the profiling code and if they fail the code > falls back to triggering a trap with appropriate fields in struct > thread. This is fine as such, but amd64, arm, i386, and powerpc have > implementations that always fail. arm64, mips, riscv, and sparc64 all > add code to the trap handler to detect that this particular code has > faulted and return to the handler before doing and processing that might > result in a sleep. This optimization came from 4.4BSD. Not having it for i386 also came from 4.4BSD. NetBSD fixed it for i386 in 1994 or earlier (locore.s 1.41) > Does this optimization actually make sense in 2017, particularly > given that we're not taking advantage of it on x86 (and worse, our > implementations of return (-1) aren't inlined so they have cache > impacts)? Profiling is even more in need of optimizations in 2017. But not this one, at least on i386. [fs]uswintr() might be worth using if they looked like [fs]uword16() and the latter and were efficient. (I don't see any reason why they can't be essentially the same. If the user memory is not mapped then they will cause the same page fault, and they just have to fail instead of trying to handle the page fault.) But [fs]uword16() are now extremely inefficient on i386. The user and kernel memory are in a different address spaces. The functions are implemented using a trampoline that has to map user memory, and this is even slower than having a trampoline. But not as slow as switching the whole memory map on every crossing of the user-kernel boundary including for profiling interrupts. Since accessing 1 word at a time is too slow on i386 no matter how it is done. the correct optimization looks more like a fancier ast() than fsuswintr(): use a kernel buffer with a few hundred addresses instead of only 1, and tell the application about the addresses in a single operation. Do a full switch back to user context and run a trampoline to add 1 to many addresses there, since the addresses are expected to be on many different pages. (The buffer now is { td_profil_addr; td_profil_ticks; }. It can hold several ticks but only at 1 address. Multiple ticks occur mainly when the system can't keep up; then the address is clobbered but the ticks count is charged to a new address.) Bruce From owner-freebsd-arch@freebsd.org Mon Apr 16 19:33:49 2018 Return-Path: Delivered-To: freebsd-arch@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 B2282F9FB4A for ; Mon, 16 Apr 2018 19:33:49 +0000 (UTC) (envelope-from tychon@freebsd.org) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64DC57353C for ; Mon, 16 Apr 2018 19:33:49 +0000 (UTC) (envelope-from tychon@freebsd.org) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id C645DCFF4F for ; Mon, 16 Apr 2018 15:33:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=sasl; bh=1WcMWxmAcyR13Q0CZ3rc0MbSi9E=; b= Fle0Jjr4MUSWjKJopuQsccimF37d1TOXKZ7nWDWDQ3czOFH155cErfd+tpFCEP8B ReehIDQJJc7D9tiYKmZORxswNSEjd3pBgxpAwuJNlUvN+H6U2H7OnZVTuxrIjvxk L1KAX7p7zs3TpO6XIeO1o0wUyzO7jw3Yf0KaLEfNfa8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id BDDFACFF4D for ; Mon, 16 Apr 2018 15:33:48 -0400 (EDT) Received: from [10.0.1.195] (unknown [146.115.68.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 429DCCFF4C for ; Mon, 16 Apr 2018 15:33:48 -0400 (EDT) From: Tycho Nightingale Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: excluding processes from PTI Message-Id: Date: Mon, 16 Apr 2018 15:33:47 -0400 To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.6.18) X-Pobox-Relay-ID: 15A5036E-41AD-11E8-B82B-67830C78B957-09779102!pb-smtp2.pobox.com X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:33:49 -0000 In D15100, which I just put on Phabricator, it's possible for processes = to be excluded from PTI. What is not in D15100 is policy, nor = implementation of a policy, to select which processes are excluded from = PTI. A trivial implementation of a policy would be something like this: @@ -2656,6 +2657,7 @@ int pmap_pinit_type(pmap_t pmap, enum pmap_type pm_type, int flags) { + struct ucred *cred =3D curthread->td_ucred; vm_page_t pml4pg, pml4pgu; vm_paddr_t pml4phys; int i; @@ -2689,7 +2691,7 @@ if (pm_type =3D=3D PT_X86) { pmap->pm_cr3 =3D pml4phys; pmap_pinit_pml4(pml4pg); - if (pti) { + if (pti && (jailed(cred) || cred->cr_ruid !=3D 0)) { pml4pgu =3D vm_page_alloc(NULL, 0, = VM_ALLOC_NORMAL | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED | = VM_ALLOC_WAITOK); pmap->pm_pml4u =3D (pml4_entry_t *)PHYS_TO_DMAP( which excludes those processes running as superuser and are not in-jail. Another approach, suggested by kib, is to provide finer-grained control. = Perhaps using procctl(2) instead. I'm curious to solicit some feedback on this. Thanks! Tycho From owner-freebsd-arch@freebsd.org Thu Apr 19 07:20:52 2018 Return-Path: Delivered-To: freebsd-arch@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 4AAC5F88CCC for ; Thu, 19 Apr 2018 07:20:52 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B673F84D53 for ; Thu, 19 Apr 2018 07:20:51 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-lf0-x22c.google.com with SMTP id d79-v6so6281080lfd.0 for ; Thu, 19 Apr 2018 00:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GiigaTEbWsOMnTVUZlXiiwaHdEuMmtSUbXFQAYElGtw=; b=nkPIF1h4H8uOKC4jNMB+4NNrMEfhUoBLiDJXV8mVlIOlehSL53PiCdE41XqPW0sH7h g217BrmX8StRBrHoaAFcCwo1YYsOaWyET4qvCjx/NvHxaQIihAVAarW3QjHmjQ0jSf8U 1GcCMwABPpcBeMI7Wm6VBHosT7Wltcb/DFUaU5D+IF8Wq1TIciTckiPw8+DzAQcYdATx ig4bgXzHE/8RIDIlWWxhB6GGgpEGLScgXmlvwZL8eTVfaZVrjk0Gvu0lHHXAiO5O1DuR UO/rUA7VqL0Ht46Fhybzt083mx/ac4cutl6aqz0MhbTMDw5j76pfg5ez53hidlcUe6wu Si/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GiigaTEbWsOMnTVUZlXiiwaHdEuMmtSUbXFQAYElGtw=; b=oOeFstrDGU0US2StFl3dZ5tSSQkDA2It4pUk2UMKvR5aCR0DvYr9TZNS0L9CF6iLXG tKRTwdgh3nM7dFYgmo2/bDkgn/9FxWBWot6nremTmJORsVoTA4y04qKIhyCFTHDckk9T o3vN2TUZknC6+HXRa+Zm/hWMSoOpwYzUH9rUBjENO7At+JV/vsN+1ljUrSeT0t1+IewN eAgsm+8ASPu5uDXt80UF6OxyTT+yd0rxKg+NkkhjYKNRjw/tL+NmRkjuLbvxd+/3IrvJ oIGf6qfu7WRuiX7hMUU5IzsVg/lcojGXmbyvY7EusNof4HC14+uZETqtBzEkXj4/ApqN fLjQ== X-Gm-Message-State: ALQs6tB0swXYTEDqX8jzHs1K5TrAMc3o+oW27/6BybLrawTphEc67rdS gMo3zB7SNaHr3eA31PTKMGd6tqktlEGizzLyTTZ+2g== X-Google-Smtp-Source: AIpwx48pTx+GyuCyImKZhh5IYxHGOTEqtRxTof/TiPkha38ht8JzUjNwWWC94FdFindWpWw76JavRTjEA0qq8zs3Oa8= X-Received: by 2002:a19:5a1d:: with SMTP id o29-v6mr3321165lfb.93.1524122449650; Thu, 19 Apr 2018 00:20:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:294d:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 00:20:19 -0700 (PDT) In-Reply-To: References: From: Ed Schouten Date: Thu, 19 Apr 2018 09:20:19 +0200 Message-ID: Subject: Re: excluding processes from PTI To: Tycho Nightingale Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 07:20:52 -0000 Hi Tycho, 2018-04-16 21:33 GMT+02:00 Tycho Nightingale : > - if (pti) { > + if (pti && (jailed(cred) || cred->cr_ruid != 0)) { > > which excludes those processes running as superuser and are not in-jail. > > Another approach, suggested by kib, is to provide finer-grained control. Perhaps using procctl(2) instead. Maybe it's sufficient to just use priv_check() here? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands