From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 30820@debbugs.gnu.org
Subject: bug#30820: Chunked store references in compiled code break grafting (again)
Date: Mon, 19 Mar 2018 15:05:26 -0400 [thread overview]
Message-ID: <87muz3dgy1.fsf@netris.org> (raw)
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")
ludo@gnu.org (Ludovic Courtès) writes:
> The recently added glibc grafts triggered issues that, in the end, show
> the return of <http://bugs.gnu.org/24703> (“Store references in 8-byte
> chunks in compiled code”).
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
next prev parent reply other threads:[~2018-03-19 19:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-14 15:47 bug#30820: Chunked store references in compiled code break grafting (again) Ludovic Courtès
2018-03-14 17:24 ` Ludovic Courtès
2018-03-16 8:54 ` bug#30395: " Ludovic Courtès
2018-03-20 23:07 ` Ludovic Courtès
2018-03-21 6:39 ` Ricardo Wurmus
2018-03-21 20:59 ` Ludovic Courtès
2018-03-19 21:22 ` Danny Milosavljevic
2018-03-19 22:29 ` Ludovic Courtès
2018-03-19 19:05 ` Mark H Weaver [this message]
2018-03-19 19:16 ` Mark H Weaver
2018-03-19 21:34 ` Danny Milosavljevic
2018-03-19 22:27 ` Ludovic Courtès
2018-03-20 1:04 ` Mark H Weaver
2018-03-20 8:50 ` Ludovic Courtès
2018-03-19 22:34 ` Ludovic Courtès
2018-03-20 0:52 ` Mark H Weaver
2018-03-20 8:56 ` Ludovic Courtès
2018-03-21 4:17 ` Mark H Weaver
2018-03-21 5:43 ` Mark H Weaver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87muz3dgy1.fsf@netris.org \
--to=mhw@netris.org \
--cc=30820@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).