From owner-freebsd-hackers@freebsd.org Sun Oct 6 00:02:15 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A65913FF7E for ; Sun, 6 Oct 2019 00:02:15 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 46m3h51kp9z4Gm0; Sun, 6 Oct 2019 00:02:12 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4FE2A3A5; Sat, 5 Oct 2019 20:02:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 05 Oct 2019 20:02:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=m7gZkWsopZeNUyDpj8BhOBDfpxQ T86fGmpm9xEiuJWc=; b=aq94+ycPsz+BKsag9jKBRuiJH2MosieZ3NO+xdUrI9G HnvXHaR4ut5qqzPuBKOSJqtXctgjByquGKDhfISJ3r5xbh+nDdgU07TK9GTIlTtG ETv7jwQJd8m4z5TOYG/efH1a2jzJF7RxXWnr4Fk/Lwar5KD4IiYqDW4tD8ASgaJP jaQ7B+Oyj4QA/b1L2FCL4dUg6JyiHpJeiabxAl43nFzt9RksklvtlMMFLheElvKo qG6/rsqJ4HZ5OKMsdLSLqXcU/q7sryYaRQwoGtPvirKkh6asz6SnkuGcyqkJiqYy tABL3SaRESvuQJ6Zoj2W5UV0BGHOma8kCIAamXOiMGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=m7gZkW sopZeNUyDpj8BhOBDfpxQT86fGmpm9xEiuJWc=; b=XQR62uNeEfvqZNL/3fmp+K 1ZSxbRluFaApLnlI6aGInyNUB5pvdlNhVgBTdPZxsUyOo6qRNsMinVqJ4g4NuPHm c0ow7Ig36X04sZmDlbXOQHzFbVv3gOHonz2BkNWC8k6z1dKMjia8gtqqN/57eDDI a84VsMHKKAN/jzJyN3Jfcenp6iiBgSotcGNjt1hQakyZvO6ZOk1Sf8IAZVZzM6xv jMNcOb9iyWz3z1REEMGBW7E81eEV7Zebd7oaE5e9LK1mjiw12wKvpFGZRzwasWsa NHc3L+ePJ2G/X23MwFei0oguvqNtP21xQEx1MRuiU/9BMydImTctsSyHRN9z3Bfw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheefgdduleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehgtd erredtredvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecukfhppeekvddrjedtrdeluddrleelnecurfgrrhgrmhepmh grihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: from bastion.zyxst.net (bastion.zyxst.net [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id E93668005B; Sat, 5 Oct 2019 20:02:09 -0400 (EDT) Date: Sun, 6 Oct 2019 01:01:40 +0100 From: tech-lists To: Dimitry Andric Cc: freebsd-hackers@freebsd.org Subject: Re: CPUTYPE?= in make.conf Message-ID: <20191006000140.GA24947@bastion.zyxst.net> References: <20191004141338.GA72749@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 46m3h51kp9z4Gm0 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=aq94+ycP; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=XQR62uNe; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.21 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-8.19 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-3.49)[ip: (-9.82), ipnet: 64.147.123.0/24(-4.90), asn: 11403(-2.68), country: US(-0.05)]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[21.123.147.64.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 00:02:15 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Oct 04, 2019 at 07:16:26PM +0200, Dimitry Andric wrote: >This is not a hardware failure, but totally expected behavior. You can >only run poudriere builds for CPUs of an equal, or earlier generation, >and even then you will have to ensure that the target CPU does not >accidentally support instructions from your host CPU. I was surprised to find that the sandybridge (Xenon E5-2690) would not comp= ile for CPUTYPE?=3Dbonnell (this is intel atom N450) as the N450 is a lot (2010) ol= der. But the haswell compiles for CPUTYPE?=3Dbonnell fine. This is what made me wonder if there's some kind of fault with the Xenon E5-2690. Or maybe it just can't use CPUTYPE?=3D properly? Does its use require any special capability of the host chip? If I don't put any CPUTYPE?=3D in poudriere's make.conf on the Xenon,=20 everything compiles as expected without error. Maybe I should just do this = ;) *** although I'm going to continue compiling for btver1 on the haswell as t= he resulting system feels more responsive. thanks, --=20 J. --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl2ZLvUACgkQs8o7QhFz NAXeWg//T0ioLGizzQ4D9v2ak1LiQqmlt/bq16bmWUOOloCh74ZvRyoNGReFW1j6 5VWIczF/XGbA3uN3soLZ8RTVAlMh9TymZkBNllQRZIKUzdv0flTPuoGOnDw/DiI1 69jMElJp3OfEc1avP8nH2NGwCdyMFPS7eKWabAd92RAA6H6gYUXeboqOjDjALeGT ZekjUyBEnKdR/FgTxIFu8ZiMbL4ld7bbwU6KYMDeJ05eB7u1RuHhl0sfZz74x9pV mWQdgWFixi/8lI+Nt9YR0BuDp9ZwWyMYgBH+DsxIDsFdt3H6i7hYkQjupROnuU93 O5UGw7/8RB//8ZW8AD6D/gnhIYZN+yHU6yHnqtnYJlQFPXw7fgsDRE5jJeQ7GJuR PLw+dQx8bQlnYU8avuUzE0anKIN+mCa4IXGw5CHDayjcI/c+JwBiIqpnMDSTV7zZ iS8kkFEuIc3luKoUvaM0tbuU1k4K0xZDfDX4596lRo+tmbMX0znDlIm9ChV5I7DB 3izSoJm/XaoRiqOx1z3p0tKxliCFWpGSfNvreYC+bpikrx1rH5zdt+WVhVY4BWa1 ZXx68V5+hVrEb+hDCIiqfdW6PD2JCSlwYobYqS15TKT38z5qLp1zkT9mGOeltxPQ etKr6ELydbW9YihU8k0xZw0khA0a6QbpBX9gDl5QApGQLIEgTyw= =qQI+ -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-hackers@freebsd.org Sun Oct 6 00:11:03 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7CB7214015B for ; Sun, 6 Oct 2019 00:11:03 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 46m3tG5tZSz4H1Z for ; Sun, 6 Oct 2019 00:11:02 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 89D842E7 for ; Sat, 5 Oct 2019 20:11:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 05 Oct 2019 20:11:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=Ea6zUr9VuBTr4Nw7T+xPZ6Vgxo9 Q/VhHEWXHoPsq+3w=; b=a2nQMWFEi+oBY8FVjdlzOm+4fOWOVRxxe2s5Z5Pd1Jf DwKMoQmQwKRHI8FBT7MJUBzrAedGUxN2+Qhf4eA9l6OjUbrmw+iRO0VWKZqsmA1f Xcv0gH0lvmaZxWBkYazznh4mNpba959KQrj49g2O4EWH3auI/lklfQBP4ZUOS3hC 1sDEcS3WoZGiHmW6F7q3yYQ89hxmQtcoSMd0ZTxD5eK97gSxoXPtRdJ5fNpKYgXc FCJDN3V7D/BrBOVUAHgTH9c2kCkEaJVFClgAJ8LNuDPctYQj0q0BeV/soIGdLqf5 topbIW91VnSJ+GIXLuL/6pjLnyegGeJxeaTUg3ksSnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Ea6zUr 9VuBTr4Nw7T+xPZ6Vgxo9Q/VhHEWXHoPsq+3w=; b=roqw098bhkSjDF0IU8TEgm v5Cf+2ZZri6bK5WmG/lIQ3hLEX+9dU/fFnsNyoFL214uYJUXkxzIVciadmZHyeIs GlL02bPiPg8GPB+g5HbSkBf7rpHGlD9DxHC5rg70MC9J0xq9zuOro82RRPu013Z+ SHknML3Nr+eJtnY00Idtjuzhbj7INKXBpmhM+7/oNLzkAo4CQFp+SrkTQERcXmmk t1seduZGxFEZjzTw3DUHfzlPvH0z1XUNUJZlMgKxxBEjIfXvYBDRXDDPR7q/YdMb I5NFO5SAlF1pmiUz0SXu3bCGiX7ARkzGZy5wf6abz+jVv+gTBgBBezQZT9wjCO3Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheefgdduleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehgtd erredtredvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecuffhomhgrihhnpegtphhusghoshhsrdgtohhmnecukfhppe ekvddrjedtrdeluddrleelnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhi shhtshesiiihgihsthdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from bastion.zyxst.net (bastion.zyxst.net [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 5EABE8005B for ; Sat, 5 Oct 2019 20:11:00 -0400 (EDT) Date: Sun, 6 Oct 2019 01:10:31 +0100 From: tech-lists To: freebsd-hackers@freebsd.org Subject: Re: CPUTYPE?= in make.conf Message-ID: <20191006001031.GB24947@bastion.zyxst.net> References: <20191004141338.GA72749@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 46m3tG5tZSz4H1Z X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=a2nQMWFE; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=roqw098b; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.21 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-8.19 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; IP_SCORE(-3.49)[ip: (-9.82), ipnet: 64.147.123.0/24(-4.90), asn: 11403(-2.68), country: US(-0.05)]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[21.123.147.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 00:11:03 -0000 --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Oct 04, 2019 at 11:14:28AM -0400, grarpamp wrote: >Intel.com says AVX extensions should be present in both. > >Does intel.com even publish per cpu or per family >exhaustive lists of all the instructions present? >ie: So users don't have to collate all the base instruction >plus extension set terminology docs separately. I don't know about exhaustive. I was using this: http://cpuboss.com/cpus/Intel-Xeon-E5-2690-vs-Intel-Core-i7-4770K The other way of getting them is installing sysutils/cpuid and running that. You're right about AVX, that's my error. thanks, --=20 J. --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl2ZMRIACgkQs8o7QhFz NAVRaw/9FYHrpZeOXBEDAB8uQvevtTSYYax6c8v+B1hSBiYXCk5r/SsW+nZHxKOS q4hJEHh8X0X8RMBy4TbUQMMltmW26UDWU/bI+Wv5TmqBK9QfdyP3DMl6lF3A+y2D iJa51wHa3TZByeLOAAaRIK+SDvhmGCQDLgpEsPDp16sZlM4Jo/AlSA3HPPtRq5XT ygHlFLzrLmYBY4USzWFM29SecRJjoEf5lSNkMpMy+cFDKRFAriwXkCS8yPNt0i8g RNWggfAyIPSq4b2NFJjYxzS+APnW8DD7US2XYdOmE/FmluVpG/5TWsTdb6PsBLet kctC1bEOI78F1QIZl6TesAPsLgQRi5mJy5nX+3cr5sT6W62aADwRYZ0gD1IB1y41 +Y+knBHZ3V3PwUq6MuFoQP6zI4i9+Wmu4PBOv5bt2SVagsTT/R//64trJVU4pjhR c/CKMUppWIACuAHFiip7Jm8TUVEUM4cf3is7AO1p38kCNt9xbysZ+GUaoi1BQ9dN mJtiFw0NS0QlnQbndYl/gX3aOCiWuRNX6KmWd/9bjePekSEPf0vn0RPi+EbCyES7 LfmJgsdjPGMNpYlFTm9kz5QiiWf84NHhY32kOgDh3dJFEPPa08J5gQ8jztomkU9f QXiI/ruKfBL7dHrt4zINoffjTrhnzWtfODWJ5bSqVadfioXGc3g= =Zhq3 -----END PGP SIGNATURE----- --b5gNqxB1S1yM7hjW-- From owner-freebsd-hackers@freebsd.org Sun Oct 6 07:56:13 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 338BD12FE63 for ; Sun, 6 Oct 2019 07:56:13 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46mGC014xTz3Hvm for ; Sun, 6 Oct 2019 07:56:11 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pf1-f174.google.com with SMTP id q12so6510797pff.9 for ; Sun, 06 Oct 2019 00:56:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=USOOMlL57OE39VyIRlOCwn54De1RaFHX4FBiJmcfan8=; b=qH5F0akoGtbBzSNMdMbmkbYKk38DXus0SVkkSJ/haqtPIB2H8EHckrSw2ahVcZyqrq kCNgKArtcpIRKE1Oz1JNLHmmAb84vScQdsTzSxairN0AdmN1hR0wgmM2IRZ89QWbmJ77 gpfgzW7XARXEQwB6kM5DFkRiARyl8CSU6oC/BnKkb3hzPiUGLmJqKafaaFw2TOSddENx ZYvFAjEVOie1M5yFCQXB2ylEkFhY3tl55pvuXk+/R49ryEIo/5eU0ntgSJwEXi+WQgSC k50Dvrymv8LFWAU2SgRmaR+lv4FzbQexxnnRJA1ls81W54P5LULxyj8fyWnHLmp6HW/O DLHg== X-Gm-Message-State: APjAAAXS/KNDXLzcOt4N1vud3XFVS70iRghUf9KKiHUrw1D8DIaoVIUm VSBWGlgfcMrFJRkBDNPA9aoRRY5X5kk= X-Google-Smtp-Source: APXvYqx2GCqH75jbBlar8o+18jwLfpNzv4ohdZ+haRlAtORYXzrCVUX+0XxD0WNaTKTy4/rjza6C6w== X-Received: by 2002:a62:7d54:: with SMTP id y81mr26616987pfc.86.1570348570389; Sun, 06 Oct 2019 00:56:10 -0700 (PDT) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com. [209.85.210.176]) by smtp.gmail.com with ESMTPSA id 22sm11106983pfo.131.2019.10.06.00.56.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Oct 2019 00:56:10 -0700 (PDT) Received: by mail-pf1-f176.google.com with SMTP id b128so6553614pfa.1 for ; Sun, 06 Oct 2019 00:56:09 -0700 (PDT) X-Received: by 2002:a17:90a:1c01:: with SMTP id s1mr26903429pjs.76.1570348569673; Sun, 06 Oct 2019 00:56:09 -0700 (PDT) MIME-Version: 1.0 References: <20191004141338.GA72749@bastion.zyxst.net> <20191006001031.GB24947@bastion.zyxst.net> In-Reply-To: <20191006001031.GB24947@bastion.zyxst.net> From: Gleb Popov Date: Sun, 6 Oct 2019 11:55:34 +0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CPUTYPE?= in make.conf To: tech-lists Cc: freebsd-hackers X-Rspamd-Queue-Id: 46mGC014xTz3Hvm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-4.04 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; URI_COUNT_ODD(1.00)[5]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[174.210.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.04)[ip: (-9.73), ipnet: 209.85.128.0/17(-3.26), asn: 15169(-2.15), country: US(-0.05)]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; SUBJECT_HAS_QUESTION(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 07:56:13 -0000 On Sun, Oct 6, 2019 at 4:11 AM tech-lists wrote: > Hi, > > On Fri, Oct 04, 2019 at 11:14:28AM -0400, grarpamp wrote: > > >Intel.com says AVX extensions should be present in both. > > > >Does intel.com even publish per cpu or per family > >exhaustive lists of all the instructions present? > >ie: So users don't have to collate all the base instruction > >plus extension set terminology docs separately. > > I don't know about exhaustive. I was using this: > http://cpuboss.com/cpus/Intel-Xeon-E5-2690-vs-Intel-Core-i7-4770K > > The other way of getting them is installing sysutils/cpuid and running > that. > > You're right about AVX, that's my error. > Some time ago I wrote sysutils/hs-cputype utility, which infers you CPU type from clang's output, coerce it to CPUTYPE possible values and prints that to you. It also allows you to compare two CPUTYPEs in terms of features. > thanks, > -- > J. > From owner-freebsd-hackers@freebsd.org Sun Oct 6 15:31:04 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0F31C12D2D0 for ; Sun, 6 Oct 2019 15:31:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46mSHp078gz4VNt for ; Sun, 6 Oct 2019 15:31:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=tPdUanUmSaPsRO6yM37E4K7DqmI+oB91MDMAvCn0wx8=; b=oItLFl1PySi1/q8yNl9inMsa2z3V80snRlwXmil1tgiPWPhO6guJVtGUXdgndlAQRXFqzI6yJic9m1P3f88WAh3oTv3Sr3rUl7qe4D21VS0EsdhlZ1odBvNiWdkc43FkrEVLOemuW7xb01seWHVi6UZ9t00IdYBXR8TwVLJwHLsMaye0ZGPcSV2PGTqKvg2Hw+udwG2U+L/wChCfjammlKpmLdOWEJuweLfTmGWqqx77LmQM9WWtoPbyGhip0+zn1o+1zG/rCLtfYFm00odzcFgFIH8wYSZaejLfNC5w0gR0Wd/PpQcFE8NjIC/KviqJLAfNI4O47mBNObZCivCbcg==; Received: from macmini.bk.cs.huji.ac.il ([132.65.179.19]) by kabab.cs.huji.ac.il with esmtp id 1iH8Ur-000Mt8-6t; Sun, 06 Oct 2019 18:30:57 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: vsftpd: very strange bug? From: Daniel Braniss In-Reply-To: Date: Sun, 6 Oct 2019 18:30:56 +0300 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B6ED526-08BD-43EE-A11B-0C948F97A190@cs.huji.ac.il> To: "O'Connor, Daniel" X-Mailer: Apple Mail (2.3594.4.19) X-Rspamd-Queue-Id: 46mSHp078gz4VNt X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=oItLFl1P; dmarc=none; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-0.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.876,0]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.99)[-0.987,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[huji.ac.il]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[210.116.65.132.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.26)[ipnet: 132.64.0.0/13(-0.74), asn: 378(-0.60), country: IL(0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 15:31:04 -0000 > On 4 Oct 2019, at 13:08, O'Connor, Daniel wrote: >=20 >=20 >=20 >> On 4 Oct 2019, at 15:08, Daniel Braniss wrote: >> I=E2=80=99m trying to run vsftpd for anonymous use, and have this = very strange behaviour: >> on host A it works just fine, but on on any other host it does not. >> the binary is on a nfs server, the chdir is also to a directory on = nfs, all host run the same root image FreeBSD 11.3. >=20 > Is maproot different in the exports line for those 2 hosts? there the same :-( i wrote a small test program, and it acts correctly! so there is = something weird going on in vsftpd. thanks danny >=20 > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum >=20 >=20 From owner-freebsd-hackers@freebsd.org Sun Oct 6 17:51:33 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0CDB8130195 for ; Sun, 6 Oct 2019 17:51:33 +0000 (UTC) (envelope-from neel@neelc.org) Received: from nyc1.neelc.org (nyc1.neelc.org [IPv6:2a0d:5600:33:11::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46mWPv6knpz4dj6 for ; Sun, 6 Oct 2019 17:51:31 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (nyc1.neelc.org [IPv6:2a0d:5600:33:11::2]) by nyc1.neelc.org (Postfix) with ESMTPSA id 6D43614DE4E for ; Sun, 6 Oct 2019 13:51:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 06 Oct 2019 13:51:22 -0400 From: Neel Chauhan To: freebsd-hackers@freebsd.org Subject: Reviewing Bugzilla #241088 (netinet: Move request window scaling computation to tcp_output()) Message-ID: <1cf5a691a66570fed0e7bd45f46e8db3@neelc.org> X-Sender: neel@neelc.org User-Agent: Roundcube Webmail/1.3.9 X-Rspamd-Queue-Id: 46mWPv6knpz4dj6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 2a0d:5600:33:11::2 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-2.66 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[neelc.org]; IP_SCORE(-0.46)[asn: 63473(-2.24), country: US(-0.05)]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:63473, ipnet:2a0d:5600:33::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 17:51:33 -0000 Hi freebsd-hackers@ mailing list, Would someone be willing to review my patch in Bugzilla #241088 (netinet: Move request window scaling computation to tcp_output())? Please find below the links: * Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241088 * Phabricator: https://reviews.freebsd.org/D21907 Best, Neel Chauhan === https://www.neelc.org/ From owner-freebsd-hackers@freebsd.org Mon Oct 7 04:58:34 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2C26513E0BD for ; Mon, 7 Oct 2019 04:58:34 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46mpCY0BY4z4GM0 for ; Mon, 7 Oct 2019 04:58:32 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: by mail-ot1-x32a.google.com with SMTP id c10so9876467otd.9 for ; Sun, 06 Oct 2019 21:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=soBfot5eiMPh2eiIGsnnPUtn9sSjuHE8qfCN/7NLlMs=; b=tJh5JCLghP2/PifG/GaqAzqYkOPPf/qyLYQskkhHLgOc6dxmwdiUzHhe7PnfoT2LrD B9s1koqH5R7O75ZzTrUNbeiyiX7HeAP5uH6VYY6nP9JkbKaCw1J50dta7Txu9bxsaNzm 1QWixZ8z/GUYulGPCVcl3ZH1nAmdooodAsDaJ7C16zpLeykkE5QJa1+zmFlQwm9pfhv9 z+aAcl3Xybxk86XSgzamq55cRsJY/TZJB7D674FlYaBkv5wnOpUV1tlZDk5F7PXaD5nH 51+wE/NocR6Rqkvb57Yrrcutau6Ic2d1HHEOnCpGiEu3ftrIFC9QUUj0KA4vimJDrTFO iJjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=soBfot5eiMPh2eiIGsnnPUtn9sSjuHE8qfCN/7NLlMs=; b=bjiA8ViCZU63SNzfWzXjbmnUKwgqXN7oxFqUoBGApLWJvYkdtwJjn+h7WXT1ZEYlPJ PhYkoj2rgBFvZou3eWTfOtj7zzj1y0zU5FPsw7DVYY/8m/gzizYXPUsQErFWwo67AxNW ku6VkuXJMxJeU1NOBNJ/X2wRDVRMq0cJHCLXgeB5lMZPZI2DF2cN9eP4Kgv82quewUfu NvCjzldte7L7gOr9cP78urcPm/ZJDsJNsM+ILyJS9kYZaLC/t4Wbb31RkqtpfRRy7mrV o5P7leZq1xwLDmL5svdqgOGOdRJES1Bj3KLYCZt/iiOMSVZZ/7ZK9ZRuIWPnkefj/DD+ yP3g== X-Gm-Message-State: APjAAAW1oR0KfJlSyKWpMeWVhTcV/KgQdsjINEHxBNaQdt/BHp8lgMlP t/xXlJ5XZp+L+ptwa9aqOPs9+PnqNq6Ed0ilAW4ZH+vh X-Google-Smtp-Source: APXvYqzCMF6+ktB+mn5jsI9MvhNs154TglsR9LHlCwGXqo/ABch/Ycob1wNVQfFRMqrkxjnEY41YbB6cXyDiVsVkU+Q= X-Received: by 2002:a9d:a63:: with SMTP id 90mr18933676otg.164.1570424311432; Sun, 06 Oct 2019 21:58:31 -0700 (PDT) MIME-Version: 1.0 From: David Cross Date: Mon, 7 Oct 2019 00:58:20 -0400 Message-ID: Subject: uefisign and loader To: FreeBSD Hackers X-Rspamd-Queue-Id: 46mpCY0BY4z4GM0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=tJh5JCLg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dcrosstech@gmail.com designates 2607:f8b0:4864:20::32a as permitted sender) smtp.mailfrom=dcrosstech@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-7.89), ipnet: 2607:f8b0::/32(-2.55), asn: 15169(-2.15), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[a.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 04:58:34 -0000 I've been working on getting secureboot working under freebsd (I today just finished off a REALLY rough tool that lets one tweak uefi authenticated variables under freebsd, with an eye to try to get a patch to put this into efivar). After setting the PK, the KEK, and the db, I was super excited to finally secure-boot my machine, and discovered that I could not uefisign loader. Attempting to sign loader returns a cryptic: "section points inside the headers" and then hangs in pipe-read (via siginfo). (this is under 12.0 FWIW). I am able to sign boot1, however boot1.efi doesn't handle GELI keys so its not really useful for me. Suggestions? From owner-freebsd-hackers@freebsd.org Mon Oct 7 05:02:57 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DFAE813E61A for ; Mon, 7 Oct 2019 05:02:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46mpJc6Sbrz4H2D for ; Mon, 7 Oct 2019 05:02:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82b.google.com with SMTP id e15so2593408qtr.4 for ; Sun, 06 Oct 2019 22:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=09uzxkp3Gty+dPpblz19wuH3VHQNNBEylcgmSiHizrY=; b=ftYXtlHadoAzQoBAfXcpF8+08lI7jDbnzuWxYQXZzi22jqSGYU4wZNIqSfH8HamBX5 i2Z+uzaVn3LCjL6qoTrw5Q2YIRF2LFi91L3I42PsKU0XMXg7LN+seYGSJY9GCClmLzlF 22JQiUIrZmS+ml660CX6jRfbrbk/ga4x+L2enPXYX8QiJAiHSOKid5af8M4ZBMd83NZu CMe2BeYwSJzApi9ZtKbxhVnB4M4rw2viYHz1W+9fnfVHIgXrMXQS3SuRBiEEePYZ7nlS j3uN7EBJ4Bn6okY1qt8LWdVFqDOuPP3obc8IMQOB26Rc5S4PNO7Cxsw0qme7bVr4Yxib GgtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=09uzxkp3Gty+dPpblz19wuH3VHQNNBEylcgmSiHizrY=; b=J+QtUOjN4cTLxqvgDb9cd+Xr++NCv+zMjYA2jBMNe90RhKrEvWeGGl+9HT/h+T5iWj VwqAjz04M+UVbfNCvCHdxLJ3CKo7LroK2bOXOwKkNhJ/SZY6TLTQfgqPnBTV28h4gR/F nQP9IaprdI3UpPUTf9q+FAN7sK/6y3zQgcXhC5sZO+VY3de4eQtX1gbGuUPeuN75JXMn 18ZtfLv4JCaRiz/Y5rWGAQVW1bKxoN2tc/4DlYZZd66caXvBa1LwhyOP+lN5kt5E0Qnp VYrRupj6hysBO1O7j0WK4Gwr/2EHEjnD2jDBBs6k7ykqczR2t6YtcHifz1SkwMv9Ig+a mKZQ== X-Gm-Message-State: APjAAAW5oEhmUg6xzqWmijQ/CVkJW8iHsii2US1qNPMZ2YRs4ASSpMe8 wAtRA9Ko5kmfswFZacHTfAtOVPkwcTG3ANAAzFJaunQP X-Google-Smtp-Source: APXvYqz2P0RW7Ee3mjR8nZ50vovInGCgNTftmGJRv3eu4uYUuODGYwRNjlTEfjO7FS2b5dzoOxvYkqI38VarDGrdJiE= X-Received: by 2002:ac8:3564:: with SMTP id z33mr28097976qtb.291.1570424575505; Sun, 06 Oct 2019 22:02:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 6 Oct 2019 23:02:43 -0600 Message-ID: Subject: Re: uefisign and loader To: David Cross Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 46mpJc6Sbrz4H2D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ftYXtlHa; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::82b) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.83 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[b.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.83)[ip: (-9.39), ipnet: 2607:f8b0::/32(-2.55), asn: 15169(-2.15), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 05:02:57 -0000 On Sun, Oct 6, 2019, 10:58 PM David Cross wrote: > I've been working on getting secureboot working under freebsd (I today just > finished off a REALLY rough tool that lets one tweak uefi authenticated > variables under freebsd, with an eye to try to get a patch to put this into > efivar). After setting the PK, the KEK, and the db, I was super excited to > finally secure-boot my machine, and discovered that I could not uefisign > loader. Attempting to sign loader returns a cryptic: "section points > inside the headers" and then hangs in pipe-read (via siginfo). (this is > under 12.0 FWIW). > > I am able to sign boot1, however boot1.efi doesn't handle GELI keys so its > not really useful for me. > > Suggestions? > Use loader.efi directly instead? Warner > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Oct 7 07:43:09 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EBAB1F9DB4; Mon, 7 Oct 2019 07:43:09 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46mssS5FCtz4PNS; Mon, 7 Oct 2019 07:43:08 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-io1-xd44.google.com with SMTP id c25so26354255iot.12; Mon, 07 Oct 2019 00:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U8VnsNCGQag82DKgQZKjyNayOQ84NuSUYRyOjAwTieE=; b=dDYaF8ndmmZFe4sWKj+/LPaQyknvyEvvoJ6+AZ1HHnJghIrCrhDoWwQA0mORdBKrw9 CJ6cGVkIO12nUMv7s/dUmlIvJGqq73txKNnqJj2TxstvzsgXdNApjcoiwdz+jqOnz5JY 5qZV6vgRFWyC9X48ifnLvf5Zeu9nGOtevhbx60BMuXnTEw8WH2fSm7iv03DofOL4OSSP hJk+m8powgTiBsAVGkT5J/EZvXczxxwvQ/mdc6zNdUbzsLl9NzKoZxN6WDFSt60ggr9T JR17wpeBB9NvzotFwIptHe49ewtG51aJT7uk6/4LVvzVYmLAmK9X0NHgKS89fWuu8rYG EyZQ== 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=U8VnsNCGQag82DKgQZKjyNayOQ84NuSUYRyOjAwTieE=; b=SIPSfYA/OnBbU//jRd1BUv7pWI5Jpjz/PBtEg79TxhKcW2qXkiCGGYZPM1MbkfLTwf g7t63U7eWPZXxwgiwoKh1aL2K4RWRFCS0taV2JcvRNy8LlKQojSczCWMO7geOmhrJpxJ ZLH+KgXbRo6F2uAA+3qUWsG2zuDsZxqRlODOgw21r8TITzcabx7sxrLzgIlPQ0OvO+JT KKzEZLV24jKXxgooTYoFrZJmal0WmFidMe0VZrjApAfmpbcBlNf0ZD/QlqPpLNJk7f7y K9iI450ggAnRyOTEV8BzwWNVeq2t97mkiSwEXlD4oxriMyy+fVjde51WDHXKvpW5rQlv 9q4w== X-Gm-Message-State: APjAAAU+qsdf7z0loOJs3hU6H/2PCgvu08MaRDpcyPpd/WgcpT9gDcl7 KUeElAAmjHhayaLuW0kCesrDr4lDMIQ2V83Bc7db8ttC X-Google-Smtp-Source: APXvYqw//rlGXkVUEHgQeNG+enBUytlvevfIOd9BlxTlEjm6yg08DIfsaIXn1jv/7qoEvU9zQEBGuHcznUA+pGZ0WLc= X-Received: by 2002:a5e:aa09:: with SMTP id s9mr23738904ioe.22.1570434187286; Mon, 07 Oct 2019 00:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9f01:0:0:0:0:0 with HTTP; Mon, 7 Oct 2019 00:43:06 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Mon, 7 Oct 2019 03:43:06 -0400 Message-ID: Subject: Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based To: freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 46mssS5FCtz4PNS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=dDYaF8nd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::d44 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.00)[ip: (2.27), ipnet: 2607:f8b0::/32(-2.55), asn: 15169(-2.15), country: US(-0.05)]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[4.4.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 07:43:10 -0000 On 10/4/19, Igor Mozolevsky wrote: > On Fri, 20 Sep 2019 at 22:01, grarpamp wrote: >> >> For consideration... >> https://lists.freebsd.org/pipermail/freebsd-security/2019-September/010099.html >> >> SVN really may not offer much in the way of native >> internal self authenticating repo to cryptographic levels >> of security against bitrot, transit corruption and repo ops, >> external physical editing, have much signing options, etc. >> Similar to blockchain and ZFS hash merkle-ization, >> signing the repo init and later points tags commits, >> along with full verification toolset, is useful function. > > > > > Isn't UNIX(TM) philosophy that a program should do one thing and do it > well? Just because people can't be bothered to learn to use multiple > tools to do *multiple* tasks on the same dataset, is not a reason, let > alone "the reason," to increase any program complexity to orders of > N^M^K^L so that one "foo checkout" does all the things one wants! Was r353001 cryptosigned so people can verify it with a second standalone multiple tool called "PGP", after the first standalone multiple tool called "repo checkout"? Was it crypto chained back into a crypto history so they could treat it as a secure diff (the function of a third standalone multiple tool "diff a b") instead of as entirely separate (and space wasting set of) unlinked independant assertions / issuances as to a state? How much time does that take over time each time vs perhaps loading signed set of keys into repo client config. Is LOGO and tape better because less complex tool than C and disk. > When crypto invalidates a repo, how would it be different > from seeing non ASCII characters in plain ASCII files, or sudden > refusal to compile > one way or another you'd still need to restore > from BACKUP Backup is separate, and indeed a fine practice to help keep for when all sorts of horrors can happen. > crypto IS NOT a substitute for good data keeping > practices. Who said that it was. However it can be a wrapper of proof / certification / detection / assurance / integrity / test over them... a good thing to have there, as opposed to nothing. > Also, what empirical data do you have for repo bitrot/transit > corruption that is NOT caught by underlying media? Why are people even bothering to sha-2 or sign iso's, or reproducible builds? There is some integrity function there. Else just quit doing those too then. Many sources people can find, just search... https://www.zdnet.com/article/dram-error-rates-nightmare-on-dimm-street/ http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf http://www.cs.toronto.edu/~bianca/papers/ASPLOS2012.pdf https://www.jedec.org/sites/default/files/Barbara_A_summary.pdf https://en.wikipedia.org/wiki/Data_degradation https://en.wikipedia.org/wiki/ECC_memory https://en.wikipedia.org/wiki/Soft_error Already have RowHammer too, who is researching DiskHammer? Yes, there does need to be current baseline studies made in 2020 across all of say Google, Amazon, Facebook global datacenters... fiber, storage, ram, etc. It is surely not zero errors otherwise passed. Then note all the users who do not run any media, memory, and cables capable of detecting and or correcting garbage. And the claims or data, about "checksums / digests / hashes" that fall short of at least 2^128 odds that strong crypto based repositories can provide. Many do not, and should not, accept less as sufficient standards. What is the worth of your data and instructions producted with some software from some repositories from some hops. Though error is only part of entire possible subject, still however... Lower some risks there too by raising some crypto bars. Be sure to expand "external physical editiing" hinted to include malicious, even by both local and remote adversarial actors, and or those acting outside of established practice. Some crypto repositories require additionally compromise of committer and or distribution private key to impart trust downstream, all of which leaves nice audit, instead of just sneaking in a "vi foo.rcs" or binary equivalent. Cryptographic defense in depth, not prayer. [Sorry not sure which is better mail list] From owner-freebsd-hackers@freebsd.org Mon Oct 7 10:58:42 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6134712AD95; Mon, 7 Oct 2019 10:58:42 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46myC52Vd1z3MFb; Mon, 7 Oct 2019 10:58:41 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id g13so10550845otp.8; Mon, 07 Oct 2019 03:58:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZQglkprzouiwdiyAqljwW4pNNdxzzgvG/tHZdTtHdaU=; b=kWXM75kO1SxWARv4a3o10n3Ix+8f7RzsuCToBRnDzipBJ8tBP/mndA+83GEd3ewP0I cHgTKJ+lubq7QvgjtJtgcHNuCsQ0tXMzxmtP1ENjnpH0ABkNUDe/tlRJpwXCMTaF8GN+ /a3Aj75biS8V7/tJaDn1c17UCdw3uT3FLVbcfXhSWHCtxamF7jPmk0VVK5yEFGhVPNyW J1OCnwU6Nf7uIGlyaPu16S6kT+BGZAPzJDLf25Poyc3QAk+txFDbXt3EeuZHAForruNt wL/WBOpmbnlqaYbQGTg5FtH1UTYXyc5uuwwh/kfIML/UPOPA129Lg++tiV13maaN2tNI kzQw== X-Gm-Message-State: APjAAAV/YZM28xdYFcPtkfffpru8FfJ6G4lkntsx27Z23kUysN+PjXj8 9FUcdNiKHWCR/C38rB1XZTsjemYvrgaV+hjPijo= X-Google-Smtp-Source: APXvYqxqjKwyq2Gd531raW3AljdxW03f+jemi8TfQhP1/wW0XvWTxTQOEtS8WiW6KKETkJXNjj/cyLRCGG+KBLe476k= X-Received: by 2002:a05:6830:22d7:: with SMTP id q23mr20407346otc.65.1570445919800; Mon, 07 Oct 2019 03:58:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Igor Mozolevsky Date: Mon, 7 Oct 2019 11:58:03 +0100 Message-ID: Subject: Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based To: grarpamp Cc: freebsd security , Hackers freeBSD , freebsd-questions@freebsd.org, freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 46myC52Vd1z3MFb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mozolevsky@gmail.com designates 209.85.210.44 as permitted sender) smtp.mailfrom=mozolevsky@gmail.com X-Spamd-Result: default: False [-3.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[hybrid-lab.co.uk]; RWL_MAILSPIKE_GOOD(0.00)[44.210.85.209.rep.mailspike.net : 127.0.0.18]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[44.210.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.17)[ip: (-0.41), ipnet: 209.85.128.0/17(-3.26), asn: 15169(-2.14), country: US(-0.05)]; FORGED_SENDER(0.30)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 10:58:42 -0000 On Mon, 7 Oct 2019 at 08:43, grarpamp wrote: > > On 10/4/19, Igor Mozolevsky wrote: > > On Fri, 20 Sep 2019 at 22:01, grarpamp wrote: > >> > >> For consideration... > >> https://lists.freebsd.org/pipermail/freebsd-security/2019-September/010099.html > >> > >> SVN really may not offer much in the way of native > >> internal self authenticating repo to cryptographic levels > >> of security against bitrot, transit corruption and repo ops, > >> external physical editing, have much signing options, etc. > >> Similar to blockchain and ZFS hash merkle-ization, > >> signing the repo init and later points tags commits, > >> along with full verification toolset, is useful function. > > > > > > > > > > Isn't UNIX(TM) philosophy that a program should do one thing and do it > > well? Just because people can't be bothered to learn to use multiple > > tools to do *multiple* tasks on the same dataset, is not a reason, let > > alone "the reason," to increase any program complexity to orders of > > N^M^K^L so that one "foo checkout" does all the things one wants! > > Was r353001 cryptosigned so people can verify it with > a second standalone multiple tool called "PGP", after the > first standalone multiple tool called "repo checkout"? > Was it crypto chained back into a crypto history so they could > treat it as a secure diff (the function of a third standalone multiple > tool "diff a b") instead of as entirely separate (and space wasting > set of) unlinked independant assertions / issuances as to a state? > How much time does that take over time each time vs > perhaps loading signed set of keys into repo client config. I'm guessing they are rhetorical questions; but you ought to look up how to do tool chaining in any flavour in UNIX(TM). > Is LOGO and tape better because less complex tool than C and disk. For some people, perhaps. > > crypto IS NOT a substitute for good data keeping > > practices. > > Who said that it was. However it can be a wrapper of > proof / certification / detection / assurance / integrity / test > over them... a good thing to have there, as opposed to nothing. What is the specific risk model you're mitigating---all you say is hugely speculative?! > > Also, what empirical data do you have for repo bitrot/transit > > corruption that is NOT caught by underlying media? > > Why are people even bothering to sha-2 or sign iso's, or > reproducible builds? There is some integrity function there. > Else just quit doing those too then. Funny you should say that, Microsoft, for example, don't checksum their ISOs for the OSes. You missed the point about reproducible builds entirely: given code A from Alice and package B from Bob, Charlie can compile package C from A and verify that C is identical to B, a simple `diff' of binaries is sufficient for that! The problem is that a lot of the time code A itself is buggy to such degree that it's vulnerable to attack (recall Heartbleed, for example). Crappy code is not mitigated by any layer of additional integrity checking of the same crappy code! > Many sources people can find, just search... > https://www.zdnet.com/article/dram-error-rates-nightmare-on-dimm-street/ > http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf > http://www.cs.toronto.edu/~bianca/papers/ASPLOS2012.pdf > https://www.jedec.org/sites/default/files/Barbara_A_summary.pdf > https://en.wikipedia.org/wiki/Data_degradation > https://en.wikipedia.org/wiki/ECC_memory > https://en.wikipedia.org/wiki/Soft_error I don't bother with second-hand rumors on WikiPedia so I'm not even going to bother looking there, but as for the rest, seriously, you're quoting a study of DDR1 and DDR2??? I have it on good authority that when at least one manufactured moved to smaller die process for DDR3 they saw the error rates plummet to their own surprise (as they were expecting the opposite) and now we're on DDR4, and what's the die size there?.. Perhaps you need to look into the error rates of EDO RAM et al too? In any event, ECC, integrity checking etc is done on the underlying media to detect and in some cases correct errors so you have to worry less about it at higher levels, so getting so obsessed by it is just silly especially advocating for a tool to do it all in one go! Here's a question to ponder: if code set X, certificate Y, and signed digest Z are stored on one media (remote server in your case), and your computed digest doesn't match digest Z, what part was corrupt, X, Y, or Z, or your checksumming? > Already have RowHammer too, who is researching DiskHammer? And RowHammer has been successfully demonstrated in a production environment? How exactly are you planning on timing the attack vector to get RAM cell data when you (a) don't know when that cell will be occupied by what you want, nor (b) where that cell is going to be in the first place? Go ask any scientist who works for pharma to explain the difference between "works in a lab" and "works in the real world"... > Yes, there does need to be current baseline studies made > in 2020 across all of say Google, Amazon, Facebook global > datacenters... fiber, storage, ram, etc. It is surely not zero > errors otherwise passed. Perhaps you need to "tell" Google, Amazon, Facebook, et al about that, and then come back to us with the results of those studies? To sum up, you're advocating for extra effort with no empirical data nor a decent risk model to justify the effort, good luck! -- Igor M. From owner-freebsd-hackers@freebsd.org Mon Oct 7 13:29:20 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5665112F85A for ; Mon, 7 Oct 2019 13:29:20 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46n1Xv202dz41qf for ; Mon, 7 Oct 2019 13:29:19 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: by mail-ot1-x335.google.com with SMTP id g13so10923262otp.8 for ; Mon, 07 Oct 2019 06:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SLSuRM2sDV8XiJ2+JfPzei6zUyOIX2nseen1S2F/EFE=; b=eAcJWT3YMAVF6QcCnoTF0JNlHgi7Uj1VjYegOW1gps0gEZd6WllsKSWxWet560VD95 5BNlpAtIrlH9YoJwOzgKINT5a5CKGbjhkNRGB8ufO/KElWNRtcPPDcQdTvAYu9OlwFVk BbGmmsMsaetKflu7m+vof4xu4rouzIamI355/3YfuojmPfi2+Uzo6KnrE4ZqON/wg+Gg DTDwzKUuBb4u+a+mSz3fK5pIxObsNYBFdCkCaHClYKG/hRT0w7PcCfG4Nh1cNkbZoTSW 6XsryXUXpKmKzqQuXTz+y6AR4+nSS3y8JkyvCyocCBVCIPzkOtRqvyMNMqOTKfW3+9sj pRTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SLSuRM2sDV8XiJ2+JfPzei6zUyOIX2nseen1S2F/EFE=; b=li8RbPap+h9KgkkWHOxGR7YypwudsNDch3VRKHmVPPzZdXnPEjYLQF76iq2WSWqEZz I3EzyCY1NcvyyCkH64VSEkdfpAS2mZEKNLHmMpsxZhEcI84c70zl8bpyGF1QmFXnkM75 RA0/Y98MRj/ohnJgPNL3q5Fz3y5Erl7RDp8FSYRBcPefOZwgdSuD5ytYwqWHnQI6txGb 07WBkpgxvBm8oYKDARPxiigesAHFDqEdVu2BC8O/Lurn6JRAYf0aexTCh9l/b32sp19J 897xsSAX+mHylq0oNNje0Im3bw4MFQS/l1n0p5F9KOn+48vhRQlJNWCM8shvpKVTUjEY 59Dg== X-Gm-Message-State: APjAAAVWKtj+J7UDrvvkuwRb0fmy9QWYvQYJSBsnGFWUpUe7pImbYxAL RVgRp78tnDZz8nBUCEh8WhJJ3KIADyxOTxlju/2L2g== X-Google-Smtp-Source: APXvYqwkRfUWtuo5TUApWTDcOYORX+tqc0sz8tA18llFOu/4qMrgUli+Rzoq2xHgCNCkAwZO3chJWy6/Mnc10ZiEea0= X-Received: by 2002:a05:6830:1bda:: with SMTP id v26mr21348262ota.139.1570454957547; Mon, 07 Oct 2019 06:29:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Cross Date: Mon, 7 Oct 2019 09:29:06 -0400 Message-ID: Subject: Re: uefisign and loader To: Warner Losh Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 46n1Xv202dz41qf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=eAcJWT3Y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dcrosstech@gmail.com designates 2607:f8b0:4864:20::335 as permitted sender) smtp.mailfrom=dcrosstech@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[5.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(0.00)[ip: (-7.27), ipnet: 2607:f8b0::/32(-2.55), asn: 15169(-2.14), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 13:29:20 -0000 On Mon, Oct 7, 2019 at 1:02 AM Warner Losh wrote: > > > On Sun, Oct 6, 2019, 10:58 PM David Cross wrote: > >> I've been working on getting secureboot working under freebsd (I today >> just >> finished off a REALLY rough tool that lets one tweak uefi authenticated >> variables under freebsd, with an eye to try to get a patch to put this >> into >> efivar). After setting the PK, the KEK, and the db, I was super excited >> to >> finally secure-boot my machine, and discovered that I could not uefisign >> loader. Attempting to sign loader returns a cryptic: "section points >> inside the headers" and then hangs in pipe-read (via siginfo). (this is >> under 12.0 FWIW). >> >> I am able to sign boot1, however boot1.efi doesn't handle GELI keys so its >> not really useful for me. >> >> Suggestions? >> > > Use loader.efi directly instead? > >> >> I currently do use loader.efi directly, however not being able to sign loader.efi directly complicates things a bit (using hash based signature lists for the 'db' variable); and it seems we *should* be able to sign loader. From some other posts on the internet it seems that at some point we could. From owner-freebsd-hackers@freebsd.org Thu Oct 10 18:29:51 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B82A5145ECF for ; Thu, 10 Oct 2019 18:29:51 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46q04G4pgZz4QJc for ; Thu, 10 Oct 2019 18:29:50 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: by mail-oi1-x232.google.com with SMTP id a15so5810221oic.0 for ; Thu, 10 Oct 2019 11:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vyxyOmI7Dcn7lkpo+nJITq7keQTJTljrcH1q4jRbBa0=; b=AShwmQj0DFAICqDUHVjLy0vCEsfc5GVb443RadRx1TXIrg0YoZ74xDpHnVN+YrRtVx JF1N6jCl98MmbX3G74EJ0CiDGz4meGS5wwINbLD1ONeFNALrrhg/qzFTGdw47xgSSbh3 w8XNvFxSWvOd8iLaxnBN4tHWnMIRSIPklR2NUOw40NRzQgKeIsszLEdgrqQV8LQgmRBn AT/z18hIP55jArRWNB99bu0tlo3wj13fUthABcdvSF/xgkpIkDGwUpEidveFtaJY2tXU gOI6lxQcR4CIEX5U6iuPP+Hyhbn8Ei7uQXsOjx1YeIjfSqxHnPVCrtDtbIuAyW4SNm6J WF5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vyxyOmI7Dcn7lkpo+nJITq7keQTJTljrcH1q4jRbBa0=; b=qE0W2bea0cPwy0xnmlpnXAKTFJbvH0f8Ja1Capw05l7/UR4vlNi8Z/AOGBZPRVBcAI S15/Jf/fpWmxyYT+boVUOkKBV+wDnTrtZbLOru8iCrWcEl8CyFpzLPx5wo20d3jNajlx 3iievi6KRfdC1P+HpZ0ZMQmDVMrjLF8nyzYZLN248w4d6hA34Jl4okdoW9QOaq6B81eo N3mE2PplSPoCeV4QG7HlVsIb0QYLrRsFTMmR2vNUGAfzyQG8IihZuHXFt60x8gMQv9E0 zvq8AF1Sz12RPUkep0RjtBnd53zo93GtEKJmYxSFnvhTWsGJH+qdlH79nEoJwbKXiAhS iI0A== X-Gm-Message-State: APjAAAVptwZ3AzPfu6M0kUIsc3m2TexcrT9EjtYz5pOeRhz0f0Rx9Qhp YxLQH1U5ZtKq2zTonOYvVrH4S5F8aCxCkCGUtvWxaQ== X-Google-Smtp-Source: APXvYqxzUQmFdBXcvL/Mt/CetKi3tFm4KJ3FMLHv3El5i9lI/qK6Uh91TQLsVqvND8as/w9Ca/0SiFAg9Z1rBjEGmr0= X-Received: by 2002:aca:3909:: with SMTP id g9mr9087888oia.107.1570732188774; Thu, 10 Oct 2019 11:29:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Cross Date: Thu, 10 Oct 2019 14:29:37 -0400 Message-ID: Subject: Re: uefisign and loader To: Warner Losh Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 46q04G4pgZz4QJc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=AShwmQj0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dcrosstech@gmail.com designates 2607:f8b0:4864:20::232 as permitted sender) smtp.mailfrom=dcrosstech@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2.3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(0.00)[ip: (-8.88), ipnet: 2607:f8b0::/32(-2.53), asn: 15169(-2.13), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 18:29:51 -0000 Ok, it appears uefisign is just outright broken; after not being able to boot even boot1 signed, I brought the signed image over to windows and used signtool verify and got the error message: "SignTool Error: WinVerifyTrust returned error: 0x80096010 The digital signature of the object did not verify." This is a different error then I get form SignTool boot1.efi from an untrusted cert (signed via SignTool) which reports: "..A certificate chain processed, but terminated in a root certificate which is not trusted..." Anyone actually use uefisign successfully? On Mon, Oct 7, 2019 at 9:29 AM David Cross wrote: > > > On Mon, Oct 7, 2019 at 1:02 AM Warner Losh wrote: > >> >> >> On Sun, Oct 6, 2019, 10:58 PM David Cross wrote: >> >>> I've been working on getting secureboot working under freebsd (I today >>> just >>> finished off a REALLY rough tool that lets one tweak uefi authenticated >>> variables under freebsd, with an eye to try to get a patch to put this >>> into >>> efivar). After setting the PK, the KEK, and the db, I was super excited >>> to >>> finally secure-boot my machine, and discovered that I could not uefisign >>> loader. Attempting to sign loader returns a cryptic: "section points >>> inside the headers" and then hangs in pipe-read (via siginfo). (this is >>> under 12.0 FWIW). >>> >>> I am able to sign boot1, however boot1.efi doesn't handle GELI keys so >>> its >>> not really useful for me. >>> >>> Suggestions? >>> >> >> Use loader.efi directly instead? >> >>> >>> > I currently do use loader.efi directly, however not being able to sign > loader.efi directly complicates things a bit (using hash based signature > lists for the 'db' variable); and it seems we *should* be able to sign > loader. From some other posts on the internet it seems that at some point > we could. > From owner-freebsd-hackers@freebsd.org Fri Oct 11 02:55:05 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7B7AA13A1EF for ; Fri, 11 Oct 2019 02:55:05 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 46qCHD0FmGz3P7T for ; Fri, 11 Oct 2019 02:55:03 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 10 Oct 2019 19:59:27 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.15.2/8.15.2) with ESMTPS id x9B2rsWu061162 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 10 Oct 2019 19:53:54 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.15.2/8.15.2/Submit) id x9B2rs7U061161; Thu, 10 Oct 2019 19:53:54 -0700 (PDT) (envelope-from ambrisko) Date: Thu, 10 Oct 2019 19:53:54 -0700 From: Doug Ambrisko To: David Cross Cc: FreeBSD Hackers Subject: Re: uefisign and loader Message-ID: <20191011025354.GA59270@ambrisko.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 46qCHD0FmGz3P7T X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.90) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [-1.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.985,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ambrisko.com]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.47)[ipnet: 70.88.0.0/14(-1.15), asn: 7922(-1.15), country: US(-0.05)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 02:55:05 -0000 On Thu, Oct 10, 2019 at 02:29:37PM -0400, David Cross wrote: | Ok, it appears uefisign is just outright broken; after not being able to | boot even boot1 signed, I brought the signed image over to windows and used | signtool verify and got the error message: | "SignTool Error: WinVerifyTrust returned error: 0x80096010 | The digital signature of the object did not verify." | | | This is a different error then I get form SignTool boot1.efi from an | untrusted cert (signed via SignTool) which reports: | "..A certificate chain processed, but terminated in a root certificate | which is not trusted..." | | Anyone actually use uefisign successfully? I've been using sbsign with patches to use an external OpenSSL engine since our keys are stored in a corporate signing server. This worked well since at work we have different groups running Linux as well so having common signing tools made things easier. Each group has their own UEFI keys. I had authenticated updates working in FreeBSD https://reviews.freebsd.org/D8278 Warner had some feedback. I think I incorporated it but forget. It's been a while. My former group has being shipping FreeBSD in UEFI secure boot mode with their own custom keys for several years. Doug A. | On Mon, Oct 7, 2019 at 9:29 AM David Cross wrote: | | > | > | > On Mon, Oct 7, 2019 at 1:02 AM Warner Losh wrote: | > | >> | >> | >> On Sun, Oct 6, 2019, 10:58 PM David Cross wrote: | >> | >>> I've been working on getting secureboot working under freebsd (I today | >>> just | >>> finished off a REALLY rough tool that lets one tweak uefi authenticated | >>> variables under freebsd, with an eye to try to get a patch to put this | >>> into | >>> efivar). After setting the PK, the KEK, and the db, I was super excited | >>> to | >>> finally secure-boot my machine, and discovered that I could not uefisign | >>> loader. Attempting to sign loader returns a cryptic: "section points | >>> inside the headers" and then hangs in pipe-read (via siginfo). (this is | >>> under 12.0 FWIW). | >>> | >>> I am able to sign boot1, however boot1.efi doesn't handle GELI keys so | >>> its | >>> not really useful for me. | >>> | >>> Suggestions? | >>> | >> | >> Use loader.efi directly instead? | >> | >>> | >>> | > I currently do use loader.efi directly, however not being able to sign | > loader.efi directly complicates things a bit (using hash based signature | > lists for the 'db' variable); and it seems we *should* be able to sign | > loader. From some other posts on the internet it seems that at some point | > we could. | > | _______________________________________________ | freebsd-hackers@freebsd.org mailing list | https://lists.freebsd.org/mailman/listinfo/freebsd-hackers | To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Oct 3 14:11:43 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DACEB136FD8 for ; Thu, 3 Oct 2019 14:11:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 46kZgd6zxbz4B2W for ; Thu, 3 Oct 2019 14:11:41 +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 mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 21D3F43DE43; Fri, 4 Oct 2019 00:11:36 +1000 (AEST) Date: Fri, 4 Oct 2019 00:11:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Bruce Evans , Sebastian Huber , FreeBSD Subject: Re: Why is tc_get_timecount() called two times in tc_init()? In-Reply-To: <20191003084021.GI44691@kib.kiev.ua> Message-ID: <20191003214837.L1757@besplex.bde.org> References: <0e27fb3e-0f60-68e1-dbba-f17c3d91c332@embedded-brains.de> <20191002140040.GA44691@kib.kiev.ua> <20191003013314.O2151@besplex.bde.org> <20191002163946.GE44691@kib.kiev.ua> <20191003030837.C2787@besplex.bde.org> <20191003084021.GI44691@kib.kiev.ua> 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=D+Q3ErZj c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=oYFAf8PNGlaI0U8UrYkA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 46kZgd6zxbz4B2W X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_TWO(0.00)[2]; RWL_MAILSPIKE_POSSIBLE(0.00)[246.132.29.211.rep.mailspike.net : 127.0.0.17]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[optusnet.com.au]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[optusnet.com.au]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; IP_SCORE(0.00)[ip: (-6.97), ipnet: 211.28.0.0/14(-3.23), asn: 4804(-2.38), country: AU(0.01)]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; FREEMAIL_CC(0.00)[optusnet.com.au] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 14:11:43 -0000 On Thu, 3 Oct 2019, Konstantin Belousov wrote: > On Thu, Oct 03, 2019 at 03:12:26AM +1000, Bruce Evans wrote: >> On Wed, 2 Oct 2019, Konstantin Belousov wrote: >> >>> On Thu, Oct 03, 2019 at 02:25:46AM +1000, Bruce Evans wrote: >>>> On Wed, 2 Oct 2019, Konstantin Belousov wrote: >>> So the conclusion is that the second call can be removed, am I right ? >> >> Yes. >> >> All tc_get_timecount() functions should be checked for doing sufficient >> initialization in one call (so that deltas for subsequent calls are >> correct). > > This should be it. Hmm, there are a lot of calls from subsystems that shouldn't know about this. > But, is even a single call to tc_get_timecount() needed for "warmup" ? Yes, something must initialize the hardware timecounter if it is not already initialized (and free-running). The i8254 timecounter is a good example. It has internal state that is only updated while it is active. Something must also initialize the software timecounter. This seems to have been broken since 2002 when switch_timecounter() was removed. Most of the software state is initialized early, but th_offset_count is initialized late in tc_windup(), so going live with 'timecounter = newtc' never works. The order in sysctl_kern_timecounter_hardware() is: ...tc_get_timecount(newtc); /* initialize h/w tc. */ /* Fail to initialize newtc->th_offset with new h/w value. */ timecounter = newtc; /* go live with uninitialized tc. */ > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c > index 382d139617d..28d0d738a58 100644 > --- a/sys/dev/acpica/acpi.c > +++ b/sys/dev/acpica/acpi.c > @@ -3191,7 +3191,6 @@ acpi_resync_clock(struct acpi_softc *sc) > * Warm up timecounter again and reset system clock. > */ > (void)timecounter->tc_get_timecount(timecounter); > - (void)timecounter->tc_get_timecount(timecounter); > inittodr(time_second + sc->acpi_sleep_delay); > } Fairly bad code with bogus comment. Comment more bogus than before. The timecounter hasn't been warmed up (or even initialized) before the comment. "again" in the comment refers to removed second tc call. The actual initialization is done by inittodr(). No tc initialization or warming should be needed before it it. It first reads the RTC, then calls tc_setclock() to set the timecounter to the value read. There is not enough locking around this (real-time locking to guarantee that the value read is not too out of date when it is used...). tc_setclock() now has mutex locking which might be good enough if it were around the whole operation. But it isn't even around all of itself, and tc_setclock() depends on the timecounter being initialized at this point. I think th_offset is used uninitialized after resume. Various bugs and magic limit the damage from this. There is the large bug that CLOCK_MONOTONIC stops while suspended. I think acpi does start its timer earlier and the comment about "warming up again" is partly correct for a single tc call -- the call doesn't warm up again, but further warming which is probably unnecessary. The uninitialized th_offset provides a garbage delta, but tc_setclock() compensates using other deltas: XX void XX tc_setclock(struct timespec *ts) XX { XX struct timespec tbef, taft; XX struct bintime bt, bt2; XX XX timespec2bintime(ts, &bt); XX nanotime(&tbef); Race above here by not locking yet. Use th_offset uninitialized above and below here in some cases. nanotime() gives a garbage time after acpi resume. Since the acpi timer mask is fairly large and the acpi timer frequency is fairly small, there is a chance that overflow doesn't occur so that the garbage time is almost correct as a relative time (the correct monotonic time less the suspended time). XX mtx_lock_spin(&tc_setclock_mtx); Now have almost adequate locking. XX cpu_tick_calibrate(1); XX binuptime(&bt2); XX bintime_sub(&bt, &bt2); This gives an almost correct relative time with some magic: - inittodr() passed us the RTC time which is absolute and now in bt - bt2 is garbage calculated using the garbage th_offset - whatever garbage bt2 is, the final bt gives the delta needed to recover the RTC provided we keep using the garbage offset and any overflows from this give consistent deltas. XX XX /* XXX fiddle all the little crinkly bits around the fiords... */ XX tc_windup(&bt); tc_windup() finally initializes th_offset. Now the deltas aren't from a consistent garbage offset, but the damage is limited. The bt arg here is only used to subvert boottimebin to a non-boottime so that adding the broken monotic time to the boot time gives the RTC time modulo the consistency bugs near here and drift. Monotonic times use the new offset and are only especially broken if that goes backwards over suspend/resume. It is unclear if other subsystems can call timecounter code during resume (or suspend) before the timecounter is fully reinitialized here. XX mtx_unlock_spin(&tc_setclock_mtx); XX ... > > diff --git a/sys/dev/acpica/acpi_timer.c b/sys/dev/acpica/acpi_timer.c > index 34a832089a2..d768397a785 100644 > --- a/sys/dev/acpica/acpi_timer.c > +++ b/sys/dev/acpica/acpi_timer.c > @@ -274,7 +274,6 @@ acpi_timer_resume_handler(struct timecounter *newtc) > "restoring timecounter, %s -> %s\n", > tc->tc_name, newtc->tc_name); > (void)newtc->tc_get_timecount(newtc); > - (void)newtc->tc_get_timecount(newtc); > timecounter = newtc; > } > } Oops, here is the first incomplete reinitialization and warmup. It clearly uses th_offset uninitialized, just like for switching the timecounter hardware. This function (and similarly acpi_timer_suspend_handler()) seem to be mostly wrong. When the acpi timecounter is the current timecounter, suspend doesn't schedule resume and resume has an unnecessary check. When the acpi timecounter is not the current timecounter, suspend forces a switch to it and schules resume to undo this foot-shooting. Supsend and resume do the usual buggy switch with a warmup or 2 but th_offset uninitialized. Note that acpi_resync_clock() for resume (where inittodr() is called) syncs the current timecounter() and doesn't belong under acpi. > diff --git a/sys/dev/xen/control/control.c b/sys/dev/xen/control/control.c > index 98ab5bf3a6b..1e132f4d866 100644 > --- a/sys/dev/xen/control/control.c > +++ b/sys/dev/xen/control/control.c > @@ -303,7 +303,6 @@ xctrl_suspend() > * Warm up timecounter again and reset system clock. > */ > timecounter->tc_get_timecount(timecounter); > - timecounter->tc_get_timecount(timecounter); > inittodr(time_second); Similar with "again" in comment. Actually worse than that: for acpi in the foot-shooting case the acpi timecounter was warmed in suspend when it was bogusly activated; in resume is inactivated and the original timecounter warmed (but not again) and reactivated. For xen, there is no corresponding switching and just this misplaced incomplete reinitialization. > > #ifdef EARLY_AP_STARTUP > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > index 9920a9a9304..847fbbbf35d 100644 > --- a/sys/kern/kern_tc.c > +++ b/sys/kern/kern_tc.c > @@ -1257,7 +1257,6 @@ tc_init(struct timecounter *tc) > tc->tc_frequency < timecounter->tc_frequency) > return; > (void)tc->tc_get_timecount(tc); > - (void)tc->tc_get_timecount(tc); > timecounter = tc; > } > This might work for the very first initialization. > @@ -1519,7 +1518,6 @@ sysctl_kern_timecounter_hardware(SYSCTL_HANDLER_ARGS) > > /* Warm up new timecounter. */ > (void)newtc->tc_get_timecount(newtc); > - (void)newtc->tc_get_timecount(newtc); > > timecounter = newtc; > Original problem only appeared to be cosmetic. > @@ -2011,7 +2009,6 @@ inittimecounter(void *dummy) > > /* warm up new timecounter (again) and get rolling. */ > (void)timecounter->tc_get_timecount(timecounter); > - (void)timecounter->tc_get_timecount(timecounter); > mtx_lock_spin(&tc_setclock_mtx); > tc_windup(NULL); > mtx_unlock_spin(&tc_setclock_mtx); > This might work since it doesn't defer the call to tc_windup(). "again" in its comment seems to be bogus. "twice" might have been correct but banal for the 2 calls. This function is a SYSINIT() so it is unclear how much is initialized before it. Bruce From owner-freebsd-hackers@freebsd.org Fri Oct 4 19:39:39 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9BF7A137260 for ; Fri, 4 Oct 2019 19:39:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 46lKvX6h11z3GG5 for ; Fri, 4 Oct 2019 19:39:36 +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 mail104.syd.optusnet.com.au (Postfix) with ESMTPS id CA06043F06D; Sat, 5 Oct 2019 05:39:29 +1000 (AEST) Date: Sat, 5 Oct 2019 05:39:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp cc: Sebastian Huber , Warner Losh , Konstantin Belousov , Bruce Evans , FreeBSD Subject: Re: Why is tc_get_timecount() called two times in tc_init()? In-Reply-To: <60167.1570198248@critter.freebsd.dk> Message-ID: <20191005024530.U1757@besplex.bde.org> References: <0e27fb3e-0f60-68e1-dbba-f17c3d91c332@embedded-brains.de> <20191002140040.GA44691@kib.kiev.ua> <20191003013314.O2151@besplex.bde.org> <20191002163946.GE44691@kib.kiev.ua> <20191003030837.C2787@besplex.bde.org> <20191003084021.GI44691@kib.kiev.ua> <47834.1570116246@critter.freebsd.dk> <141ee0af-2ff4-50fc-b4e4-6d1fc47e04f3@embedded-brains.de> <60167.1570198248@critter.freebsd.dk> 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=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=PGrZBZ7u4VfUz6DTkGYA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 46lKvX6h11z3GG5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; IP_SCORE(0.00)[ip: (-6.92), ipnet: 211.28.0.0/14(-3.23), asn: 4804(-2.38), country: AU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; FROM_EQ_ENVFROM(0.00)[] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 19:39:39 -0000 On Fri, 4 Oct 2019, Poul-Henning Kamp wrote: > -------- > In message <141ee0af-2ff4-50fc-b4e4-6d1fc47e04f3@embedded-brains.de>, Sebastian > Huber writes: > >>> I think the original reason for this was (locked) delta-based >>> timecounters, (ie counters which roll over rapidly) in order that >>> their first "real" use would not return truly bogus values. >> >> Ok, this explanation makes sense. When I ported the FreeBSD timecounter >> implementation to RTEMS I was a bit surprised how many chips (even a >> Cortex-M has nothing out of the box) lack a simple free running counter. >> Maybe it should be added as a comment to these two tc_get_timecount() calls? > > As long as the counter can be read atomically and does not roll over > in a matter of milliseconds, two reads are not necessary. The i8254 timecounter rolls over in a matter of microseconds if suitably (mis)configured. E.g., for pcaudio i8254 periodic timer was run at 16 kHz so it rolled over every 74 or 75 cycles. I only used this for stress tests. Now you can do even better stress tests and foot shooting using event timers: make the i8254 the active timecounter and the active event timer in aperiodic mode, and ask it to generate aperiod interrupts faster than 16 kHz. The pcaudio code attempts to avoid glitches in the timecounter when switching the frequency between HZ and 16k (mostly by deferring the switch to the interrupt handler). The one-shot switching not careful, and can be exercised at higher frequencies by unprivileged applications (after privilege is used to configure). No matter how fast the counter can roll over, 2 reads are only useful or needed accidentally. And they are needed for rollover detection for the i8254 timecounter: XX low = inb(TIMER_CNTR0); XX high = inb(TIMER_CNTR0); XX count = i8254_max_count - ((high << 8) | low); XX if (count < i8254_lastcount || i8254_lastcount is garbage after only 1 read, but it is used here at the start of the rollover detection. Thus the first read returns garbage and also leaves some internal state as garbage, but it will update i8254_lastcount in its internal state and that is enough for the second read to work correctly. XX (!i8254_ticked && (clkintr_pending || XX ((count < 20 || (!(flags & PSL_I) && The magic 20 is something that is hopefully larger than the interrupt latency (IIRC, this dates from McCann's version in ~1992 when we hoped that i386's had interrupt latency this low). XX count < i8254_max_count / 2u)) && 16 kHz gives a non-magic 37 for 'i8254_max_count / 2u' and we do a faster test for rollover between 20 and 37 and no rollover test above 37. XX i8254_pending != NULL && i8254_pending(i8254_intsrc))))) { XX i8254_ticked = 1; XX i8254_offset += i8254_max_count; XX } Rollover detection requires calling i8254_get_timecounter() at least {once per rollover} + {~20 cycles}. It looks like I fixed switching to the i8254 timecounter by adding an extra call in 1 place. This was not so good, and it turned into 2 calls in 1 place, then was later replicated in places that shouldn't know anything about this. The need for 2 calls is only an optimization, but I don't a better way. On any call, we can't know if the previous call left garbage (or was not made) without reading the counter twice. The caller now keeps track of the state and makes a second call when necessary. This fits well with another responsibility of the callers -- calls must be made often enough to detect rollover. Perhaps requiring calls strictly more often than rollover is best. Then the rollover detection in the i8254 timecounter can be removed. I now see the correct design for handling timecounters across suspend/ resume: - in the suspend method for the active timecounter, if this stops the hardware, then first stop the software timecounter, perhaps by switching to a null timecounter. Don't leave the active timecounter returning garbage as now. (acpi suspend does some bogus switching instead, I think from the active timecounter to the non-null acpi timecounter. This can only help if the acpi timecounter is suspended after the active timecounter, which it should be if acpi is configured.) - in the resume method for the active timecounter, if this timecounter was switched away from in suspend, first start the hardware timecounter, then switch to it. - restore switch_timecounter() and fix it to work and call it instead of replicating it. Call it at boot time for dummy -> normal, at sysctl change time for normal -> another, at suspend time for normal -> null and at resume time for null -> normal. - the timecounter for transitions in suspend/resume can't be dummy since we don't know how fast or far it should advance. Since the h/w timer is expected to stop while suspended, it may as well stop for transitions too (acpi might already implement this by stopping and starting its timer as the last and first things in suspend and resume, but I don't trust it to stop all the other CPUs and subsystems and the above works without acpi). - fix races and minimize drift when restoring the RTC time using inittodr(). My version uses only splhigh() locking which stopped working in FreeBSD-5. It keeps track of the drift between the RTC and the timecounter in a recent long interval and assumes that the drift is the same while suspended (it is not the same, but better than 0). My version also fixes the average 0.5 seconds error reading the RTC. - fix monotonic times across suspend/resume. Don't clobber boottime to make the real time come out right after stopping the monotonic clock, but step the monotonic clock forward to approximate physical time since the unclobbered boottime. - fix timeouts across suspend/resume. Most should occur soon after resume, but not all at once. Bruce From owner-freebsd-hackers@freebsd.org Tue Aug 13 15:41:31 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 32CF9B323E for ; Tue, 13 Aug 2019 15:41:31 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467H4p3P0vz41MW for ; Tue, 13 Aug 2019 15:41:30 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wm1-x32d.google.com with SMTP id e8so1338634wme.1 for ; Tue, 13 Aug 2019 08:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=DemeNiNi4pTd4MXqGipWaKGnI6CrHfC4F+wf8J6813I=; b=CZn4CFD6zYuOUjruuykcjTfsSa4gHwSLk1UYUhq7WhQ8/w3A+QFw7xxVzuuoGRBGYe 2cKj02X4ZDb9dzkEW/+g0eLO1DhPJKT2mNGhnb79LRTuaMNtXzOm98N3XiZefelo3hm0 jaiYLj4v2ln+yaJrY58QT4sqPsVQkZq57Nc8z05St9aqGoiRqWu7OKJpRcacinJH62aw kUSluMFiJOCZFtZ4p+QTMJfwIBISKH4D16wRVtU4pD2NGn97Qer/sJySuHC9FghEHI4w kyv1Hgn3CpG2cImmg0COGfFaU4kvy4TaZsjjTIDjeCrniZtNDNJjkx5qwHPOR7mTfwAt K/Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=DemeNiNi4pTd4MXqGipWaKGnI6CrHfC4F+wf8J6813I=; b=Qq4fW47Tl4TbkNtpN5v+ykFpuSWh3xFTtdGOS2BYmq1BRV9h/myzzeatxWxxZTcrq6 giBkISV5BdZh/7/knBSaDvIVac116mAuc4L2u0zt8OSla2xKstZFmgozZlZW2wRqfNHT l5ycMA+wk5OvoFmlX2Hs8bviAIR0sFq9354sVBAG41SGDkm/E9YDdQ6EvqSQw2vK12Wg kyswshXY8Vw3Dowth149hRufD+Q8WDpqM9NFmRr183gMjJvHHL0Si+JcbMn4OnS0yPu1 nKgeSQo2KdHe+xydMwMhxyUlDItuxD9IlnJbk2/StGOwpB4tO3Gtk7XvAI3wncw6sl0w jBSg== X-Gm-Message-State: APjAAAUkNXWa8i+8X5+bg2GGUSg+kG5APgJDwWNLaN5do3k30PxdUV/T WJ/WRmUY/DqVQLK8N7haNlr0NLqZXIM= X-Google-Smtp-Source: APXvYqw4Swr0LOQ1DHh3/DBis74QVz3SnsKWmw5r5LmQmEq3Le+U6kPLSNPDIiBsedy6W9kqIoSOxA== X-Received: by 2002:a1c:7e50:: with SMTP id z77mr3935793wmc.164.1565710888592; Tue, 13 Aug 2019 08:41:28 -0700 (PDT) Received: from [10.0.1.104] (p4FD3AB4E.dip0.t-ipconnect.de. [79.211.171.78]) by smtp.gmail.com with ESMTPSA id s64sm3234714wmf.16.2019.08.13.08.41.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 08:41:28 -0700 (PDT) From: Gordon Bergling Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: uname -a default options Message-Id: To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 467H4p3P0vz41MW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=CZn4CFD6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gbergling@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=gbergling@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; RECEIVED_SPAMHAUS_PBL(0.00)[78.171.211.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.22), ipnet: 2a00:1450::/32(-3.04), asn: 15169(-2.39), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[d.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 13 Aug 2019 15:41:31 -0000 X-Original-Date: Tue, 13 Aug 2019 17:41:26 +0200 X-List-Received-Date: Tue, 13 Aug 2019 15:41:31 -0000 Hello List, "uname -a" is currently mapping the -a option to =E2=80=9E-mnrsv=E2=80=9C,= which results in something similar like $ uname -a FreeBSD lion.0xfce3.net 12.0-STABLE FreeBSD 12.0-STABLE r350835 GENERIC = amd64 What would you think about reducing the option mapping for =E2=80=9E-a=E2=80= =9C to =E2=80=9E-vmn=E2=80=9C , which would result in a less repetitive = version string like the one below. $ uname -vmn lion.0xfce3.net FreeBSD 12.0-STABLE r350835 GENERIC amd64 Adapting this would be trivial, but before I hack something together, I = would like to get some feedback if such a change would be welcomed? Best regards, Gordon -- Gordon Bergling E-Mail: gbergling@googlemail.com Web: http://www.gordons-perspective.com/ Think before you print! From owner-freebsd-hackers@freebsd.org Fri Aug 30 04:03:32 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 40C4DC0A04; Fri, 30 Aug 2019 04:03:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 46KQnZ3Cmyz4c3q; Fri, 30 Aug 2019 04:03:29 +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 mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 63005361D09; Fri, 30 Aug 2019 14:03:27 +1000 (AEST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Eugene Grosbein cc: freebsd-security@freebsd.org, Freebsd hackers list Subject: Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi In-Reply-To: Message-ID: <20190830133855.W1405@besplex.bde.org> References: <20190820201257.7A9D41F8B7@freefall.freebsd.org> 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=P6RKvmIu c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=i-w8XHbryAZmjjn50WgA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 46KQnZ3Cmyz4c3q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.249 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-3.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_LOW(-0.10)[249.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23:c]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; IP_SCORE(0.00)[ip: (-5.25), ipnet: 211.28.0.0/14(-3.26), asn: 4804(-2.38), country: AU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 30 Aug 2019 04:03:32 -0000 X-Original-Date: Fri, 30 Aug 2019 14:03:25 +1000 (EST) X-List-Received-Date: Fri, 30 Aug 2019 04:03:32 -0000 On Wed, 21 Aug 2019, Eugene Grosbein wrote: > 21.08.2019 3:12, FreeBSD Security Advisories wrote: > > [skip] > >> IV. Workaround >> >> No workaround is available. Custom kernels without "device sound" >> are not vulnerable. > > Is it true that there is no way to disable vulnerable and unneeded device driver > built in GENERIC other that through rebuilding the kernel? > > I remember that pre-4.x versions of FreeBSD had visual VGA-based pre-boot configurator Visual userconfig and command-line userconfug were in all versions of 4.x too. > allowing to disable any compiled-in device driver. Don't device.hints(5) or loader(8) have means to do so? Configuration was unimproved by hints, env and new-bus after 4.x. In 4.x and earlier, the irq and other parameters, and disable and other flags, were part of a formal syntax implemented at config(8) time using yacc and at kernel userconfig time more hackishly and at kernel visual userconfig time more guishlly. Now hints and env give a random mostly undocumented syntax. Even disable flags don't work right. New-bus allows more complicated or just larger topologies which are harder to control using disable flags. > These days GENERIC have LOTS of drivers and it's convenient but unsafe. It is hard to even find the list of (unattached) drivers, or get useful (fauling) probe messages for drivers that aren't used. I use the following patch mainly to fix sio and uart probing in uncontrollable or hard-coded order and/or precendence when both are statically configured. One must be disabled on a per-device basis, but even disabling doesn't work without this patch. The patch preserves some historical mistakes and adds some excessive verboseness about probe failures. I'm still waiting for jhb to reply to mails on 30 Oct 2015 and 23 Jan 2018 asking for a review of this patch or better a complete fix. XX Index: subr_bus.c XX =================================================================== XX --- subr_bus.c (revision 332488) XX +++ subr_bus.c (working copy) XX @@ -2079,6 +2079,12 @@ XX return (TAILQ_NEXT(last, link)); XX } XX XX +/* XX + * Keep probing disabled devices for now, in case this has beneficial side XX + * effects. XX + */ XX +static volatile int probe_rdisabled = 0; XX + XX /** XX * @internal XX */ XX @@ -2088,7 +2094,7 @@ XX devclass_t dc; XX driverlink_t best = NULL; XX driverlink_t dl; XX - int result, pri = 0; XX + int rdisabled, result, unit, pri = 0; XX int hasclass = (child->devclass != NULL); XX XX GIANT_REQUIRED; XX @@ -2139,8 +2145,27 @@ XX resource_int_value(dl->driver->name, child->unit, XX "flags", &child->devflags); XX XX - result = DEVICE_PROBE(child); XX + /* Record other state while the unit is valid. */ XX + unit = child->unit; XX + rdisabled = resource_disabled(dl->driver->name, unit); XX XX + /* See below for more details. */ XX + if (rdisabled) { XX + device_print_prettyname(dev); XX + if (probe_rdisabled) XX + device_printf(child, XX + "probing disabled device\n"); XX + else { XX + device_printf(child, XX + "disabled in probe by hints\n"); XX + device_disable(child); XX + } XX + } XX + if (rdisabled && !probe_rdisabled) XX + result = ENXIO; XX + else XX + result = DEVICE_PROBE(child); XX + XX /* Reset flags and devclass before the next probe. */ XX child->devflags = 0; XX if (!hasclass) XX @@ -2182,6 +2207,30 @@ XX } XX XX /* XX + * Ignore the result of probing a disabled device, XX + * so that disabled devices with higher priorities XX + * are not preferred, only to do nothing at attach XX + * time but complete their disablement and fail. XX + * This is not quite right since it loses the XX + * accidental (?) feature of being able to disable XX + * attaching a resource for all drivers by XX + * disabling it for one driver if there happens to XX + * one with highest priority (or equal highest, XX + * with the disabled one preferred because it is XX + * probed first. XX + */ XX + if (rdisabled) { XX + device_print_prettyname(dev); XX + /* XXX device_printf() fails -- child inval. */ XX + printf("%s%d: disabled in probe by hints\n", XX + dl->driver->name, unit); XX +#ifdef notyet /* XXX don't risk this with invalid child->unit */ XX + device_disable(child); XX +#endif XX + continue; XX + } XX + XX + /* XX * A priority lower than SUCCESS, remember the XX * best matching driver. Initialise the value XX * of pri for the first match. The rest is unrelated (keep the message out of the attach timing). But it seems reasonable to get entropy from probe time as well as attach timing, and that would include timing for spammish probe messages. XX @@ -2909,8 +2958,6 @@ XX } XX XX device_sysctl_init(dev); XX - if (!device_is_quiet(dev)) XX - device_print_child(dev->parent, dev); XX attachtime = get_cyclecount(); XX dev->state = DS_ATTACHING; XX if ((error = DEVICE_ATTACH(dev)) != 0) { XX @@ -2925,6 +2972,8 @@ XX return (error); XX } XX attachtime = get_cyclecount() - attachtime; XX + if (!device_is_quiet(dev)) XX + device_print_child(dev->parent, dev); XX /* XX * 4 bits per device is a reasonable value for desktop and server XX * hardware with good get_cyclecount() implementations, but WILL Bruce From owner-freebsd-hackers@freebsd.org Sat Oct 5 15:10:19 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7682713578D for ; Sat, 5 Oct 2019 15:10:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 46lqtL0LTcz3Kcn for ; Sat, 5 Oct 2019 15:10:17 +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 mail105.syd.optusnet.com.au (Postfix) with ESMTPS id E7BA1361AE3; Sun, 6 Oct 2019 01:10:12 +1000 (AEST) Date: Sun, 6 Oct 2019 01:10:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans cc: Poul-Henning Kamp , Sebastian Huber , Warner Losh , Konstantin Belousov , FreeBSD Subject: Re: Why is tc_get_timecount() called two times in tc_init()? In-Reply-To: <20191005171343.X925@besplex.bde.org> Message-ID: <20191006000900.E2009@besplex.bde.org> References: <0e27fb3e-0f60-68e1-dbba-f17c3d91c332@embedded-brains.de> <20191002140040.GA44691@kib.kiev.ua> <20191003013314.O2151@besplex.bde.org> <20191002163946.GE44691@kib.kiev.ua> <20191003030837.C2787@besplex.bde.org> <20191003084021.GI44691@kib.kiev.ua> <47834.1570116246@critter.freebsd.dk> <141ee0af-2ff4-50fc-b4e4-6d1fc47e04f3@embedded-brains.de> <60167.1570198248@critter.freebsd.dk> <20191005024530.U1757@besplex.bde.org> <20191005171343.X925@besplex.bde.org> 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=D+Q3ErZj c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=TlpueQ-gDQS47zSL848A:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 46lqtL0LTcz3Kcn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.249 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_LOW(-0.10)[249.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[optusnet.com.au]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23:c]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[optusnet.com.au]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RWL_MAILSPIKE_POSSIBLE(0.00)[249.132.29.211.rep.mailspike.net : 127.0.0.17]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; IP_SCORE(0.00)[ip: (-5.05), ipnet: 211.28.0.0/14(-3.21), asn: 4804(-2.36), country: AU(0.01)]; FREEMAIL_TO(0.00)[optusnet.com.au]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2019 15:10:19 -0000 On Sat, 5 Oct 2019, Bruce Evans wrote: > Now event timers give more cases: > - i8254 used for one-shot timeouts, so interrupting. Syncing with its > interrupt needed but not done (programming one-shot timeouts doesn't > change internal state so leaves it as garbage). Syncing was done for > pcaudio by only reprogramming the timeouts in the interrupt handler > under suitable locks. Actual testing shows that event timers avoid this bug by only supporting one-shot mode if the i8254 is not statically configured as a timecounter. The i8254 is statically configured as a timecounter by default, but this can be changed by an obscure environment variable ("attimer0.timecounter", is not a tunable or readonly sysctl for some reason, and its device nameunit "attimer0" is different from the timecounter and eventtimer name "i8254"). However, all timecounters that rollover on every timer interrupt were broken for HZ > 1500 in r95947 in 2002, by limiting the frequency of calling tc_windup() to 1000 Hz with slop to 1500 Hz. tc_windup() is supposed to guarantee calling tc_get_timecount() more often than rollover, and limiting tc_windup()s freqency to anything less than HZ breaks this when the rollover frequency is HZ. After fixing this by removing the dynamic configuration of the misdocumented divisor tc_tick (see sysctl -d output for useless information about what this is), the i8254 rollover detection code still works at the high frequency HZ = 20k. Tested on an 8-CPU 4 GHz system using kern.timecounter.hardware=i8254 and kern.eventtimer.timer=i8254 (this forces a period eventtimer). Interrupt latency from the interrupt to tc_windup must be less than 25 (or perhaps 17 usec) for this to work. 4GHz and a spare CPU may be needed for this latency now, though i486/33 UP was enough before SMPng. The sysctl to control tc_tick has different bugs in all versions. It was born broken in r95497 by misspelling its variable name as 'tick' (this only compiles by referencing the unrelated global 'tick') and by making it read-only despite the code having a long comment with advice about changing it. The spelling error was fixed in r108671. The comment remains unchanged. Completing the fix used to require just changing CTLFLAG_RD to CTLFLAG_RW, but now it involves using a sysctl function to update the associated globals tc_tick_bt and tc_tick_sbt and possibly also lots of timeout state that was scaled using these globals. The sysctl is not fixed in my version, but I sometimes changed tc_tick using ddb. Now changing only tc_tick breaks timeouts. Bruce From owner-freebsd-hackers@freebsd.org Wed Aug 7 16:22:31 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CE475AEF8A; Wed, 7 Aug 2019 16:22:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 463cGt3nxFz3Pj4; Wed, 7 Aug 2019 16:22:30 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5A42B21CDA; Wed, 7 Aug 2019 12:22:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 07 Aug 2019 12:22:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=i KFQjkuBDI01x/nvatWdFxQkbSkjjB/b93reEcOvOKo=; b=mPIyOKSIROezMjsRG d7RExHoTxjqVF8ykCvLFTM9aEdAwHQ02Lw99iqPDYRDqGEK9HoJbp9kHqKRyMS40 cQSh9LMLO9flzaj5UWGtye1vaOJ1Qdf0A08f4KgJb+YVFbDPMzXurZlWodoStH0n jXiKIuPDv/PXPPCovGlROquEzg/VNM0kTH1YHw95fOys5z9nl7yE0b2cmei7ASTW QFVrn4p5L/7Mm++dcCw0OM4n7VLwSmq88fPQhy+gzRj7nGLf7hFVLKXT47UMhw1N yQXgb8C/4V1O7b05v6qdjD1J9kjE+Vl3xJn6xLidi4nPLcPTg3BUD4JnMS4eIenL hUnRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=iKFQjkuBDI01x/nvatWdFxQkbSkjjB/b93reEcOvO Ko=; b=eXL16uIOjNVpKaj/wWzZEcTyWEiC3poFN/sUNTu6fFXRvXcDAaURHW6Kt ynxI/asTgE0gK81yUayh2Cq8Y1ukQ3IhtjFqJK6dZdrFsy565giqpVo+rlGiZsLO fZgAKJ4WWVGWiHA/rwBMvVPQlnYXPrQvvURyTLfRkvOCq2YhFcCJwssD1yjJp5XO 44y1opy7srmgrd1xPFLgVaBs6RljO15kAVkiCyiT0/lWPzXF9UV3+t52Hn3Gf0D9 OAhdsf96b84nVnGJPnGlpOOcivlUUKr/ibV8N+5RDFuOfm5OaeAmjwCCsLKQgKxd 2d6aMQXUptugKA9JBCfk8mD+1z5+A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduvddguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtjeenucfhrhhomhepufgtohhtthcunfhonhhguceoshgtohhtthhlsehsrghm shgtohdrohhrgheqnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecukfhppedule dvrdehhedrheegrdehkeenucfrrghrrghmpehmrghilhhfrhhomhepshgtohhtthhlsehs rghmshgtohdrohhrghenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [10.178.24.14] (unknown [192.55.54.58]) by mail.messagingengine.com (Postfix) with ESMTPA id 6047580059; Wed, 7 Aug 2019 12:22:27 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: svn commit: r350550 - head/share/mk From: Scott Long In-Reply-To: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> Cc: Glen Barber , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 463cGt3nxFz3Pj4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=samsco.org header.s=fm1 header.b=mPIyOKSI; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=eXL16uIO; dmarc=none; spf=pass (mx1.freebsd.org: domain of scottl@samsco.org designates 66.111.4.28 as permitted sender) smtp.mailfrom=scottl@samsco.org X-Spamd-Result: default: False [-0.78 / 15.00]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[58.54.55.192.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; R_DKIM_ALLOW(0.00)[samsco.org:s=fm1,messagingengine.com:s=fm3]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:66.111.4.28]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[samsco.org]; BAD_REP_POLICIES(0.10)[]; NEURAL_HAM_LONG(-0.88)[-0.877,0]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[samsco.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_MEDIUM(-0.84)[-0.841,0]; IP_SCORE(-3.47)[ip: (-9.81), ipnet: 66.111.4.0/24(-4.81), asn: 11403(-2.68), country: US(-0.05)]; RCVD_IN_DNSWL_LOW(-0.10)[28.4.111.66.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 07 Aug 2019 16:22:32 -0000 X-Original-Date: Wed, 7 Aug 2019 10:22:24 -0600 X-List-Received-Date: Wed, 07 Aug 2019 16:22:32 -0000 > On Aug 7, 2019, at 10:00 AM, John Baldwin wrote: >=20 > On 8/6/19 9:56 AM, Glen Barber wrote: >> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: >>> Author: jhb >>> Date: Sat Aug 3 01:06:17 2019 >>> New Revision: 350550 >>> URL: https://svnweb.freebsd.org/changeset/base/350550 >>>=20 >>> Log: >>> Flip REPRODUCIBLE_BUILD back to off by default in head. >>>=20 >>> Having the full uname output can be useful on head even with >>> unmodified trees or trees that newvers.sh fails to recognize as >>> modified. >>>=20 >>> Reviewed by: emaste >>> Differential Revision: https://reviews.freebsd.org/D20895 >>>=20 >>=20 >> I would like to request this commit be reverted. While the original >> commit message to enable this knob stated the commit would be = reverted >> after stable/12 branched, I have seen no public complaints about >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not = see >> the benefit of disabling it by default -- why wouldn't we want >> reproducibility?). >>=20 >> To me, this feels like a step backwards, with no tangible benefit. >> Note, newvers.sh does properly detect a modified tree if it can find >> the VCS metadata directory (i.e., .git, .svn) -- I know this because >> I personally helped with it. >>=20 >> In my opinion, those that want the non-reproducible metadata included = in >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in = their >> src.conf. Turning off a sane default for the benefit of what I = suspect >> is likely a short list of use cases feels like a step in the wrong >> direction. >=20 > My arguments for flipping this in head (and head only) are that the = data > provided in uname -a when this is disabled is useful for development, = and > that in head we do tailor settings towards development (e.g. GENERIC = in > head vs GENERIC in stable). I=E2=80=99m in favor of how this works at the moment. It was a bit = jarring to me when the reproducible build flag was turned on and I lost all of the metadata = that I subconsciously use during development. I think that what John has = done is an appropriate compromise and is in line with how we=E2=80=99ve = treated similar development-facilitating features in the past, i.e. WITNESS/INVARIANTS, malloc-debug. Scott From owner-freebsd-hackers@freebsd.org Mon Sep 2 06:57:17 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 35746D38BB; Mon, 2 Sep 2019 06:57:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46MLVg6LrCz4L8r; Mon, 2 Sep 2019 06:57:15 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 4gH0iXs2QsAGk4gH2i1wR3; Mon, 02 Sep 2019 00:57:13 -0600 X-Authority-Analysis: v=2.3 cv=WeVylHpX c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=J70Eh1EUuV4A:10 a=VxmjJ2MpAAAA:8 a=7Qk2ozbKAAAA:8 a=iKhvJSA4AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=CcuWIOYoXdM3unlOn6gA:9 a=CjuIK1q_8ugA:10 a=FBhmBtCL6EQA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=1lyxoWkJIXJV6VJUPhuM:22 a=odh9cflL3HIXMm4fY7Wr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 1C033A88; Sun, 1 Sep 2019 23:57:09 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x826v8Nn021659; Sun, 1 Sep 2019 23:57:08 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x826v5ot021581; Sun, 1 Sep 2019 23:57:05 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201909020657.x826v5ot021581@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: Warner Losh , Ian Lepore , FreeBSD Hackers , "Rodney W. Grimes" , Marcelo Araujo , fcp@freebsd.org, Konstantin Belousov , Li-Wen Hsu , Kristof Provost Subject: Re: FCP 20190401-ci_policy: CI policy In-reply-to: <201908300201.x7U214qn086080@slippy.cwsent.com> References: <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> <201908300201.x7U214qn086080@slippy.cwsent.com> Comments: In-reply-to Cy Schubert message dated "Thu, 29 Aug 2019 19:01:04 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-CMAE-Envelope: MS4wfC9PFhw4adguYH4LsGSztIxJ5WQ0J3hMdJahUxCDMCNzU+XwB9y3ft0CCGngrXHRTgNK5BZHeIWfLauQZBE3VAGRHw/NiuTyi5cwLt7XNr4Ejis3vrH4 SPIU1SBneNlwx1meKZ4v2JGmzTMkOyT2+8Ae5/LbqRj4LsIESWQL6kInbe0DuPWZQryah9+yV+NKhaDjLBD9NfP8oSJl0cxZ6KLN6+KfiCxs3EF1ZWLzIuDY KsYhpzwokUsVImgpJbJEqmsyUEuY3znwrt9a99aTKlR4Z++BXM2e0Q3+48nAoVXPc3Nyx/Zvh8rbhgw8xVHKl+2sUV/gluWedavbIkwoA83AHfMTbCg7HJkp rGtLh4xy3gZqNUfViyTORdnFqIYtl3rdebTATq4vBXII/0Gb0DE= X-Rspamd-Queue-Id: 46MLVg6LrCz4L8r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.9) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.94 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.951,0]; RCVD_IN_DNSWL_NONE(0.00)[9.134.59.64.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[10]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.39)[ip: (-6.31), ipnet: 64.59.128.0/20(-3.12), asn: 6327(-2.42), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 02 Sep 2019 06:57:17 -0000 X-Original-Date: Sun, 01 Sep 2019 23:57:05 -0700 X-List-Received-Date: Mon, 02 Sep 2019 06:57:17 -0000 In message <201908300201.x7U214qn086080@slippy.cwsent.com>, Cy Schubert writes: > In message om> > , Warner Losh writes: > > On Thu, Aug 29, 2019 at 3:26 PM Warner Losh wrote: > > > > > > > > > > > On Thu, Aug 29, 2019 at 1:05 PM Rodney W. Grimes < > > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > >> (unneeded context removed) > > >> > > >> > > In either scenario we end up reducing test coverage, which means we? > re > > >> > > going to push more bugs towards users. > > >> > > > > >> > > > I totally agree. This is an overly-bureaucratic solution in searc > h > > >> of > > >> > > > a problem. > > >> > > > > > >> > > > If this needs to be addressed at all (and I'm not sure it does), > > >> then > > >> > > > another sentence or two in bullet item 10 in section 18.1 [*] of t > he > > >> > > > committer's guide should be enough. And even then it needn't be > > >> > > > overly-formal and should just mention that if a commit does break > > >> the > > >> > > > build the committer is expected to be responsive to that problem a > nd > > >> > > > the commit might get reverted if they're unresponsive. I don't > > >> think > > >> > > > we need schedules. > > >> > > > > > >> > > I do feel that?s a better argument. We?ve always had a policy of > > >> > > reverting on request (AIUI), so this is more or less trying to be a > > >> > > strong restatement of that, more than a fundamental shift in policy. > > >> > > > > >> > > > >> > We don't have a policy to revert commit, actually revert commit is > > >> > something bad, it is kind of punishment, I have been there, nobody > > >> wants to > > >> > be there. Stop to push this non-sense argument. > > >> > > >> Here in lies one of the fundemental problems, this view by some that > > >> a "revert commit is something bad, it is kind of punishment". That is > > >> not true. Reverts are GREAT things, they allow the tree to be returned > > >> to a known state, usually quicly. The original commit is STILL IN SVN, > > >> and a bad revert can guess what.. be reverted!. > > >> > > >> IMHO the project as a whole needs to overcome its fear of reverts and > > >> start to use them for the great and powerful things that they are. > > >> > > >> This connection of bad and punishment needs to stop, and the sooner > > >> the better. > > >> > > > > > In the past, if someone had any follow on work at all in their tree, the > > reversion would be quite disruptive to that work. Most of the time it's a > > lot easier for me, with a lot less friction, to just fix issues that come > > up after the commit than to revert and prepare a new commit. Sure, it's > > possible, but it can destroy work in extreme cases. *THAT* is why I'm > > firmly in the camp of giving the original committer a shot at fixing things > > because it's much less disruptive to them, and generally we can get a fix > > into the tree faster. It reduces friction and encourages people to fix > > things quickly, imho, to hesitate a little on the revert. Especailly when > > the broken thing is the playstation loader on powerpc that can stay broken > > for the hour or six (or even days) it takes me to figure out why it > > broke... Often things away from the beaten path don't get discovered for > > days or weeks or months, and a reversion then can be extremely disruptive > > if there's other changes layered on top of the offending commit.... > > > > So the whole reversion issue is a lot more complicated than 'oh, it's still > > in svn'. There are real high costs associated with being too quick or > > liberal on the revert and those must be weighed against the damage the bad > > commit is doing.. > > I think that's why we need to define the problem first. > > The justification of the arbitrary numbers of minutes/hours isn't clear. > > I see there are possibly two trains of thought here which need to be > separated. > > 1. A general frustration by some. > > 2. A tool, a solution to a problem, I am unsure if it is related to #1. > > Why do I see this as such? > > The problem statement beings by saying that FreeBSD has a CI system that > performs compiles and runs automated tests. In the next paragraph it says > sometimes changes break compilation... > > This tells me that A) we have a solution which we discuss in B (the > problem). > > To my thinking we need to approach this from: A) we have a problem, maybe > backing it up with some stats some evidence of sorts. Then explore one or > preferably two solutions. Not to be hard on anyone and keeping my emotions > out of it, they way the problem statement is structured reads to me as a > solution looking for a problem. That's not to say we don't have a problem > (nor am I saying we do have a problem either). The problem statement is > structured to a foregone conclusion. > > I'd structure this by stating the problem (paragraph 2 and the bullet > points, though I think the problem needs to be explored a little more), > then discuss some of the timing issues regarding the fixing of the three > types of problems (compile, panic, and regressions, of which tests identify > regressions). > > I'm not saying that there is or isn't a problem but the problem statement > as written doesn't convince me there is a problem. It's leading me to a > conclusion. Thinking much of this week about how I approached this, it was wrong of me to structure this email in this way to convey I wasn't entirely convinced. This was critique and it should not have been. My email was offensive and for that I'm sorry. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Wed Oct 2 16:25:55 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 516721330D8 for ; Wed, 2 Oct 2019 16:25:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 46k1hx5Mf1z4f44 for ; Wed, 2 Oct 2019 16:25:52 +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 mail105.syd.optusnet.com.au (Postfix) with ESMTPS id EB5753628E2; Thu, 3 Oct 2019 02:25:46 +1000 (AEST) Date: Thu, 3 Oct 2019 02:25:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Sebastian Huber , FreeBSD Subject: Re: Why is tc_get_timecount() called two times in tc_init()? In-Reply-To: <20191002140040.GA44691@kib.kiev.ua> Message-ID: <20191003013314.O2151@besplex.bde.org> References: <0e27fb3e-0f60-68e1-dbba-f17c3d91c332@embedded-brains.de> <20191002140040.GA44691@kib.kiev.ua> 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=P6RKvmIu c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=s1G7sxBSAAAA:20 a=3O9r_qV0sLByUYXe2nsA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 46k1hx5Mf1z4f44 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.249 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; RCVD_IN_DNSWL_LOW(-0.10)[249.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[optusnet.com.au]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23:c]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[optusnet.com.au]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RWL_MAILSPIKE_POSSIBLE(0.00)[249.132.29.211.rep.mailspike.net : 127.0.0.17]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; IP_SCORE(0.00)[ip: (-5.13), ipnet: 211.28.0.0/14(-3.25), asn: 4804(-2.40), country: AU(0.01)]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 16:25:55 -0000 On Wed, 2 Oct 2019, Konstantin Belousov wrote: > On Tue, Oct 01, 2019 at 01:11:18PM +0200, Sebastian Huber wrote: >> Hello, >> >> since this commit >> >> https://github.com/freebsd/freebsd/commit/307f787e5a7f >> > It is not very useful to pass github hashes around. > > I think that the addition of the second tc_get_timecount() was done > earlier, in r95530, and there it has semi-useful comment > + /* Warm up new timecounter. */ > + (void)newtc->tc_get_timecount(newtc); > + (void)newtc->tc_get_timecount(newtc); > > The commit message is not helpful at all. The comment was correct when I added it in r48887. Then it was only attached to the first tc_get_timecounter() call which is necessary to start up or sync the hardware timecounter in some cases, e.g., for the i8254. After the warmup, r48887 called the preexisting function tc_switch_timecount() switch the software state. This function was unused (ifdefed out) but required only minor modifications. r95530 removes tc_switch_timecount() and replaces it by a second call to tc_get_timecounter() and an assignment of the new timecounter pointer to the active timecounter pointer, and removes the blank line that separates the warmup from the application. The second call and the assignment are all that is left of the function after moving its initialization. The second warmup looks like nonsense in both versions, and it is unclear how activation by plain assignment can work in the second version (the first version was in FreeBSD-3 or 4 and was locked by splclock()). The assignment is sloppy about memory ordering. The second warmup may have helped by accidentally forcing the assignment to be after the first warmup. (Some timecounters that need at least 1 warmup, e.g., the i854, use atomic ops that accidentally give sufficient ordering.) Later work on ordering may have reduced the sloppiness. > I do not see a timecounter which would need two get_timecount() calls > to start working properly now, but I can imagine that at time it was. I think it never helped much. For the TSC, the 2 calls are ordered only relatively each other on a single CPU. They are not ordered relative to memory. For the i8254, 1 call is enough. The ACPI timer does hardware accesses so it is in between. > I added Bruce to Cc: to may be get more context and explanation. > >> tc_get_timecount() is called two times in tc_init(). >> >> /* >> * Initialize a new timecounter and possibly use it. >> */ >> void >> tc_init(struct timecounter *tc) >> { >> [...] >> if (tc->tc_quality == timecounter->tc_quality && >> tc->tc_frequency < timecounter->tc_frequency) >> return; >> (void)tc->tc_get_timecount(tc); >> (void)tc->tc_get_timecount(tc); >> timecounter = tc; >> } >> >> What is the reason for this procedure? Bruce From owner-freebsd-hackers@freebsd.org Wed Aug 7 20:12:26 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B26F5B6453; Wed, 7 Aug 2019 20:12:26 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463jNB3W7bz4GTC; Wed, 7 Aug 2019 20:12:26 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x77KCOHh089133; Wed, 7 Aug 2019 13:12:24 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x77KCObt089132; Wed, 7 Aug 2019 13:12:24 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201908072012.x77KCObt089132@gndrsh.dnsmgr.net> Subject: Re: svn commit: r350550 - head/share/mk In-Reply-To: <86621ce5-3a8d-2e22-f146-3b0cc8252124@FreeBSD.org> To: Pedro Giffuni CC: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 463jNB3W7bz4GTC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.954,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 07 Aug 2019 20:12:26 -0000 X-Original-Date: Wed, 7 Aug 2019 13:12:24 -0700 (PDT) X-List-Received-Date: Wed, 07 Aug 2019 20:12:26 -0000 > On 07/08/2019 11:00, John Baldwin wrote: > > On 8/6/19 9:56 AM, Glen Barber wrote: > >> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >>> Author: jhb > >>> Date: Sat Aug 3 01:06:17 2019 > >>> New Revision: 350550 > >>> URL: https://svnweb.freebsd.org/changeset/base/350550 > >>> > >>> Log: > >>> Flip REPRODUCIBLE_BUILD back to off by default in head. > >>> > >>> Having the full uname output can be useful on head even with > >>> unmodified trees or trees that newvers.sh fails to recognize as > >>> modified. > >>> > >>> Reviewed by: emaste > >>> Differential Revision: https://reviews.freebsd.org/D20895 > >>> > >> I would like to request this commit be reverted. While the original > >> commit message to enable this knob stated the commit would be reverted > >> after stable/12 branched, I have seen no public complaints about > >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >> the benefit of disabling it by default -- why wouldn't we want > >> reproducibility?). > >> > >> To me, this feels like a step backwards, with no tangible benefit. > >> Note, newvers.sh does properly detect a modified tree if it can find > >> the VCS metadata directory (i.e., .git, .svn) -- I know this because > >> I personally helped with it. > >> > >> In my opinion, those that want the non-reproducible metadata included in > >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >> src.conf. Turning off a sane default for the benefit of what I suspect > >> is likely a short list of use cases feels like a step in the wrong > >> direction. > > My arguments for flipping this in head (and head only) are that the data > > provided in uname -a when this is disabled is useful for development, and > > that in head we do tailor settings towards development (e.g. GENERIC in > > head vs GENERIC in stable). > > > > The logic to handle modified trees has an inherent assumption that I think > > is false, at least for my workflow and I suspect many others. I do builds > > and tests of kernels on separate machines (VMs or bare metal) from where I > > use VCS to manage sources so that a kernel crash doesn't toast my source > > tree. The trees are then shared to the build/test machines via NFS. As > > a result, the build/test machines are not always able to detect that the > > tree is modified either because a subset of the checkout is exported via > > NFS, or the VCS tool isn't installed on the build/test machines because > > they are generally barebones systems with only a base installed. This > > does mean that flipping the knob off doesn't provide all of the same info, > > but it does provide the path, and the path matters because 'kgdb -n last' > > uses it, and because if you use separate directories for separate projects > > (e.g. git worktrees), then the path tells you which test kernel you booted. > > (It is not uncommon for me to have several test projects in flight on a > > single test machine for different branches.) > > > > In the original discussion on arch, we collectively recognized that > > developer builds vs release builds were different and needed different > > defaults. The compromise reached at that time was to depend on the VCS > > to detect developer builds to choose the policy. What I have found is that > > in practice for at least my workflow that doesn't actually work. I posit > > that the majority of kernels built from head are developer builds, not > > releases, and that the default should cater to that. You could also always > > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > > think would give a more accurate sense of when builds are releases or not. > > > > However, I will yield to whatever the consensus is. > > +1 keeping metadata in head. I am conflicted on this one, and I think there is a reasonable argument on both sides, but from what I have read here this appears to be mostly the kernel that is at issue, loss of the meta data from newvers.sh in the kernel is infact a PITA, even on stable or production release systems. I propose a compromise, add 2 knobs: WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname) WITH_REPRODUCIBLE_USERLAND (aka reproducible userland) WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat, and neither should be defined by default. Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC for releases/snapshots, but do not ship the system with it set (I can here a growl from Glen on this) Thus we build a reproducible kernel and ship it with the system but if the user builds a kernel it gets meta data to indicate it is no longer a stock kernel. FYI, upon finding I could not figure out what kernel I was running after installing 12.0 release I turnd off REPRODUCIBLE on my kernel build VM for 12.0. I do leave it on if I am building userland. Thoughts? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Aug 31 11:27:50 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B746CCEA8F for ; Sat, 31 Aug 2019 11:27:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 46LDbm59Lfz4PMZ; Sat, 31 Aug 2019 11:27:47 +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 mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 289C743DB62; Sat, 31 Aug 2019 21:27:42 +1000 (AEST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh cc: John Baldwin , Eugene Grosbein , Bruce Evans , Freebsd hackers list Subject: Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi In-Reply-To: Message-ID: <20190831194355.W930@besplex.bde.org> References: <20190820201257.7A9D41F8B7@freefall.freebsd.org> <20190830133855.W1405@besplex.bde.org> <5961a5af-d36c-4b8f-20c1-e7054b0149f4@grosbein.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=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=15r4UtA_DlBlPJ4m4IgA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-Rspamd-Queue-Id: 46LDbm59Lfz4PMZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-3.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.965,0]; IP_SCORE(0.00)[ip: (-6.95), ipnet: 211.28.0.0/14(-3.28), asn: 4804(-2.41), country: AU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sat, 31 Aug 2019 11:27:50 -0000 X-Original-Date: Sat, 31 Aug 2019 21:27:38 +1000 (EST) X-List-Received-Date: Sat, 31 Aug 2019 11:27:50 -0000 On Fri, 30 Aug 2019, Warner Losh wrote: > On Fri, Aug 30, 2019 at 10:06 AM John Baldwin wrote: > >> On 8/30/19 12:56 AM, Eugene Grosbein wrote: >>> 30.08.2019 11:03, Bruce Evans wrote: >>> >>>> The patch preserves some historical mistakes and adds some excessive >>>> verboseness about probe failures. I'm still waiting for jhb to reply to >>>> mails on 30 Oct 2015 and 23 Jan 2018 asking for a review of this patch >>>> or better a complete fix. >>> >>> Hmm... Maybe additional notification worth it :-) >> >> Hmm, I've used 'hint.foo.0.disabled=1' with many devices and it works fine. >> devctl enable can "undo" the disable post-boot even. >> >> It doesn't disable probing, only attaching once we know which driver a >> device >> is going to use. It doesn't work fine. I notice the problem mainly for sio vs uart (I statically configure lower quality drivers like uart and vt together with the drivers that I use for regression testing, and select the one to use by dynamic hints). sio and uart have hard-coded precedences. These usually select the wrong driver when neither is disabled. I forget if this is a problem if 1 of the drivers is disabled. It shouldn't be. sio's probe is still naughty and depends on setting up some state for sio's attach (as needed to support old isa irqs not being shareable, but that was broken before FreeBSD-4). So its probe is far from idempotent. uart's probe is not idempotent either -- see below. >> As far as I can tell, the patch makes it disable >> DEVICE_PROBE as well, but the vast majority of DEVICE_PROBE routines are >> idempotent. The patch has a flag variable which may be used to keep some of the probing benahviour. But the vast majority of probe routines are not idempotent. They change the hardware state, not just the softc. I don't remember any even attempting to restore the hardware state at the end of probes. Console drivers give further complications -- see below. >> Only a handful of legacy ISA drivers use 'return (0)' to try >> to >> pass state from probe to attach via the softc. Those drivers could choose >> to >> check the disabled flag in their probe routine and/or be fixed to have >> idempotent probe routines. I think the latter is probably the best path >> forward. sio is one of these. The problem is clearest for console drivers. Suppose sio and uart are both statically configured. One or both must be disabled as a console driver, else console initialzation of each spamds the one that was inititalized first. Normal probe/attach is not involved for this, but the same disable flag is used for this as fr probe/attach. This is not sufficient, due to the probe clobbering the console state, at least transiently. In -current: (1) suppose sio console is initially enabled and uart console is iniitially disabled. Then: - sio attaches as console - uart probe clobbers sio hardware state transiently and on completion - however, sio console doesn't use the ambient sio hardware state -- it switches the hardware state to a nearly-invariant console state, as needed to single-step through higher level state changes in sio via tcsetattr(); this works for adverse probes too. (2) suppose sio console is initially disabled and uart console is iniitially endabled. Then: - uart attaches as console - sio probe clobbers sio hardware state transiently and on completion - uart console does no context switching, so uart crashes even single- stepping its own tcsetattr(). It might work accidetally after sio probe completes. > The problem with disabling before PROBE is that if you have N foo devices, > hint.foo.0.disabled=1 will disable all of them as the probe routines all > return 'not me' and we try foo0 on each new instance... I'm pretty sure > that's why it's not done today and why I didn't do it when I added this > feature because how do you know you have foo0 until probe says 'yup, that's > mine'? > > Most of the old ISA routines that returned 0 I think have been deleted. > Maybe all since they were for fussy hardware from before the plug and play > era... There are still problems with devices being probed and attached on different buses. On x86, acpi is probed first and isa last (pnp probes naybe first, but rarey succeed). In one of my hardware configurations, IIRC the same hardware device is attached as uart2 on puc on acpi (or is it pci) and as sio4 on puc on acpi/pci unless it is fully disabled (in the probe too). This device works better as memory mapped, but I only committed the i/o mapped BARs for it in puc. uart hangs in the probe on the i/o mapped BARs since the device also needs regshift = 2 and support for regshift != 0 was axed from puc. puc has remarkably few memory mapped BARs in it, else it would hamg more. sio only supports i/o mapped BARs except in my uncomitted version. uart supports memory mapped BARs in puc, but only ones with regshift=0. The BAR type is determined dynamically, and the problem is mostly avoided by omitting memory-mapped BARs in puc data. Bruce From owner-freebsd-hackers@freebsd.org Wed Oct 2 17:12:32 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E83F613471E for ; Wed, 2 Oct 2019 17:12:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 46k2kl1X4sz3F5N for ; Wed, 2 Oct 2019 17:12:31 +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 mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 8C41643DE09; Thu, 3 Oct 2019 03:12:28 +1000 (AEST) Date: Thu, 3 Oct 2019 03:12:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Bruce Evans , Sebastian Huber , FreeBSD Subject: Re: Why is tc_get_timecount() called two times in tc_init()? In-Reply-To: <20191002163946.GE44691@kib.kiev.ua> Message-ID: <20191003030837.C2787@besplex.bde.org> References: <0e27fb3e-0f60-68e1-dbba-f17c3d91c332@embedded-brains.de> <20191002140040.GA44691@kib.kiev.ua> <20191003013314.O2151@besplex.bde.org> <20191002163946.GE44691@kib.kiev.ua> 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=P6RKvmIu c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=s1G7sxBSAAAA:20 a=tfnm91WlDkBHvcOSr7QA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 46k2kl1X4sz3F5N X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[optusnet.com.au]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23:c]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[optusnet.com.au]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RWL_MAILSPIKE_POSSIBLE(0.00)[246.132.29.211.rep.mailspike.net : 127.0.0.17]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; FREEMAIL_CC(0.00)[optusnet.com.au]; IP_SCORE(0.00)[ip: (-7.03), ipnet: 211.28.0.0/14(-3.24), asn: 4804(-2.39), country: AU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 17:12:33 -0000 On Wed, 2 Oct 2019, Konstantin Belousov wrote: > On Thu, Oct 03, 2019 at 02:25:46AM +1000, Bruce Evans wrote: >> On Wed, 2 Oct 2019, Konstantin Belousov wrote: >> >>> On Tue, Oct 01, 2019 at 01:11:18PM +0200, Sebastian Huber wrote: >>>> Hello, >>>> >>>> since this commit >>>> >>>> https://github.com/freebsd/freebsd/commit/307f787e5a7f >>>> >>> It is not very useful to pass github hashes around. >>> >>> I think that the addition of the second tc_get_timecount() was done >>> earlier, in r95530, and there it has semi-useful comment >>> + /* Warm up new timecounter. */ >>> + (void)newtc->tc_get_timecount(newtc); >>> + (void)newtc->tc_get_timecount(newtc); >>> >>> The commit message is not helpful at all. >> >> The comment was correct when I added it in r48887. Then it was only >> attached to the first tc_get_timecounter() call which is necessary to >> start up or sync the hardware timecounter in some cases, e.g., for the >> i8254. After the warmup, r48887 called the preexisting function >> tc_switch_timecount() switch the software state. This function was >> unused (ifdefed out) but required only minor modifications. >> >> r95530 removes tc_switch_timecount() and replaces it by a second call >> to tc_get_timecounter() and an assignment of the new timecounter pointer >> to the active timecounter pointer, and removes the blank line that >> separates the warmup from the application. The second call and the >> assignment are all that is left of the function after moving its >> initialization. >> >> The second warmup looks like nonsense in both versions, and it is >> unclear how activation by plain assignment can work in the second >> version (the first version was in FreeBSD-3 or 4 and was locked by >> splclock()). The assignment is sloppy about memory ordering. The >> second warmup may have helped by accidentally forcing the assignment >> to be after the first warmup. (Some timecounters that need at least >> 1 warmup, e.g., the i854, use atomic ops that accidentally give >> sufficient ordering.) Later work on ordering may have reduced the >> sloppiness. >> >>> I do not see a timecounter which would need two get_timecount() calls >>> to start working properly now, but I can imagine that at time it was. >> >> I think it never helped much. For the TSC, the 2 calls are ordered only >> relatively each other on a single CPU. They are not ordered relative to >> memory. For the i8254, 1 call is enough. The ACPI timer does hardware >> accesses so it is in between. > So the conclusion is that the second call can be removed, am I right ? Yes. All tc_get_timecount() functions should be checked for doing sufficient initialization in one call (so that deltas for subsequent calls are correct). Bruce From owner-freebsd-hackers@freebsd.org Fri Oct 4 13:38:07 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D5CF12E9D6 for ; Fri, 4 Oct 2019 13:38:07 +0000 (UTC) (envelope-from mufti11@web.de) Received: from mout.web.de (mout.web.de [212.227.17.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.web.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46l9tP6Zd5z4NFn for ; Fri, 4 Oct 2019 13:38:05 +0000 (UTC) (envelope-from mufti11@web.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1570196277; bh=+9rsDTWNHyZtdOxQXEKJBI3MhFA82BJaNHyDISbljeM=; h=X-UI-Sender-Class:To:From:Subject:Date; b=CSpZAGY5Jjz0WK/7md5H4mnYBDbiDajHcD6PxSWN3PjeLdxdMu4LZLIgbc1MRSnt0 tBOte1YQOkTJNKlcw7n2CqEealfud+ADFlMjx5/RuAa7r5SyvDgNiqzzhiip4im1eY BTtENjVtH+xzdHy4h52P3QIkRTR0+LHpEflKkXKU= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [192.168.178.79] ([109.193.194.217]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MPYNR-1iBiYs008X-004jT7 for ; Fri, 04 Oct 2019 15:13:31 +0200 To: freebsd-hackers@freebsd.org From: "J. Scheurich" Subject: Adding white_dune to FreeBSD ports collection ? Openpgp: preference=signencrypt Message-ID: <4b5b62b2-0376-568d-9d70-56077fae78e4@web.de> Date: Fri, 4 Oct 2019 15:13:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Provags-ID: V03:K1:lqGm3ZfFVkM4VcKKQulXPbVaBGkTRSS+lmpAgLHHZju5bJvI0N0 2LSPceAsaeB1f9usKAUG6Yy7rFwmgjrTR3jQbferO2LilUwLLDefuw1EUXBRo1WGz4tQLjS +89GCWLYPkzHAHHdhniMg/juFvoQdziF3FuHwT6FpTvB0P7cg2S8RL+0urdLutGxTmocE3E 3QSH2n+u5fJNuFZGNO5eQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:KvwhZfXiTjQ=:Yld4fNgZfNF+SC+mZ1K5OW 9FWc+2JgLziQmpG4ey9Mgkmg7f9ikYrXXtyQmBmQkkWL9Kw8EjFJmHjJHSvkk4DWnj6bg8jTn Tl9V11UyHiDtscMTFu9WZHAK33x5HeRUBdmZXVqKw96+xzUF/iDgUFlw5yzIMJxQtfuPBJkCr ltB7H5p8GFqJIXigFFDm+INMlEK4GzSTm3xdEeuQGobrvoNrynekfpaAWdzpAgZJJXve2r+Tw bhJUTy20Ue45uchAbT9TGDsVT/tSgB/QtdGnWBmDuC1Nro8qr//JuT8lMfK9HweaPA8zbREaz swG5DQU0pSChXUXEZA8PQg6903n4AY9vrzzwzXvzDr6tS59MCBdboEhH9W9jJWxxQbHhzhK57 eMUf+hVIZKTSBWNGNjZGpuHaFUBwKbANNaEd9pZSzcPuficOUzp8OV9ZT2ZYatKg8yexf8lI1 8eyZuBf8dhjQsVYouiWK+z1U31hQbdZaMmK+h9NtVCWXEgMLNskZPWfSvJlFaumM0f9VMhc8u 0gJ9d+dJ1HHXTQDX9eEDSNzrf7ALTERxu0NeMJk+H+zWrP4oj5g5gDD82sRn6sVAe0+vSZ23e Pv4i5hNXr09qplWwuXXBWDYCbxW+4AEwxwX3uQ4QFZGhW6rdk5sW7A+etwAvz1tCwKuiHMUP5 HAV+IwjbjhgpUvboZoius4nbtVmylziQDCICFEuSDIMKsloSK4WWMnx/A4MNiiE/lnktJWgwx S1oyh6ePyt6jw91kTtOqGqjXXbDaYs8mQeM+rZ/Evd1k2zi53GNWQNQT9Q6hwV4GkQbRh+M18 VYrYP2qegdiZsk5+gMou5npPicr9ZM6Lapo5LLg2rxYQibsb/pFz5noWlqOvlzEkQZeZDyHRR VAvffZAm5egvN3w3olUgEdQ6eqdz/q6mOvF7m0OxTgMTFDYWd08pUhM1qFXcVnikdwgWhrTWj 4T9Gl6cSahoUblIoNrHL1DghdGSagcRYl8SwsmM1th+VEsqQEJQuzqTWY42nKlovCgP1MY82M 1jrlBxeENnE8Bjby5YSv/jkv06yUCLjEGvnKluq9lgbhaiJIRYkqF6RplpW0XH+ndZX+IO0G8 JV0nkpqzlF2jwHUBl612568D4HQFGEnkB9Y54HomZBvNCj5dapb7IqS8q3N87tF1uiSigYUHF 912/W1Rm0dUERJFMVygZYcjicnSibt5qTT08r0s3KPec7OqfZS5yLDBFPVn3un22nDY8YDN5o Y3au7L1ib8mmTNGKjKc8FE+Keia5eGk+kNr+434g78iISjbNJxJFwWW8zY/8= X-Rspamd-Queue-Id: 46l9tP6Zd5z4NFn X-Spamd-Bar: +++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=web.de header.s=dbaedf251592 header.b=CSpZAGY5; dmarc=none; spf=pass (mx1.freebsd.org: domain of mufti11@web.de designates 212.227.17.12 as permitted sender) smtp.mailfrom=mufti11@web.de X-Spamd-Result: default: False [7.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:212.227.17.0/27]; FREEMAIL_FROM(0.00)[web.de]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[web.de:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[12.17.227.212.list.dnswl.org : 127.0.5.1]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[web.de]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[217.194.193.109.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[217.194.193.109.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; R_DKIM_ALLOW(0.00)[web.de:s=dbaedf251592]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[web.de.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[web.de]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; IP_SCORE_FREEMAIL(0.00)[]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_LONG(1.00)[1.000,0]; IP_SCORE(0.00)[ipnet: 212.227.0.0/16(-1.34), asn: 8560(2.06), country: DE(-0.01)]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; GREYLIST(0.00)[pass,body] X-Spam: Yes X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 13:38:07 -0000 Hi, I want to ask, if it is possible to add white_dune (wdune) to the FreeBSD ports collection. white_dune 0.28 (0.30?) was part of the ports collection, but the current version is 1.456. There is already a binary distribution for FreeBSD 12.0 on the website https://wdune.ourproject.org/ but it has been built with wdune-*/packager/freebsd/mkpkg.sh / "pkg create" so long MUFTI From owner-freebsd-hackers@freebsd.org Wed Aug 7 03:05:14 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA6EABC089 for ; Wed, 7 Aug 2019 03:05:14 +0000 (UTC) (envelope-from brightiup.zhuo@gmail.com) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463GZx66jDz47Yx for ; Wed, 7 Aug 2019 03:05:13 +0000 (UTC) (envelope-from brightiup.zhuo@gmail.com) Received: by mail-ot1-x32e.google.com with SMTP id x21so5236427otq.12 for ; Tue, 06 Aug 2019 20:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4tm6+20Mp08NpLzY/3Z/ibrY24mKTJVlQU1hePLNdLA=; b=tG7xP1N3HOotvmWpQKrfDXm8xPEA/hOnzB1nCCAVpElnjeEbKwxpoXHvkraZ6MwSZK BY0mSxnDCXtmIBgsbzihYAEFRAr1gAzEAvVF5NZrTuGYBpyuOYwFWRCkE3Ic6JSEpS5v URc5mGW/ByLF30GP3j6ArPJD+lXCBEXke8fuh6Kv8+4z+jkGVqaPiuNnUhe2svjia4hE V/ax+bOA6T45kTE+bL9fXu0+iH6Hb3vV73+8Kd/GrZF/mUT6U/wkIagjlwqSKBi4gA4f AKb0kzOmxe8d0tAe4VAl00oMkCHy349TVu4CZhYHWxiUmOU82IC0qVUpegvFtjM1htaT 6MXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4tm6+20Mp08NpLzY/3Z/ibrY24mKTJVlQU1hePLNdLA=; b=LGH8m31Hxvcal5whle0ynF8+Dl1AHcvqpy1GJKU5jvdQjT0cRJ6s5m4nnX5dV2ekRv zctnOCwzkUAntxuYYByF71rGhWMoEHElFoqWIgiKMijz+FM6SsbXGxg1LsZxuACYeYou LcMo0OJlF7Ure/JvHGqHJoH7NR4K/cZjNLDM+5gYsZ3jebWlGuRLZ8Y8e/InPujMXXOW 49i7tLvPbKVBtJ3rwf1ZV6NyJtiuBNXBhK698KapH0xtciaYvxiLVcI+9wSzz3itpdup L7kutgGDOMlrtCCcqVtf/A24iPHophHMIMyPUqV6UhCC0RxWhon76+5cRe/oBQQNx7m4 Gh9Q== X-Gm-Message-State: APjAAAWTQNkY6bUxmP1QcZQxW3v9pudqEehzuGLWK4fkeXWq0G2i5iCT 8Xx99Ag8m20s1AK4L6HfNHOl72YyKBiTvPYyDvxSuLZAOIc= X-Google-Smtp-Source: APXvYqyyJsygO1gXs2AslWUHgYR9J/5la5qTE+8BEpUh5d/+56J+Dz590T3GB4+pHVXHauGsYD8iGi5I9K13lKEetTo= X-Received: by 2002:a5e:8f08:: with SMTP id c8mr6121473iok.52.1565147112529; Tue, 06 Aug 2019 20:05:12 -0700 (PDT) MIME-Version: 1.0 From: Liang Zhuo Message-ID: Subject: Force kernel epoch calls To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 463GZx66jDz47Yx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=tG7xP1N3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of brightiupzhuo@gmail.com designates 2607:f8b0:4864:20::32e as permitted sender) smtp.mailfrom=brightiupzhuo@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.14), ipnet: 2607:f8b0::/32(-3.05), asn: 15169(-2.45), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[e.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 07 Aug 2019 03:05:15 -0000 X-Original-Date: Wed, 7 Aug 2019 11:05:01 +0800 X-List-Received-Date: Wed, 07 Aug 2019 03:05:15 -0000 Hi list, I have a problem with *epoch* while I am trying to write an exploit of a FreeBSD kernel bug. Specifically, many schedules are managed by epoch system, like *if_destroy()* which destroys a *struct ifnet* object, and *in_pcbfree_\* *defered()* which destroys a *struct inpcb* object. My question is that these schedules will only be called just before the process exits by *epoch_call_task() *as follow: fork_exit() -> gtaskqueue_thread_loop() -> gtaskqueue_run_locked() -> epoch_call_task() -> if_destroy()/in_pcbfree_defered() But I need to control the time of freeing of those objects as better as synchronization. Do do I have any methods to force these calls in epoch system to be called? Thanks, Brightiup From owner-freebsd-hackers@freebsd.org Sun Sep 8 05:55:51 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 04E15E9287; Sun, 8 Sep 2019 05:55:51 +0000 (UTC) (envelope-from stefan.kanthak@nexgo.de) Received: from vsmx009.vodafonemail.xion.oxcs.net (vsmx009.vodafonemail.xion.oxcs.net [153.92.174.87]) (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 46R0s10sg7z4Wrk; Sun, 8 Sep 2019 05:55:48 +0000 (UTC) (envelope-from stefan.kanthak@nexgo.de) Received: from vsmx001.vodafonemail.xion.oxcs.net (unknown [192.168.75.191]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTP id 2967015A7FF7; Sun, 8 Sep 2019 05:55:46 +0000 (UTC) Received: from H270 (unknown [93.230.223.140]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 8F3C515A8141; Sun, 8 Sep 2019 05:55:39 +0000 (UTC) Message-ID: <174BDDD122964DA9AD32D77663AB863D@H270> From: "Stefan Kanthak" To: , Cc: Subject: Shorterr releng/12.0/lib/msun/i387/s_remquo.S, releng/12.0/lib/msun/amd64/s_remquo.S, ... Organization: Me, myself & IT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158 X-VADE-STATUS: LEGIT X-Rspamd-Queue-Id: 46R0s10sg7z4Wrk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stefan.kanthak@nexgo.de designates 153.92.174.87 as permitted sender) smtp.mailfrom=stefan.kanthak@nexgo.de X-Spamd-Result: default: False [-2.06 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.932,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:153.92.174.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[nexgo.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.23)[-0.229,0]; HAS_X_PRIO_THREE(0.00)[3]; IP_SCORE(-0.00)[country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[87.174.92.153.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:60664, ipnet:153.92.174.0/24, country:DE]; MID_RHS_NOT_FQDN(0.50)[]; RECEIVED_SPAMHAUS_PBL(0.00)[140.223.230.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 08 Sep 2019 05:55:51 -0000 X-Original-Date: Sun, 8 Sep 2019 07:52:46 +0200 X-List-Received-Date: Sun, 08 Sep 2019 05:55:51 -0000 Hi, here's a patch to shave 4 instructions (and about 25% code size) from http://sources.freebsd.org/releng/12.0/lib/msun/i387/s_remquo.S http://sources.freebsd.org/releng/12.0/lib/msun/i387/s_remquof.S http://sources.freebsd.org/releng/12.0/lib/msun/i387/s_remquol.S http://sources.freebsd.org/releng/12.0/lib/msun/amd64/s_remquo.S http://sources.freebsd.org/releng/12.0/lib/msun/amd64/s_remquof.S http://sources.freebsd.org/releng/12.0/lib/msun/amd64/s_remquol.S Especially the negation is rather clumsy: 1. the 2 shifts by 16 to propagate the sign to all bits can be replaced with a single shift by 31, or with a CLTD alias CDQ (which is 2 bytes shorter); 2. the conversion of -1 to +1 via AND and its addition can be replaced by subtraction of -1. The minor differences between the code for the float, double and long double as well as the i387 and amd64 implementations are intended; pick the variant you like best. I prefer and recommend the variant with 3 ADC and 2 SHL instructions used for the i387 double-precision function http://sources.freebsd.org/releng/12.0/lib/msun/i387/s_remquo.S, which comes first. stay tuned Stefan Kanthak PS: if you ever need to run these functions on a CPU without barrel shifter, replace the first SHL or ROR with BT $14,%eax and the second SHL or ROL with BT $9,%eax ... and hope that BT doesn't use a slow shift under the hood. --- -/releng/12.0/lib/msun/i387/s_remquo.S +++ +/releng/12.0/lib/msun/i387/s_remquo.S @@ -34,1 +34,2 @@ ENTRY(remquo) + xorl %ecx,%ecx @@ -42,22 +43,17 @@ /* Extract the three low-order bits of the quotient from C0,C3,C1. */ - shrl $6,%eax - movl %eax,%ecx - andl $0x108,%eax - rorl $7,%eax - orl %eax,%ecx - roll $4,%eax - orl %ecx,%eax - andl $7,%eax + adcl %ecx,%ecx + shll $18,%eax + adcl %ecx,%ecx + shll $5,%eax + adcl %ecx,%ecx /* Negate the quotient bits if x*y<0. Avoid using an unpredictable branch. */ - movl 16(%esp),%ecx - xorl 8(%esp),%ecx - sarl $16,%ecx - sarl $16,%ecx - xorl %ecx,%eax - andl $1,%ecx - addl %ecx,%eax + movl 16(%esp),%eax + xorl 8(%esp),%eax + cltd + xorl %edx,%ecx + subl %edx,%ecx /* Store the quotient and return. */ - movl 20(%esp),%ecx - movl %eax,(%ecx) + movl 20(%esp),%eax + movl %ecx,(%eax) ret END(remquo) --- -/releng/12.0/lib/msun/i387/s_remquof.S +++ +/releng/12.0/lib/msun/i387/s_remquof.S @@ -42,22 +42,18 @@ /* Extract the three low-order bits of the quotient from C0,C3,C1. */ - shrl $6,%eax - movl %eax,%ecx - andl $0x108,%eax - rorl $7,%eax - orl %eax,%ecx - roll $4,%eax - orl %ecx,%eax - andl $7,%eax + sbbl %ecx,%ecx + negl %ecx + shll $18,%eax + adcl %ecx,%ecx + shll $5,%eax + adcl %ecx,%ecx /* Negate the quotient bits if x*y<0. Avoid using an unpredictable branch. */ - movl 8(%esp),%ecx - xorl 4(%esp),%ecx - sarl $16,%ecx - sarl $16,%ecx - xorl %ecx,%eax - andl $1,%ecx - addl %ecx,%eax + movl 8(%esp),%eax + xorl 4(%esp),%eax + cltd + xorl %edx,%ecx + subl %edx,%ecx /* Store the quotient and return. */ - movl 12(%esp),%ecx - movl %eax,(%ecx) + movl 12(%esp),%eax + movl %ecx,(%eax) ret END(remquof) --- -/releng/12.0/lib/msun/i387/s_remquol.S +++ +/releng/12.0/lib/msun/i387/s_remquol.S @@ -42,22 +42,19 @@ /* Extract the three low-order bits of the quotient from C0,C3,C1. */ - shrl $6,%eax - movl %eax,%ecx - andl $0x108,%eax - rorl $7,%eax - orl %eax,%ecx - roll $4,%eax - orl %ecx,%eax - andl $7,%eax + setc %cl + movzbl %cl,%ecx + shll $18,%eax + adcl %ecx,%ecx + shll $5,%eax + adcl %ecx,%ecx /* Negate the quotient bits if x*y<0. Avoid using an unpredictable branch. */ - movl 24(%esp),%ecx - xorl 12(%esp),%ecx - movsx %cx,%ecx - sarl $16,%ecx - sarl $16,%ecx - xorl %ecx,%eax - andl $1,%ecx - addl %ecx,%eax + movl 24(%esp),%eax + xorl 12(%esp),%eax + cwtl + cltd + xorl %edx,%ecx + subl %edx,%ecx /* Store the quotient and return. */ - movl 28(%esp),%ecx - movl %eax,(%ecx) + movl 28(%esp),%eax + movl %ecx,(%eax) ret +END(remquol) --- -/releng/12.0/lib/msun/amd64/s_remquo.S --- +/releng/12.0/lib/msun/amd64/s_remquo.S @@ -34,1 +35,2 @@ ENTRY(remquo) + xorl %ecx,%ecx @@ -44,19 +45,14 @@ /* Extract the three low-order bits of the quotient from C0,C3,C1. */ - shrl $6,%eax - movl %eax,%ecx - andl $0x108,%eax - rorl $7,%eax - orl %eax,%ecx - roll $4,%eax - orl %ecx,%eax - andl $7,%eax + adcl %ecx,%ecx + rorl $15,%eax + adcl %ecx,%ecx + roll $6,%eax + adcl %ecx,%ecx /* Negate the quotient bits if x*y<0. Avoid using an unpredictable branch. */ - movl -12(%rsp),%ecx - xorl -4(%rsp),%ecx - sarl $16,%ecx - sarl $16,%ecx - xorl %ecx,%eax - andl $1,%ecx - addl %ecx,%eax + movl -12(%rsp),%eax + xorl -4(%rsp),%eax + cltd + xorl %edx,%ecx + subl %edx,%ecx /* Store the quotient and return. */ - movl %eax,(%rdi) + movl %ecx,(%rdi) --- -/releng/12.0/lib/msun/amd64/s_remquof.S --- +/releng/12.0/lib/msun/amd64/s_remquof.S @@ -44,19 +44,15 @@ /* Extract the three low-order bits of the quotient from C0,C3,C1. */ - shrl $6,%eax - movl %eax,%ecx - andl $0x108,%eax - rorl $7,%eax - orl %eax,%ecx - roll $4,%eax - orl %ecx,%eax - andl $7,%eax + sbbl %ecx,%ecx + negl %ecx + rorl $15,%eax + adcl %ecx,%ecx + roll $6,%eax + adcl %ecx,%ecx /* Negate the quotient bits if x*y<0. Avoid using an unpredictable branch. */ - movl -8(%rsp),%ecx - xorl -4(%rsp),%ecx - sarl $16,%ecx - sarl $16,%ecx - xorl %ecx,%eax - andl $1,%ecx - addl %ecx,%eax + movl -8(%rsp),%eax + xorl -4(%rsp),%eax + cltd + xorl %edx,%ecx + subl %edx,%ecx /* Store the quotient and return. */ - movl %eax,(%rdi) + movl %ecx,(%rdi) --- -/releng/12.0/lib/msun/amd64/s_remquol.S --- +/releng/12.0/lib/msun/amd64/s_remquol.S @@ -42,21 +42,18 @@ /* Extract the three low-order bits of the quotient from C0,C3,C1. */ - shrl $6,%eax - movl %eax,%ecx - andl $0x108,%eax - rorl $7,%eax - orl %eax,%ecx - roll $4,%eax - orl %ecx,%eax - andl $7,%eax + setc %cl + movzbl %cl,%ecx + rorl $15,%eax + adcl %ecx,%ecx + roll $6,%eax + adcl %ecx,%ecx /* Negate the quotient bits if x*y<0. Avoid using an unpredictable branch. */ - movl 32(%rsp),%ecx - xorl 16(%rsp),%ecx - movsx %cx,%ecx - sarl $16,%ecx - sarl $16,%ecx - xorl %ecx,%eax - andl $1,%ecx - addl %ecx,%eax + movl 32(%rsp),%eax + xorl 16(%rsp),%eax + cwtl + cltd + xorl %edx,%ecx + subl %edx,%ecx /* Store the quotient and return. */ - movl %eax,(%rdi) + movl %ecx,(%rdi) ret +END(remquol) From owner-freebsd-hackers@freebsd.org Mon Sep 16 23:02:29 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1531CEF10D; Mon, 16 Sep 2019 23:02:29 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46XMFw1vLlz4GY1; Mon, 16 Sep 2019 23:02:28 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-io1-xd42.google.com with SMTP id f12so2918382iog.12; Mon, 16 Sep 2019 16:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ABHAaOdC0ZGtWKBW0F8L2MVhuSDFYtQmUjNQDZ63w6Y=; b=YxekkMpkesfeLSLZfVTtB2R65wPtzY5sKkzpFmODv45ZXnQ7AINCK2yTswOrdKJZEy 1mh64p550EOMqB4AVaoW8I++XB4q3cZ8XtVb1Nhs1OHSux9pDYx+3ldGp5iQ5ZWxIYld //WvthA6nV0ZLnb3n61KoPzu+S+qr/OqANieTtGPsOycyGR6i45RMiitrINsHGlT5Cxc FAL3vW4Oi/2045EbPoEZoPd3J5fV4J45IQW/M5vNlnGVkH4owE9dq1aX0G1/vjaQQbbM s2iExCKaA7JExv4t9Z9xU5hrlgrfGIyVBTEzg4tdY+t7XpUAYO3AOuDXRyAFneTXTYGo Bs1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ABHAaOdC0ZGtWKBW0F8L2MVhuSDFYtQmUjNQDZ63w6Y=; b=r366W8occ62dfxNfjgD+c2cGuPUowP5UeL/COigfmQ6O6G+pCqPU7435PJum2WvoQM eJX9hIOUe/2539KUPbGGt0jwfiwEkFXaZkD4pQOlkIPGDCDaj/iqTTxZNR6AxkiZImHo X2BT4jWAtFMtpAmLeNfjaE3NwwmRPx7cLHUaljKmprGt8SRwbI3x/e5fU/u/loGYfUTQ Mp1asFDc9Zqg4q8th9fkdYXBxMIEljGmStOcMCdN4Gzy8BrUZlyURDTwYiOXu0tw69sq WthDCmhWLN0ASNg43Mf7D23llLKpnlhI7PGsA6rkUK3/yTVTaWuOuYZnHGLkn5RRj2BS AKdA== X-Gm-Message-State: APjAAAXNJIaSa8HFwi61VNJgF/lGfJbB4l9jwjC7eACqWGh8RfudLUY7 FG2GVEjacZgu4yxIawTJqi8TatfcHVfMnWu3xBHRjoJm X-Google-Smtp-Source: APXvYqzeBiEO3CvRLg8+qKXHJpkgUZdiix/TyECxE6bjxyooUQ6lflFiaw4q+oWoTuUTedorhbQ48caEGeQkUmJTEdw= X-Received: by 2002:a5d:97cf:: with SMTP id k15mr302746ios.151.1568674946952; Mon, 16 Sep 2019 16:02:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9f01:0:0:0:0:0 with HTTP; Mon, 16 Sep 2019 16:02:26 -0700 (PDT) From: grarpamp Message-ID: Subject: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based To: freebsd-security@freebsd.org Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 46XMFw1vLlz4GY1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=YxekkMpk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::d42 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.00)[ip: (2.20), ipnet: 2607:f8b0::/32(-2.69), asn: 15169(-2.24), country: US(-0.05)]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2.4.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 16 Sep 2019 23:02:29 -0000 X-Original-Date: Mon, 16 Sep 2019 19:02:26 -0400 X-List-Received-Date: Mon, 16 Sep 2019 23:02:29 -0000 For consideration... SVN really may not offer much in the way of native internal self authenticating repo to cryptographic levels of security against bitrot, transit corruption and repo ops, external physical editing, have much signing options, etc. Similar to blockchain and ZFS hash merkle-ization, signing the repo init and later points tags commits, along with full verification toolset, is useful function. https://www.monotone.ca/ https://en.wikipedia.org/wiki/Monotone_(software) https://git-scm.com/ https://en.wikipedia.org/wiki/Git Maintaining the kernel's web of trust https://lwn.net/Articles/798230/ Distributing kernel developer PGP keys via pgpkeys.git https://lkml.org/lkml/2019/8/30/597 Signing patch flow https://lwn.net/Articles/737093/ Compromised security happens https://lwn.net/Articles/464233/ https://security.stackexchange.com/questions/67920/how-safe-are-signed-git-= tags-only-as-safe-as-sha-1-or-somehow-safer https://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptograph= ic-hash-function http://fossil-scm.org/index.html/doc/trunk/www/hashpolicy.wiki https://ericsink.com/vcbe/html/cryptographic_hashes.html https://svn.haxx.se/dev/archive-2015-06/0052.shtml http://git.661346.n2.nabble.com/Verifying-the-whole-repository-td1368311.ht= ml https://shattered.io/ https://www.youtube.com/watch?v=3DG8wQ88d85s4 https://en.wikipedia.org/wiki/Data_degradation https://git-scm.com/docs/git-fsck https://marc.info/?l=3Dgit&m=3D118143549107708 https://en.wikipedia.org/wiki/Comparison_of_version-control_software https://en.wikipedia.org/wiki/Deterministic_compilation https://www.monotone.ca/monotone.html#Trust-Evaluation-Hooks How does one know their entire copy of repo obtained on DVD, "mirror", or elsewhere cryptographically matches the authoritative repo... that any commits were actually signed off on... or that any reproducible builds are even reproducing the main repo... etc... cannot be done without secure crypto infrastructure at the very core. "User also knows that even if someone should break into the shared hosting server and tamper with the database, they won=E2=80=99t be able to inject malicious code into the project, because all revisions are signed by the team members, and he has set his Trust Evaluation Hooks so he doesn=E2=80=99t trust the server key for signing revisions. In monotone, the important trust consideration is on the signed content, rather than on the replication path by which that content arrived in your database." Note also CVS, which some BSD's still use (ahem: Open, Net), is even worse than SVN with zero protection at all in any component regarding this subject. It really time to migrate repo tech to year 2020. From owner-freebsd-hackers@freebsd.org Sat Oct 5 08:22:34 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A6E4412BA52 for ; Sat, 5 Oct 2019 08:22:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 46lfqr3521z4SZv for ; Sat, 5 Oct 2019 08:22:32 +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 mail105.syd.optusnet.com.au (Postfix) with ESMTPS id B0C38363A37; Sat, 5 Oct 2019 18:22:24 +1000 (AEST) Date: Sat, 5 Oct 2019 18:22:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans cc: Poul-Henning Kamp , Sebastian Huber , Warner Losh , Konstantin Belousov , FreeBSD Subject: Re: Why is tc_get_timecount() called two times in tc_init()? In-Reply-To: <20191005024530.U1757@besplex.bde.org> Message-ID: <20191005171343.X925@besplex.bde.org> References: <0e27fb3e-0f60-68e1-dbba-f17c3d91c332@embedded-brains.de> <20191002140040.GA44691@kib.kiev.ua> <20191003013314.O2151@besplex.bde.org> <20191002163946.GE44691@kib.kiev.ua> <20191003030837.C2787@besplex.bde.org> <20191003084021.GI44691@kib.kiev.ua> <47834.1570116246@critter.freebsd.dk> <141ee0af-2ff4-50fc-b4e4-6d1fc47e04f3@embedded-brains.de> <60167.1570198248@critter.freebsd.dk> <20191005024530.U1757@besplex.bde.org> 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=D+Q3ErZj c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=hPcphjJ6FNuFfpMK5-0A:9 a=oKGDZX8tWB3N5HoI:21 a=y4fVjnv8CydkU4kY:21 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 46lfqr3521z4SZv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.249 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_LOW(-0.10)[249.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[optusnet.com.au]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23:c]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[optusnet.com.au]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RWL_MAILSPIKE_POSSIBLE(0.00)[249.132.29.211.rep.mailspike.net : 127.0.0.17]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; IP_SCORE(0.00)[ip: (-5.09), ipnet: 211.28.0.0/14(-3.22), asn: 4804(-2.37), country: AU(0.01)]; FREEMAIL_TO(0.00)[optusnet.com.au]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2019 08:22:34 -0000 On Sat, 5 Oct 2019, Bruce Evans wrote: > On Fri, 4 Oct 2019, Poul-Henning Kamp wrote: >> >> As long as the counter can be read atomically and does not roll over >> in a matter of milliseconds, two reads are not necessary. > > The i8254 timecounter rolls over in a matter of microseconds if suitably > (mis)configured. E.g., for pcaudio i8254 periodic timer was run at > 16 kHz so it rolled over every 74 or 75 cycles. I only used this for > stress tests. > ... > No matter how fast the counter can roll over, 2 reads are only useful > or needed accidentally. And they are needed for rollover detection > for the i8254 timecounter: > > XX low = inb(TIMER_CNTR0); > XX high = inb(TIMER_CNTR0); > XX count = i8254_max_count - ((high << 8) | low); > XX if (count < i8254_lastcount || > > i8254_lastcount is garbage after only 1 read, but it is used here at the > start of the rollover detection. Thus the first read returns garbage > and also leaves some internal state as garbage, but it will update > i8254_lastcount in its internal state and that is enough for the second > read to work correctly. Oops, actually no warmup is needed for some cases, but if warmup is needed then 2 calls are little better than 1 for giving it. The internal state is managed by both i8254_get_timecount() and clkintr(). When clkintr() is not active, no warmup is needed. Then the first call to i8254_get_timecount() returns a random number that works as a reference point for subsequent calls, so everything works if this is used immediately to set the reference point th_offset. But when clkintr() is not active, the internal state is not fully initialized until the next clkintr()... > XX (!i8254_ticked && (clkintr_pending || > XX ((count < 20 || (!(flags & PSL_I) && > XX count < i8254_max_count / 2u)) && > XX i8254_pending != NULL && i8254_pending(i8254_intsrc))))) { > XX i8254_ticked = 1; > XX i8254_offset += i8254_max_count; > XX } ... since this fails to advance i8254_offset when it should, the next clkintr() does the advance, so the random reference point returned here becomes invalid (the time appears to step forward). > The need for 2 calls is only an optimization, but I don't a better way. The better way is is to just add a warmup/initialization method and call that instead of abusing tc_get_timecount(). Warmup is only enough if the timer is already running. Then a null warmup may be enough. The simplifications in r137037 depend on this. All attachable timecounters are assumed to be running all the time, so that making one active doesn't require starting its timer. For the i8254 timecounter, there were 2 cases as above: - i8254 not used for hardclock(), so not interrupting. No warmup needed - i8254 used for hardclock(), so interrupting. Syncing with its interrupt needed but not done. Now event timers give more cases: - i8254 used for one-shot timeouts, so interrupting. Syncing with its interrupt needed but not done (programming one-shot timeouts doesn't change internal state so leaves it as garbage). Syncing was done for pcaudio by only reprogramming the timeouts in the interrupt handler under suitable locks. A related bug: - the kern.timecounter.tc..frequency sysctl gives a random number corresponding to the above for timecounters other than the active one unless they have not wrapped since they were last read. Rollover is only detected for the active timecounter. The random number is fairly predictable if the hardware timecounter is real hardware (without complications for interrupt handling...). Reading it twice is useless for fixing this. Bruce From owner-freebsd-hackers@freebsd.org Wed Aug 7 20:41:16 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DBF43B73B1; Wed, 7 Aug 2019 20:41:16 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463k1R2q6lz4Jr1; Wed, 7 Aug 2019 20:41:14 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x77KfDIK089237; Wed, 7 Aug 2019 13:41:13 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x77KfDv1089236; Wed, 7 Aug 2019 13:41:13 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201908072041.x77KfDv1089236@gndrsh.dnsmgr.net> Subject: Re: svn commit: r350550 - head/share/mk In-Reply-To: To: Pedro Giffuni CC: rgrimes@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 463k1R2q6lz4Jr1 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.72 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[rgrimes@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; NEURAL_SPAM_MEDIUM(0.73)[0.727,0]; IP_SCORE(0.05)[ip: (0.15), ipnet: 69.59.192.0/19(0.08), asn: 13868(0.05), country: US(-0.05)]; NEURAL_HAM_SHORT(-0.63)[-0.630,0]; NEURAL_SPAM_LONG(0.68)[0.679,0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 07 Aug 2019 20:41:16 -0000 X-Original-Date: Wed, 7 Aug 2019 13:41:13 -0700 (PDT) X-List-Received-Date: Wed, 07 Aug 2019 20:41:16 -0000 > On 07/08/2019 15:12, Rodney W. Grimes wrote: > >> On 07/08/2019 11:00, John Baldwin wrote: > >>> On 8/6/19 9:56 AM, Glen Barber wrote: > >>>> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >>>>> Author: jhb > >>>>> Date: Sat Aug 3 01:06:17 2019 > >>>>> New Revision: 350550 > >>>>> URL: https://svnweb.freebsd.org/changeset/base/350550 > >>>>> > >>>>> Log: > >>>>> Flip REPRODUCIBLE_BUILD back to off by default in head. > >>>>> > >>>>> Having the full uname output can be useful on head even with > >>>>> unmodified trees or trees that newvers.sh fails to recognize as > >>>>> modified. > >>>>> > >>>>> Reviewed by: emaste > >>>>> Differential Revision: https://reviews.freebsd.org/D20895 > >>>>> > >>>> I would like to request this commit be reverted. While the original > >>>> commit message to enable this knob stated the commit would be reverted > >>>> after stable/12 branched, I have seen no public complaints about > >>>> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >>>> the benefit of disabling it by default -- why wouldn't we want > >>>> reproducibility?). > >>>> > >>>> To me, this feels like a step backwards, with no tangible benefit. > >>>> Note, newvers.sh does properly detect a modified tree if it can find > >>>> the VCS metadata directory (i.e., .git, .svn) -- I know this because > >>>> I personally helped with it. > >>>> > >>>> In my opinion, those that want the non-reproducible metadata included in > >>>> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >>>> src.conf. Turning off a sane default for the benefit of what I suspect > >>>> is likely a short list of use cases feels like a step in the wrong > >>>> direction. > >>> My arguments for flipping this in head (and head only) are that the data > >>> provided in uname -a when this is disabled is useful for development, and > >>> that in head we do tailor settings towards development (e.g. GENERIC in > >>> head vs GENERIC in stable). > >>> > >>> The logic to handle modified trees has an inherent assumption that I think > >>> is false, at least for my workflow and I suspect many others. I do builds > >>> and tests of kernels on separate machines (VMs or bare metal) from where I > >>> use VCS to manage sources so that a kernel crash doesn't toast my source > >>> tree. The trees are then shared to the build/test machines via NFS. As > >>> a result, the build/test machines are not always able to detect that the > >>> tree is modified either because a subset of the checkout is exported via > >>> NFS, or the VCS tool isn't installed on the build/test machines because > >>> they are generally barebones systems with only a base installed. This > >>> does mean that flipping the knob off doesn't provide all of the same info, > >>> but it does provide the path, and the path matters because 'kgdb -n last' > >>> uses it, and because if you use separate directories for separate projects > >>> (e.g. git worktrees), then the path tells you which test kernel you booted. > >>> (It is not uncommon for me to have several test projects in flight on a > >>> single test machine for different branches.) > >>> > >>> In the original discussion on arch, we collectively recognized that > >>> developer builds vs release builds were different and needed different > >>> defaults. The compromise reached at that time was to depend on the VCS > >>> to detect developer builds to choose the policy. What I have found is that > >>> in practice for at least my workflow that doesn't actually work. I posit > >>> that the majority of kernels built from head are developer builds, not > >>> releases, and that the default should cater to that. You could also always > >>> patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > >>> think would give a more accurate sense of when builds are releases or not. > >>> > >>> However, I will yield to whatever the consensus is. > >> +1 keeping metadata in head. > > I am conflicted on this one, and I think there is a reasonable argument > > on both sides, but from what I have read here this appears to be mostly > > the kernel that is at issue, loss of the meta data from newvers.sh in > > the kernel is infact a PITA, even on stable or production release > > systems. > > > > I propose a compromise, add 2 knobs: > > WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname) > > WITH_REPRODUCIBLE_USERLAND (aka reproducible userland) > > > > WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat, > > and neither should be defined by default. > Too complex IMHO. Either the system is reproducible or it isn't. > > Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC > > for releases/snapshots, but do not ship the system with it > > set (I can here a growl from Glen on this) Thus we build > > a reproducible kernel and ship it with the system but if > > the user builds a kernel it gets meta data to indicate it > > is no longer a stock kernel. > > FYI, upon finding I could not figure out what kernel I was running > > after installing 12.0 release I turnd off REPRODUCIBLE on my kernel > > build VM for 12.0. I do leave it on if I am building userland. > > > > Thoughts? > > Among other things, reproducible builds implies that pkg upgrades are Do you mean freebsd-update? > smaller. I see it makes sense to make releases, and in fact -stable, > completely reproducible. For -current I am fine with it not being > reproducible, > > All just IMHO. Let me try to add a case for it on ^head, weekly snapshots are built, if ^head was running reproducible it would be possible to diff these snapshots in a meaniful way. It would also mean one could get pretty creative with ZFS, zfs-snapshots and the built snapshots to actually have on line almost all binary versions of ^head in a fairly compact form. > Pedro. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sun Sep 8 14:45:30 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EDA3EF52AE; Sun, 8 Sep 2019 14:45:30 +0000 (UTC) (envelope-from stefan.kanthak@nexgo.de) Received: from mx009.vodafonemail.xion.oxcs.net (mx009.vodafonemail.xion.oxcs.net [153.92.174.39]) (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 46RDc95bWHz3yfj; Sun, 8 Sep 2019 14:45:29 +0000 (UTC) (envelope-from stefan.kanthak@nexgo.de) Received: from vsmx002.vodafonemail.xion.oxcs.net (unknown [192.168.75.192]) by mta-6-out.mta.xion.oxcs.net (Postfix) with ESMTP id 0AFE060D643; Sun, 8 Sep 2019 14:45:27 +0000 (UTC) Received: from H270 (unknown [93.230.223.140]) by mta-6-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 877DB60D6AE; Sun, 8 Sep 2019 14:45:22 +0000 (UTC) Message-ID: <769CF9CBA0A34DFA92C739C970FA2AAF@H270> From: "Stefan Kanthak" To: , Subject: Shorter releng/12.0/lib/msun/i387/e_exp.S and releng/12.0/lib/msun/i387/s_finite.S Organization: Me, myself & IT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158 X-VADE-STATUS: LEGIT X-Rspamd-Queue-Id: 46RDc95bWHz3yfj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stefan.kanthak@nexgo.de designates 153.92.174.39 as permitted sender) smtp.mailfrom=stefan.kanthak@nexgo.de X-Spamd-Result: default: False [-2.35 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:153.92.174.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[nexgo.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[39.174.92.153.list.dnswl.org : 127.0.5.2]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.40)[-0.396,0]; NEURAL_HAM_MEDIUM(-0.95)[-0.949,0]; IP_SCORE(-0.00)[country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:60664, ipnet:153.92.174.0/24, country:DE]; MIME_TRACE(0.00)[0:+] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 08 Sep 2019 14:45:31 -0000 X-Original-Date: Sun, 8 Sep 2019 16:37:03 +0200 X-List-Received-Date: Sun, 08 Sep 2019 14:45:31 -0000 Hi, here's a patch to remove a conditional branch (and more) from http://sources.freebsd.org/releng/12.0/lib/msun/i387/e_exp.S plus a patch to shave some bytes (immediate operands) from http://sources.freebsd.org/releng/12.0/lib/msun/i387/s_finite.S stay tuned Stefan Kanthak --- -/releng/12.0/lib/msun/i387/e_exp.S +++ +/releng/12.0/lib/msun/i387/e_exp.S @@ -45,7 +45,25 @@ movl 8(%esp),%eax - andl $0x7fffffff,%eax - cmpl $0x7ff00000,%eax - jae x_Inf_or_NaN + leal (%eax+%eax),%edx + cmpl $0xffe00000,%edx + jb finite + /* + * Return 0 if x is -Inf. Otherwise just return x; when x is Inf + * this gives Inf, and when x is a NaN this gives the same result + * as (x + x) (x quieted). + */ + cmpl 4(%esp),$0 + sbbl $0xfff00000,%eax + je minus_inf + +nan: fldl 4(%esp) + ret +minus_inf: + fldz + ret + +finite: + fldl 4(%esp) + @@ -80,19 +98,3 @@ ret - -x_Inf_or_NaN: - /* - * Return 0 if x is -Inf. Otherwise just return x; when x is Inf - * this gives Inf, and when x is a NaN this gives the same result - * as (x + x) (x quieted). - */ - cmpl $0xfff00000,8(%esp) - jne x_not_minus_Inf - cmpl $0,4(%esp) - jne x_not_minus_Inf - fldz - ret - -x_not_minus_Inf: - fldl 4(%esp) - ret END(exp) --- -/releng/12.0/lib/msun/i387/s_finite.S +++ +/releng/12.0/lib/msun/i387/s_finite.S @@ -39,8 +39,8 @@ ENTRY(finite) movl 8(%esp),%eax - andl $0x7ff00000, %eax - cmpl $0x7ff00000, %eax + addl %eax, %eax + cmpl $0xffe00000, %eax setneb %al - andl $0x000000ff, %eax + movzbl %al, %eax ret END(finite) From owner-freebsd-hackers@freebsd.org Tue Sep 10 15:19:37 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C0BA2D983D; Tue, 10 Sep 2019 15:19:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 46STGb2vV0z4YSk; Tue, 10 Sep 2019 15:19:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.103] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id C5DAC43E52E; Wed, 11 Sep 2019 01:19:30 +1000 (AEST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stefan Kanthak cc: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Shorter releng/12.0/lib/msun/i387/e_exp.S and releng/12.0/lib/msun/i387/s_finite.S In-Reply-To: <769CF9CBA0A34DFA92C739C970FA2AAF@H270> Message-ID: <20190910230930.Q1373@besplex.bde.org> References: <769CF9CBA0A34DFA92C739C970FA2AAF@H270> 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=D+Q3ErZj c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=RyLDTv5gonMbmEc0r54A:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-Rspamd-Queue-Id: 46STGb2vV0z4YSk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [0.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(0.00)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; RBL_MAILSPIKE_WORST(2.00)[246.132.29.211.rep.mailspike.net : 127.0.0.10]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; TO_DN_SOME(0.00)[]; BAD_REP_POLICIES(0.10)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-6.96), ipnet: 211.28.0.0/14(-3.27), asn: 4804(-2.40), country: AU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 10 Sep 2019 15:19:37 -0000 X-Original-Date: Wed, 11 Sep 2019 01:19:29 +1000 (EST) X-List-Received-Date: Tue, 10 Sep 2019 15:19:37 -0000 On Sun, 8 Sep 2019, Stefan Kanthak wrote: I recently got diagnosed as having serious medical problems and am not sure if I care about this... > here's a patch to remove a conditional branch (and more) from > http://sources.freebsd.org/releng/12.0/lib/msun/i387/e_exp.S > plus a patch to shave some bytes (immediate operands) from > http://sources.freebsd.org/releng/12.0/lib/msun/i387/s_finite.S Anyway, don't bother with these functions. They should never have been written in asm and should go away. Improving the mod and remainder functions is more useful and difficult since they are in asm on amd64 too and there seems to be no better way to implement them on all x86 than to use the i387, but they are still slow. > --- -/releng/12.0/lib/msun/i387/e_exp.S > +++ +/releng/12.0/lib/msun/i387/e_exp.S This went away in my version in 2012 or 2013 together with implementing the long double hyperbolic functions. My version uses the same algorithm in all precision for the hyperbolic functions, but only the long double version was committed (in 2013). The uncommitted parts are faster and more accurate. The same methods work relatively trivially for exp() and expf(), except they are insignificantly faster than better d C version after improving the accuracy of that to be slightly worse than the asm version. I gave up on plans to use the same algorithm in all precisions for exp*(). The long double version is too sophisticated to be fast, after developments in x86 CPUs and compilers made the old Sun C versions fast. Summary of implementations of exp*() on x86: - expf(): use the same C version on amd64 and i386 (Cygnus translation of Sun version with some FreeBSD optimizations). This is fast and is currently little less accurate than it should be - exp(): use the C version on amd64 (Sun version with some FreeBSD optimizations). This is fast and is currently little less accurate than it should be. Use the asm version on i386. This is slow since it switches the rounding precision. It needs the 11 extra bits of precision to barely deliver a double precision result to within 1 ulp. > @@ -45,7 +45,25 @@ > movl 8(%esp),%eax > - andl $0x7fffffff,%eax > - cmpl $0x7ff00000,%eax > - jae x_Inf_or_NaN > + leal (%eax+%eax),%edx > + cmpl $0xffe00000,%edx This removes 1 instruction and 1 dependency, not a branch. Seems reasonable. I would try to do it all in %eax. Check what compilers do for the C version of finite() where this check is clearer and easier to optimize (see below). All of this can be written in C with about 1 line of inline asm, and then compilers can generate better code. > + jb finite This seems to pessimize the branch logic in all cases (as would be done in C by getting __predict_mumble() backwards). The branches were carefully optimized (hopefully not backwards) for the i386 and i486 and this happens to be best for later CPUs too. Taken branches are slower on old CPUs, so the code was arranged to not branch in the usual (finite) case. Newer CPUs only use static branch prediction for the first branch, so the branch organization rarely matters except in large code (not like here) where moving the unusual case far away is good for caching. The static prediction is usuually that the first forward branch is not taken while the first backward branch is taken. So the forward branch to the non-finite case was accidentally correct. > > + /* > + * Return 0 if x is -Inf. Otherwise just return x; when x is Inf > + * this gives Inf, and when x is a NaN this gives the same result > + * as (x + x) (x quieted). > + */ > + cmpl 4(%esp),$0 > + sbbl $0xfff00000,%eax > + je minus_inf > + > +nan: > fldl 4(%esp) > + ret > > +minus_inf: > + fldz > + ret > + > +finite: > + fldl 4(%esp) > + > @@ -80,19 +98,3 @@ > ret > - > -x_Inf_or_NaN: > - /* > - * Return 0 if x is -Inf. Otherwise just return x; when x is Inf > - * this gives Inf, and when x is a NaN this gives the same result > - * as (x + x) (x quieted). > - */ > - cmpl $0xfff00000,8(%esp) > - jne x_not_minus_Inf > - cmpl $0,4(%esp) > - jne x_not_minus_Inf > - fldz > - ret > - > -x_not_minus_Inf: > - fldl 4(%esp) > - ret Details not checked. Space/time efficiency doesn't matter in the non-finite case. But see s_expl.c where the magic expression (-1 / x) is used for the return value to optimize for space (it avoids branches but the division is slow). > END(exp) > > --- -/releng/12.0/lib/msun/i387/s_finite.S > +++ +/releng/12.0/lib/msun/i387/s_finite.S This function has several layers of reasons to not exist. It seems to be only a Sun extension to C90. It is not declared in , but exists in libm as namespace pollution to support old ABIs. C99 has the better API isfinite() which is type-generic. I thought that this was usually inlined. Actually, it seems to be implemented by calling __isfinite(), and not this finite(). libm also has finite() in C. Not inlining this and/or having no way to know if it is efficiently inlined makes it unusable in optimized code. > @@ -39,8 +39,8 @@ > ENTRY(finite) > movl 8(%esp),%eax > - andl $0x7ff00000, %eax > - cmpl $0x7ff00000, %eax > + addl %eax, %eax > + cmpl $0xffe00000, %eax This doesn't reduce the number of instructions or dependencies, so it is less worth doing than similar changes above. > setneb %al This is now broken since setneb is only correct after masking out the unimportant bits. > - andl $0x000000ff, %eax > + movzbl %al, %eax > ret Old bug: extra instructions to avoid the branch might be a pessimization all CPUs: - perhaps cmov is best on newer CPUs, but it is unportable - the extra instructions and possibly movz instead of and are slower on old CPUs, while branch prediction is fast for the usual case on newer CPUs. > END(finite) Check what compilers generate for the C versions of finite() and __isfinite() with -fomit-frame-pointer -march=mumble (especially i386) and __predict_mumble(). The best code (better than the above) is for finite(). Oops, it is only gcc-4.2.1 that generates very bad code for __isfinite(). s_finite.c uses masks and compilers don't reorganize this much. s_isfinite.c uses hard-coded bit-fields which some compilers don't optimize very well. Neither does the above, or the standard access macros using bit-fields -- they tend to produce store-to-load mismatches. Well, I finally found where this is inlined. Use __builtin_isfinite() instead of isfinite(). Then gcc generates a libcall to __builtin_isfinite(), while clang generates inline code which is much larger and often slower than any of the above, but it at least avoids store-to-load mismatches and doesn't misclassify long doubles in unsupported formats as finite when they are actually NaNs. It also generates exceptions for signaling NaNs in some cases, which is arguably wrong. The fpclassify and isfinite, etc., macros in are already too complicated but not nearly complicated enough to decide if the corresponding builtins should be used. Bruce From owner-freebsd-hackers@freebsd.org Wed Aug 28 11:30:27 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9E07D9A07; Wed, 28 Aug 2019 11:30:27 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46JNpB02r7z45PN; Wed, 28 Aug 2019 11:30:25 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5B1657F2.dip0.t-ipconnect.de [91.22.87.242]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 90A9F14CB; Wed, 28 Aug 2019 13:20:22 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id BF40C936C; Wed, 28 Aug 2019 13:20:19 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.15.2/8.14.4/Submit) id x7SBKJnj025847; Wed, 28 Aug 2019 13:20:19 +0200 (CEST) (envelope-from Alexander@leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@leidinger.net using -f Received: from [::ffff:31.3.144.27] ([::ffff:31.3.144.27]) by webmail.leidinger.net (Horde Framework) with HTTPS; Wed, 28 Aug 2019 13:20:19 +0200 Message-ID: <20190828132019.Horde.u4cw2bP8C-GNjeokW3YPrg9@webmail.leidinger.net> From: Alexander Leidinger To: Li-Wen Hsu Cc: fcp@freebsd.org, FreeBSD Hackers Subject: Re: FCP 20190401-ci_policy: CI policy In-Reply-To: User-Agent: Horde Application Framework 5 Accept-Language: de,en Content-Type: multipart/signed; boundary="=_Pc7I2F4qlUaL4QpRwd9TYBt"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1566991222; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=VDN9vUTW2Fy9Z1wtBl+AxkR7Odxzd2veiInw+VEJJaI=; b=xtHWJZ6yXa5EYEzqzGQ8Kv/EgHK3M7/rRDhWJCpUzAc+yOqmZS+crc1lnlbVcu9LZM9OOn 7mXc1ez8W1H5AXVMJVHe0GEMQlNhq0XZn5Whn3qBEt5R/57CZFgFFppYHdCBeQCbuAN5Y1 Fj4c4l22VH95BvBi0Y0SZrqtWlC87k8csYqFK27CheO8gJwEnwoQ+UA0EpHgYpMLAb2qtq voo0MptlsaZ8VhuaGH2S3U48tvBMCUC8SWiJXvcUo3iO5wYHNL91yAkapL5e9BqNLr/uP6 W/YojhxXIAXzDCNz0OYdggwCE0YmBVU8H+J/ku/61a7Q/K5sKU0aE8gZLqwwtg== ARC-Seal: i=1; s=outgoing-alex; d=leidinger.net; t=1566991222; a=rsa-sha256; cv=none; b=Vh0mtNCX9O6mxzzRlUfEpNc4MO42s5kf3pprYhU3wRx4zAnsTfxyWgaMC+MdOpTirAMKAM mca9/2nQvsXolN+22KJEd7rZYiEiSk+CJdX9xhZfeUFiqg5d60w5ICAwC4eBqn2m38GaRR n05xImAWJDAQsOTbjh+QURn7iQfM0r30nGbMptc8FZgKPj86VXpeyHWPkXjCLWQ8K0r7xC CJUjXIKcjxJzqJ4Fs++PpRfaEvCaRQxInY+pH8eVYYPZoy0m2SHcc3k19I/bZGTOixA+rk ZLCfOEelmdyJKNB4qHQ3vuqX7mqEue4pUbU4WuJ5I0Z/32j9DS4viKZ9ADJ5Dg== ARC-Authentication-Results: i=1; mailgate.Leidinger.net; auth=pass smtp.auth=netchild@leidinger.net smtp.mailfrom=Alexander@leidinger.net X-Rspamd-Queue-Id: 46JNpB02r7z45PN X-Spamd-Bar: --------- X-Spamd-Result: default: False [-9.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; XAW_SERVICE_ACCT(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; IP_SCORE(-3.72)[ip: (-9.80), ipnet: 2a00:1828::/32(-4.89), asn: 34240(-3.88), country: DE(-0.01)]; SIGNED_PGP(-2.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[242.87.22.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; ARC_ALLOW(-1.00)[i=1]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 28 Aug 2019 11:30:27 -0000 X-Original-Date: Wed, 28 Aug 2019 13:20:19 +0200 X-List-Received-Date: Wed, 28 Aug 2019 11:30:27 -0000 This message is in MIME format and has been PGP signed. --=_Pc7I2F4qlUaL4QpRwd9TYBt Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Li-Wen Hsu (from Wed, 28 Aug 2019 12:29:58 +080= 0): > It seems I was doing wrong that just changed the content of this FCP > to "feedback", but did not send to the right mailing lists. > > So I would like to make an announcement that the FCP > 20190401-ci_policy "CI policy": > > https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md > > is officially in "feedback" state to hopefully receive more comments > and suggestions, then we can move on for the next FCP state. Last sentence in the paragraph of "Notification" needs a content fix,=20=20 there=20are several superfluous words... Waiting period: Why do you differentiate between "all platforms" and "a tier 1=20=20 platform"?=20By definition a tier 1 platform is the highest level of=20=20 platform=20we have and as such it has the highest priority, isn't it? 15 minutes is a little bit short in my opinion. Both items together: I suggest to remove the "all platforms"=20=20 completely=20without replacement and keep the rest as is. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_Pc7I2F4qlUaL4QpRwd9TYBt Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJdZmNzAAoJEBINsJsD+NiG+sEP/iaMi2BTAEuaEkzI6O/HeY2R eNnxoRyp4mMnATq8jUe4eBZt2BQ1Qi6LPMcJpbMEmSOuteWS7VhuO4RuGJTzw9I5 PRSkEIX963rih/ktcrWfEMhbssOCykd2UEBMC71bQKmRtw1kpgso/EXJq21d6W1v /5ZQIMUTBm+X12zegW/PSm+DtrxefFq5fS3P1RGTVGTdzyFRQuj0+wUTD7zHaz6P 8SGw9IrIuWQDL/84EdnCMq44EyrGeF/rQnpVpFmmwNiR7Kl2POl1ZKWACdgSpmFR m7K9Xjjz97ec8oHBFYonUJoysAYZo40lkZvt3YcgCL64DCAeATdYLZjA0+f9QQkO O3E6gdaec/3/GF4r/pkYPzLNWdan80QuvbLj/tHmPTmRwYdpAKatY7ICty+T5sX2 nx/Ht7YSNJBkN0MmNS92bh7i+vNErOLqiQIkZEvUw+V+ysiMisFwDe8BqHl+pf61 T1Jw+kSy3Y/wwFYa3eMOy45lTTDDMz67Tg75XUfw8YXhgS1Kbgb0dK/GNxg7b3jT 8bDYD0i2KEQeOJ73YotFFe893W1qPibJngfW7YvKwuV4H1ncGDkvSdsLSuh+hgEB 2fW29krTt5BBCzfNTUpSfGPBGlGR9OgofN8O4QV8yL4ZIN8ATqSBNZd18DHleFcw V9AgGXNS9CHMAhlOkkdw =PU8L -----END PGP SIGNATURE----- --=_Pc7I2F4qlUaL4QpRwd9TYBt-- From owner-freebsd-hackers@freebsd.org Sat Sep 21 17:41:30 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 35D4812ABBF; Sat, 21 Sep 2019 17:41:30 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (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 46bHvF1bgSz3Jhx; Sat, 21 Sep 2019 17:41:28 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 83148356; Sat, 21 Sep 2019 13:41:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 21 Sep 2019 13:41:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ULKGKc KSdU85tjJHpaMRoQu/DWd8r8FHge9knP2DPIs=; b=rMitsi8HpB6vqVAqteN+oM 5WBInHxkPRNCn9wlEodVqhqbA3g9BZExn8gsxooIHLsE2OL5KApIKE5N4lOsJ9Ub FmZ1ivncO9wYFYGtnMLjToWYf4Rl4n20e9obIucra969MTQcAb+Hy1F3ZP4cvAwN GszQBgmFoQaULpwMGvmGJ3Wg079AZAdfh5SYd3+Jeu9+3bchBgkYsXwY8hDQ5sFa RtXBFlqZP+MGZSSPi8FscePCuUIGgBD7MNzrjA40q/WVHo1RuV2VFZG02mip6nt+ AIDBU2WdOVZkifnPPzguwkBPCgbY3m7Bj7Kl0vm4ITMTYxUmCJczFPHNvxAdQe8Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeggdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttd dttddtredvnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceouggrnhhivghlshhh segrphgrtghhvgdrohhrgheqnecukfhppeejledrudejiedrkedurdefgeenucfrrghrrg hmpehmrghilhhfrhhomhepuggrnhhivghlshhhsegrphgrtghhvgdrohhrghenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: from tarpaulin.shahaf.local2 (bzq-79-176-81-34.red.bezeqint.net [79.176.81.34]) by mail.messagingengine.com (Postfix) with ESMTPA id AA927D6005F; Sat, 21 Sep 2019 13:41:25 -0400 (EDT) Received: by tarpaulin.shahaf.local2 (Postfix, from userid 1005) id 46bHv72r16zZf; Sat, 21 Sep 2019 17:41:23 +0000 (UTC) From: Daniel Shahaf To: freebsd-hackers@freebsd.org Cc: freebsd-security@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based Message-ID: <20190921174123.66q4coslqqx5axct@tarpaulin.shahaf.local2> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: 46bHvF1bgSz3Jhx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=rMitsi8H; dmarc=none; spf=softfail (mx1.freebsd.org: 64.147.123.24 is neither permitted nor denied by domain of danielsh@apache.org) smtp.mailfrom=danielsh@apache.org X-Spamd-Result: default: False [-5.88 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[apache.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-3.48)[ip: (-9.78), ipnet: 64.147.123.0/24(-4.90), asn: 11403(-2.68), country: US(-0.05)]; DKIM_TRACE(0.00)[messagingengine.com:+]; RCVD_IN_DNSWL_LOW(-0.10)[24.123.147.64.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[34.81.176.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-Mailman-Approved-At: Sat, 12 Oct 2019 23:39:36 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sat, 21 Sep 2019 17:41:30 -0000 X-Original-Date: Sat, 21 Sep 2019 17:41:23 +0000 X-List-Received-Date: Sat, 21 Sep 2019 17:41:30 -0000 grarpamp wrote on Fri, Sep 20, 2019 at 17:04:08 -0400: > How does one know their entire copy of repo obtained on > DVD, "mirror", or elsewhere cryptographically > matches the authoritative repo... If someone wanted to add "signed commits" functionality to svn, I think that would be possible and even not too hard.