From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: bug#30820: Chunked store references in compiled code break grafting (again) Date: Mon, 19 Mar 2018 22:34:02 +0100 Message-ID: <20180319223402.1ba0a369@scratchpost.org> References: <87o9jq7j7r.fsf@gnu.org> <87muz3dgy1.fsf@netris.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/nDHACSvVxixn.UDyI5uLVE+"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ey2Qs-0006TU-Kg for bug-guix@gnu.org; Mon, 19 Mar 2018 17:35:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ey2Qo-0007lR-Mc for bug-guix@gnu.org; Mon, 19 Mar 2018 17:35:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:34385) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ey2Qo-0007lE-J9 for bug-guix@gnu.org; Mon, 19 Mar 2018 17:35:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87muz3dgy1.fsf@netris.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 30820@debbugs.gnu.org --Sig_/nDHACSvVxixn.UDyI5uLVE+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Mark, On Mon, 19 Mar 2018 15:05:26 -0400 Mark H Weaver wrote: > I think that we should generalize our reference scanning and grafting > code to support store references broken into pieces, as long as each > piece containing part of the hash is at least 8 bytes long. I don't think it's possible to get that to work reliably over all possible optimizations. I mean why 8 Byte? That's probably because of the 8 Byte registers on x86_64. What would happen on ARM? (32 bit registers)? And on MIPS (immediates only smaller than 32 bits)? What if gcc finds some repetition in the hash and decides not to load the register again the second time? I think the best way - since we have control over the entire toolchain anyw= ay - is to make gcc not do the data inlining in the first place. As far as I understand the gcc patches work after all. Ludo just made a mistake testing it. Although when we do this patching of gcc we should add a test to gcc that makes sure that the data inlining is indeed not there anymore for store paths. > Here's my preliminary proposal: >=20 > (1) The reference scanner should recognize any 8-byte substring of a > hash as a valid reference to that hash. >=20 > (2) To enable reliable grafting of chunked references, we should impose > the following new restrictions: (a) the store prefix must be at > least 6 bytes, (b) grafting can change only the hash, not the > readable part of the store name, and (c) the readable part of the > store name must be at least 6 bytes. >=20 > (3) The grafter should recognize and replace any 8-byte subsequence of > the absolute store file name. >=20 > The rationale for the restrictions is to ensure that any byte that needs > to be modified by the grafter should be part of an 8-byte substring of > the absolute store file name. This requires that there be at least 7 > bytes of known text before the first changed byte and after the last > changed byte. This is needed to provide a reasonable upper bound on the > probability of grafting a matching sequence of bytes that is not a store > reference. I think that is a good way to get the risk down - but it will not actually fix the problem for good. Also, complexity like the above makes the reference scanner more brittle and it's easier for bugs to hide in it (and it's slower). I think the gcc patch is actually a better way. --Sig_/nDHACSvVxixn.UDyI5uLVE+ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlqwLMoACgkQ5xo1VCww uqXPpQgAlFrKx8F34L34+KkDcib8705k0QtyrrsWlzQn7DrgqwfIZl/SIiciMOj6 0qPVCBF6+qxdd6SXL8/CbCHn/7J3wHY9QDlTIHpIbVB79IvWQ0BK8cEj1VbfK/l+ 2Z6OXT+huec0Ej6HO3NPfI6sYjcEFz0VsQyAcsddb+CgWTdaeYpsaPgg3NIyuP2B uMbvu6DF3kKZU3o50hKNoV8rl54LohvaTE6agp+ahWdjq8uKsWbygXe4QJbRNc74 OWtrujIicfRshG9LUulnmOaMAUixTLSLx0Rr6GpxQdkcEhEytG6Qp3DyPa/6lAUy LLhNAhTvp2S8c/WPVYVyJ0dxbed+Eg== =IOCW -----END PGP SIGNATURE----- --Sig_/nDHACSvVxixn.UDyI5uLVE+--