From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#30820: Chunked store references in compiled code break grafting (again) Date: Mon, 19 Mar 2018 15:05:26 -0400 Message-ID: <87muz3dgy1.fsf@netris.org> References: <87o9jq7j7r.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ey07d-000143-Be for bug-guix@gnu.org; Mon, 19 Mar 2018 15:07:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ey07a-00078u-7E for bug-guix@gnu.org; Mon, 19 Mar 2018 15:07:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:34252) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ey07a-00078e-2i for bug-guix@gnu.org; Mon, 19 Mar 2018 15:07:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87o9jq7j7r.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 14 Mar 2018 16:47:04 +0100") 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 30820@debbugs.gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > The recently added glibc grafts triggered issues that, in the end, show > the return of (=E2=80=9CStore references in 8= -byte > chunks in compiled code=E2=80=9D). 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. Here's my preliminary proposal: (1) The reference scanner should recognize any 8-byte substring of a hash as a valid reference to that hash. (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. (3) The grafter should recognize and replace any 8-byte subsequence of the absolute store file name. 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'd be willing to work on implementing this soon. What do you think? Mark