bug#24703: Store references in 8-byte chunks in compiled code

[ludo@gnu.org (Ludovic Courtès)]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>>> So, if our approach is to use -fno-builtin-strcpy, then we will have to
>>> apply it system-wide, and rebuild all of 'core-updates' from scratch.
>>
>> Another approach would be to patch GCC, specifically ‘expand_movstr’ in
>> gcc/builtins.c, which is the part responsible for this optimization,
>> along these lines (untested):
>>
>> --- gcc-5.3.0/gcc/builtins.c.orig	2016-10-18 10:45:35.042826368 +0200
>> +++ gcc-5.3.0/gcc/builtins.c	2016-10-18 10:50:46.080616285 +0200
>> @@ -3470,6 +3470,19 @@ expand_builtin_mempcpy_args (tree dest,
>>  # define CODE_FOR_movstr CODE_FOR_nothing
>>  #endif
>>  
>> +/* Return true if STR is a string denoting a "/gnu/store" file name.  */
>> +
>> +static bool
>> +store_reference_p (tree str)
>> +{
>> +  const char *store;
>> +
>> +  store = getenv ("NIX_STORE") ?: "/gnu/store";
>> +
>> +  return (TREE_STRING_LENGTH (str) > strlen (store)
>> +	  && strncmp (TREE_STRING_POINTER (str), store, strlen (store)));
>> +}
>
> [...]
>
>> WDYT?
>
> I think it's not sufficient to apply this workaround only for string
> literals that _begin_ with the store directory.  In some cases, the
> store name may appear only in the middle of a string.

Do you have examples?  I think this is unlikely: the common case here is
that we’re capturing the installation prefix as in:

  #define PREFIX "/gnu/store/…"
  strcpy (file, PREFIX);

>> In the meantime, we need a workaround.  The only option I can think of
>> is to retain a reference to the ungrafted item by adding a symlink to
>> it, like:
>
> I consider it a potentially serious security problem that ungrafted
> outputs are being used.  Papering over the problem by preventing this
> buggy software from being deleted is, in my opinion, not acceptable.

In practice, only data from the ungrafted input would be used, AFAICS.

I’m not saying that this is a good solution, I’m just trying to think of
solutions that we can deploy now while waiting for something better,
which may involve a full rebuild.

> The GCC approach is okay with me in the short term, but I'll likely want
> to revisit this issue in the future.

From your message, it’s unclear to me what you are proposing:

  1. as the short term solution;

  2. as the long term solution.

To me short-term is symlink and long-term is GCC patch.

Thanks for your feedback,
Ludo’.