From nobody Fri Nov 26 01:52:04 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7B7F818A6757 for ; Fri, 26 Nov 2021 01:52:12 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0d642ZjFz3LjH for ; Fri, 26 Nov 2021 01:52:12 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x835.google.com with SMTP id q14so7626478qtx.10 for ; Thu, 25 Nov 2021 17:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iRQkQITCiEVnx+DdEGSy3Gw5kxgFCUKwwjWI8tw/eVU=; b=U0SsPF2iNMyJ0dARZBBNF9hALl8z4pe055sRwAFy+0wWg2j6dIi28FO4aFJxD3mWRL PUjyFFgT7Cg5fCyn/fpb7mYdxU6F9nyvQ+Y+EpVDo+a3QYS8kto2rQWHMqfcUW6y6WZJ mfHSueXoVWhEkzM+IkB/nxMGY5/pF2X8/qgh/r+eXAdUXK4JpbJyrn8pI4SO5DzJ+P1h YXachVTL112I1AYObOZXCHIzJR2S63M1nRsPRj2WJni5lukANYz8uifZZHk/NVSy6xkY d1QYrienljW0ccSe3wqnV7cMKLN+oA0cK5Owcw+b4kNg9swW5MLuQZRiOP3oh6t5m0N5 hVzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=iRQkQITCiEVnx+DdEGSy3Gw5kxgFCUKwwjWI8tw/eVU=; b=jXErZoYpwGYFnRBfeonxwZtjkDuemK9z9OXpG0/1tON2UrfNwB1zdxE/bpep4scPvt uCLYNQMtypzw6tdBorVA5wvceXSOU3CGC2ctnmQQ5Auxf7bp5vameiBBYpomWPYwof1a S6UgqfF66wgVhBYPn3aFI+gCZSstI5VmgMAnHvGp9otbl+txj4yB/nTaR6jsjmvRNesW 6kJjbqbI+aVukSZMvyPH8vIRiUQ64SbBwNBlFY53eJjhzMMKj4XluRuGwvubsi511Prz 5ZFpGPsuuxkWYtMiCz9LONhIzbIJdAvfEHL3O39uQ0VKKLC9lTuHIEN+N2untGluwmG3 RcOg== X-Gm-Message-State: AOAM532kdx3cL35r8mgTDkCz3Kur9J8zXiEuVGNiBSlSZjMhv1iPMl71 nU+AyXMJEU9/ujSmw9jCd8xsVQ== X-Google-Smtp-Source: ABdhPJy6BTGuHeA/PZFy14wFkovKXco6jsFBFnBqUkb8zO9+c8ihG2JDtn//qP6FHVBuMred/Mk+lw== X-Received: by 2002:a05:622a:138a:: with SMTP id o10mr21306914qtk.237.1637891526127; Thu, 25 Nov 2021 17:52:06 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id g5sm2276885qko.12.2021.11.25.17.52.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Nov 2021 17:52:05 -0800 (PST) Date: Thu, 25 Nov 2021 20:52:04 -0500 From: Shawn Webb To: Konstantin Belousov Cc: David Chisnall , freebsd-current@freebsd.org Subject: Re: VDSO on amd64 Message-ID: <20211126015204.5pbzmctz2fqha6o4@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <7e7f4ba7-16b3-fa6e-fa1d-e9df957e91f1@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="22hc2edju7gzauni" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J0d642ZjFz3LjH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --22hc2edju7gzauni Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 25, 2021 at 09:53:19PM +0200, Konstantin Belousov wrote: > On Thu, Nov 25, 2021 at 09:35:53AM +0000, David Chisnall wrote: > > Great news! > >=20 > > Note that your example of throwing an exception from a signal handler w= orks > > because the signal is delivered during a system call. The compiler > > generates correct unwind tables for calls because any call may throw. > The syscalls itself are not annotated, I consider fixing this after vdso > lands. >=20 > >=20 > > If you did something like a division by zero to get a SIGFPE or a > > null-pointer dereference to get a SIGSEGV then the throw would probably= not > > work (or, rather, would be delivered to the right place but might corru= pt > > some register state). Neither clang nor GCC currently supports non-call > > exceptions by default. > Well, yes, the part of it was that the signal was synchronous. I was alw= ays > curious, how good are unwind tables generated by -fasynchronous-unwind-ta= bles > with this regard. >=20 > But still, the fact that unwinder stepped over the signal frame amused me. >=20 > >=20 > > This mechanism is more useful for Java VMs and similar. Some Linux-bas= ed > > implementations (including Android) use this to avoid null-pointer chec= ks in > > Java. > >=20 > > The VDSO mechanism in Linux is also used for providing some syscall > > implementations. In particular, getting the current approximate time a= nd > > getting the current CPU (either by reading from the VDSO's data section= or > > by doing a real syscall, without userspace knowing which). It also prov= ides > > the syscall stub that is used for the kernel transition for all 'real' > > syscalls. This doesn't matter so much on amd64, but on i386 it lets th= em > > select between int 80h, syscall or sysenter, depending on what the hard= ware > > supports. > >=20 > >=20 > > A few questions about future plans: > >=20 > > - Do you have plans to extend the VDSO to provide system call entry po= ints > > and fast-path syscalls? It would be really nice if we could move all o= f the > > libsyscalls bits into the VDSO so that any compartmentalisation mechani= sm > > that wanted to interpose on syscalls just needed to provide a replaceme= nt > > for the VDSO. > No. >=20 > Moving syscall entry point to VDSO is pointless: > - it would add one more level of indirection before SYSCALL, > - we do not have slow syscall entry point on amd64 so there is nothing to > choose. >=20 > And optimizing 32bit binaries (where we could implement slightly faster > syscall entry) is past its importance. >=20 > Basically, we do not have to split libc into libc proper and VDSO, as > Linux has. We can implement features for syscall boundary from both > sides of kernel, because libc and kernel are developed under the same > project. Usermode timehands, fast signal blocks, upcoming rseq support, > just to name a few of them, all benefit from this model. >=20 > VDSO is only needed for us to provide the unwind annotations on the signal > trampoline, in a way expected by unwinders. >=20 > >=20 > > - It looks as if the Linux VDSO mechanism isn't yet using this. Do you > > plan on moving it over? > No. >=20 > >=20 > > - I can't quite tell from kern_sharedpage.c (this file has almost no > > comments) - is the userspace mapping of the VDSO randomised? This has = been > > done on Linux for a while because the VDSO is an incredibly high-value > > target for code reuse attacks (it can do system calls and it can restor= e the > > entire register state from the contents of an on-stack buffer if you can > > jump into it). > Not now. Randomizing shared page location is not too hard, but there are > some ABI issues to sort out. We live with fixed-mapped shared page for > more than 10 years. As a point of reference, HardenedBSD's PaX-inspired ASLR implementation has randomized the shared page for more than half a decade now without issue. I suspect FreeBSD will find, if applied properly, randomization of the shared page (now VDSO) likely won't break anything. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --22hc2edju7gzauni Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGgPcIACgkQ/y5nonf4 4fqBoA//S2YLTbp/fAnoPQ9FoD0S6VFdZAqoFkC/EmJqhi2f6/3y5JaSrOX8odi6 G0oBmkIBemL9yUpNnV99+KD/AJwzGlI9ZkeGfFYqFjtB6JwS0ejjff/AYXzy/Pyp ZF5EOo/fRZhOtQGAu1ix798otFPC33UCH579hSOcCpDGg3jxmUdXxXQgegxduQkw zOYLz8UXNv0dD9MkY1VbhZtnhUfN8uEwr9zdCwF8yuwHXlKcWywSxeZP3BUY4fkr 89jBoUQWhOw6e/tfauX5aKBtnuIikkYYVihBrmtt/Qad5/n2dzECpmeI7UW+klc2 Mwqa0ef+Yp+WNqCoFaj8Kc98oFdpoSucfFxERJpHQ7CaE6+P1bll9fgiZEMIz+uN fJTC64yIp+Kjn/O37Zijh47sruQKC3tR+5+soOG3GV8ZcflGmeBcUBdnQ8IcqD5g X/kmmYS48ejyhRzD7OGOMcVpIL+5eGi+gsprhbPmTCtQVGHYh32nD6VXYWwXXXs5 wGMT2pxxgwOEiYE1RQhnhLIEwxpj1D+3MjyzpqN3S9lGFoFk25vxnoz3FGyZaX4h 7wvFxKzVu2UDWwI574bit6v8VTiGzI8l9TCthQSnTcOd/tpPkPGKhGh5916Gt/Yi sfMbAbCOtVLwWYxGf1UW1m3t+XaXn0yKW3wID6iDcWP+RZEBN7g= =ydTv -----END PGP SIGNATURE----- --22hc2edju7gzauni--