From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Florian Weimer <fweimer@redhat.com>,
Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH 22/28] elf: Add extension mechanism to ld.so.cache
Date: Tue, 3 Nov 2020 09:45:43 -0300 [thread overview]
Message-ID: <010f9832-5287-1004-8c73-a012b3b89c7f@linaro.org> (raw)
In-Reply-To: <87sg9vnbsf.fsf@oldenburg2.str.redhat.com>
On 30/10/2020 09:22, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
>
>>> +/* Print the extension information at the cache at start address
>>> + FILE_BASE, of ltength FILE_SIZE bytes. The new-format cache header
>>
>> s/ltength/length
>
> Fixed.
>
>>> + is at CACHE, and the file name for diagnostics is CACHE_NAME. */
>>> +static void
>>> +print_extensions (struct cache_extension_all_loaded *ext)
>>> +{
>>> + if (ext->sections[cache_extension_tag_generator].base != NULL)
>>> + {
>>> + fputs (_("Cache generated by: "), stdout);
>>> + fwrite (ext->sections[cache_extension_tag_generator].base, 1,
>>> + ext->sections[cache_extension_tag_generator].size, stdout);
>>> + putchar ('\n');
>>> + }
>>> +}
>>> +
>>
>> Ok. Will be the extension tag data always comprised of ascii printable
>> characters?
>
> For the generator extension: Yes. But not for other extensions.
> This code only deals with the generator extension.
>
>>> +/* Size of the cache extension directory. All tags are assumed to be
>>> + present. */
>>> +enum
>>> + {
>>> + cache_extension_size = (offsetof (struct cache_extension, sections)
>>> + + (cache_extension_count
>>> + * sizeof (struct cache_extension_section)))
>>> + };
>>> +
>>> +/* Write the cache extensions to FD. The extension directory is
>>> + assumed to be located at CACHE_EXTENSION_OFFSET. */
>>> +static void
>>> +write_extensions (int fd, uint32_t cache_extension_offset)
>>> +{
>>> + assert ((cache_extension_offset % 4) == 0);
>>
>> Maybe a proper error msg instead of an assert here?
>
> This is in the cache generator, so it's a code bug if the assert fires,
> not corrupted input.
Ack.
>
>>> @@ -435,6 +497,25 @@ save_cache (const char *cache_name)
>>> && idx_old < cache_entry_old_count)
>>> file_entries->libs[idx_old] = file_entries->libs[idx_old - 1];
>>>
>>> + /* Compute the location of the extension directory. This
>>> + implementation puts the directory after the string table. The
>>> + size computation matches the write calls below. The extension
>>> + directory does not exist with format 0, so the value does not
>>> + matter. */
>>> + uint32_t extension_offset = 0;
>>> + if (opt_format != 2)
>>> + extension_offset += file_entries_size;
>>> + if (opt_format != 0)
>>> + {
>>> + if (opt_format != 2)
>>> + extension_offset += pad;
>>> + extension_offset += file_entries_new_size;
>>> + }
>>
>> Ok, although I think we should be good move the 'opt_format' definition to
>> a proper enumeration.
>
> Can this wait? Something for a future patch?
Alright, although it does simplify reading this patchset and the
change should most mechanical.
>
>>> +static bool __attribute__ ((unused))
>>
>> Maybe use inline and let the compiler decide? Or the function is
>> really duplicate in a lot of places?
>
> The compiler already decides for static functions and will inline them
> if they are only used once. Given the size of the function, I think
> that's the appropriate approach here.
Ack.
>
>>> +cache_extension_load (const struct cache_file_new *cache,
>>> + const void *file_base, size_t file_size,
>>> + struct cache_extension_all_loaded *loaded)
>>> +{
>>> + memset (loaded, 0, sizeof (*loaded));
>>> + if (cache->extension_offset == 0)
>>> + /* No extensions present. This is not a format error. */
>>> + return true;
>>> + if ((cache->extension_offset % 4) != 0)
>>> + /* Extension offset is misaligned. */
>>> + return false;
>>> + size_t size_tmp;
>>> + if (__builtin_add_overflow (cache->extension_offset,
>>> + sizeof (struct cache_extension), &size_tmp)
>>> + || size_tmp > file_size)
>>> + /* Extension extends beyond the end of the file. */
>>> + return false;
>>> + const struct cache_extension *ext = file_base + cache->extension_offset;
>>
>> Maybe we should add an alignment check for 'file_base' as well (to
>> avoid unaligned struct member deference)?
>
> This pointer comes from mmap, so it's not something that can be wrong as
> the result of the file data. I could add an assert, but I don't think
> this is likely to go wrong.
Ack.
next prev parent reply other threads:[~2020-11-03 12:45 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 16:31 [PATCH 00/28] glibc-hwcaps support Florian Weimer
2020-10-01 16:31 ` [PATCH 01/28] elf: Do not search HWCAP subdirectories in statically linked binaries Florian Weimer
2020-10-01 18:22 ` Adhemerval Zanella
2020-10-01 18:24 ` Carlos O'Donell
2020-10-01 18:29 ` Adhemerval Zanella
2020-10-01 20:24 ` Carlos O'Donell
2020-10-01 16:31 ` [PATCH 02/28] elf: Implement __rtld_malloc_is_full Florian Weimer
2020-10-01 18:23 ` Adhemerval Zanella
2020-10-08 9:44 ` Florian Weimer
2020-10-01 16:31 ` [PATCH 03/28] elf: Implement _dl_write Florian Weimer
2020-10-05 19:46 ` Adhemerval Zanella
2020-10-01 16:31 ` [PATCH 04/28] elf: Extract command-line/environment variables state from rtld.c Florian Weimer
2020-10-06 20:45 ` Adhemerval Zanella
2020-10-08 11:32 ` Florian Weimer
2020-10-01 16:32 ` [PATCH 05/28] elf: Move ld.so error/help output to _dl_usage Florian Weimer
2020-10-06 21:06 ` Adhemerval Zanella
2020-10-08 12:19 ` Florian Weimer
2020-10-01 16:32 ` [PATCH 06/28] elf: Record whether paths come from LD_LIBRARY_PATH or --library-path Florian Weimer
2020-10-07 16:39 ` Adhemerval Zanella
2020-10-07 16:49 ` Florian Weimer
2020-10-01 16:32 ` [PATCH 07/28] elf: Implement ld.so --help Florian Weimer
2020-10-07 17:16 ` Adhemerval Zanella
2020-10-08 13:13 ` Florian Weimer
2020-10-01 16:32 ` [PATCH 08/28] elf: Implement ld.so --version Florian Weimer
2020-10-07 18:36 ` Adhemerval Zanella
2020-10-07 18:38 ` Adhemerval Zanella
2020-10-08 13:37 ` Florian Weimer
2020-10-01 16:32 ` [PATCH 09/28] scripts/update-copyrights: Update csu/version.c, elf/dl-usage.c Florian Weimer
2020-10-07 18:41 ` Adhemerval Zanella
2020-10-01 16:32 ` [PATCH 10/28] elf: Use the term "program interpreter" in the ld.so help message Florian Weimer
2020-10-07 21:08 ` Adhemerval Zanella
2020-10-08 14:08 ` Florian Weimer
2020-10-01 16:32 ` [PATCH 11/28] elf: Print the full name of the dynamic loader " Florian Weimer
2020-10-08 12:38 ` Adhemerval Zanella
2020-10-01 16:32 ` [PATCH 12/28] elf: Make __rtld_env_path_list and __rtld_search_dirs global variables Florian Weimer
2020-10-08 13:27 ` Adhemerval Zanella
2020-10-01 16:32 ` [PATCH 13/28] elf: Add library search path information to ld.so --help Florian Weimer
2020-10-08 16:22 ` Adhemerval Zanella
2020-10-01 16:33 ` [PATCH 14/28] elf: Enhance ld.so --help to print HWCAP subdirectories Florian Weimer
2020-10-08 16:27 ` Adhemerval Zanella
2020-10-09 8:18 ` Florian Weimer
2020-10-09 13:49 ` Matheus Castanho
2020-10-09 17:08 ` Florian Weimer
2020-10-09 17:12 ` Florian Weimer
2020-10-09 18:54 ` Matheus Castanho
2020-10-12 9:47 ` Florian Weimer
2020-10-01 16:33 ` [PATCH 15/28] elf: Do not pass GLRO(dl_platform), GLRO(dl_platformlen) to _dl_important_hwcaps Florian Weimer
2020-10-08 18:04 ` Adhemerval Zanella
2020-10-01 16:33 ` [PATCH 16/28] elf: Add glibc-hwcaps support for LD_LIBRARY_PATH Florian Weimer
2020-10-08 10:13 ` Szabolcs Nagy
2020-10-09 9:08 ` Florian Weimer
2020-10-09 10:50 ` Szabolcs Nagy
2020-10-09 10:55 ` Florian Weimer
2020-10-09 11:03 ` Szabolcs Nagy
2020-10-08 23:16 ` Paul A. Clarke
2020-10-09 8:56 ` Florian Weimer
2020-10-09 13:19 ` Adhemerval Zanella
2020-10-12 11:54 ` Florian Weimer
2020-10-01 16:33 ` [PATCH 17/28] x86_64: Add glibc-hwcaps support Florian Weimer
2020-10-01 16:33 ` [PATCH 18/28] powerpc64le: " Florian Weimer
2020-10-01 18:56 ` Paul A. Clarke
2020-10-05 9:47 ` Florian Weimer
2020-10-05 19:15 ` Paul A. Clarke
2020-10-06 12:20 ` Florian Weimer
2020-10-06 17:45 ` Paul A. Clarke
2020-10-09 9:06 ` Florian Weimer
2020-10-01 16:33 ` [PATCH 19/28] s390x: Add " Florian Weimer
2020-10-01 16:33 ` [PATCH 20/28] aarch64: " Florian Weimer
2020-10-14 13:46 ` Adhemerval Zanella
2020-10-14 14:08 ` Florian Weimer
2020-10-14 14:15 ` Adhemerval Zanella
2020-10-14 14:37 ` Szabolcs Nagy
2020-10-14 14:43 ` Adhemerval Zanella
2020-10-14 15:13 ` Florian Weimer
2020-10-14 14:44 ` Florian Weimer
2020-10-14 15:09 ` Szabolcs Nagy
2020-10-01 16:33 ` [PATCH 21/28] elf: Add endianness markup to ld.so.cache Florian Weimer
2020-10-14 14:07 ` Adhemerval Zanella
2020-10-01 16:33 ` [PATCH 22/28] elf: Add extension mechanism " Florian Weimer
2020-10-15 17:52 ` Adhemerval Zanella
2020-10-30 12:22 ` Florian Weimer
2020-11-03 12:45 ` Adhemerval Zanella [this message]
2020-11-03 15:30 ` Florian Weimer
2020-10-01 16:34 ` [PATCH 23/28] elf: Unify old and new format cache handling code in ld.so Florian Weimer
2020-10-16 14:37 ` Adhemerval Zanella
2020-10-30 13:22 ` Florian Weimer
2020-11-03 13:02 ` Adhemerval Zanella
2020-10-01 16:34 ` [PATCH 24/28] elf: Implement a string table for ldconfig, with tail merging Florian Weimer
2020-10-20 14:25 ` Adhemerval Zanella
2020-10-30 17:08 ` Florian Weimer
2020-11-03 13:05 ` Adhemerval Zanella
2020-11-03 15:29 ` Florian Weimer
2020-10-01 16:34 ` [PATCH 25/28] elf: Implement tail merging of strings in ldconfig Florian Weimer
2020-10-22 21:08 ` Adhemerval Zanella
2020-10-30 17:36 ` Florian Weimer
2020-10-01 16:34 ` [PATCH 26/28] elf: In ldconfig, extract the new_sub_entry function from search_dir Florian Weimer
2020-10-27 13:15 ` Adhemerval Zanella
2020-10-01 16:34 ` [PATCH 27/28] elf: Process glibc-hwcaps subdirectories in ldconfig Florian Weimer
2020-10-27 17:28 ` Adhemerval Zanella
2020-11-04 11:57 ` Florian Weimer
2020-10-01 16:34 ` [PATCH 28/28] elf: Add glibc-hwcaps subdirectory support to ld.so cache processing Florian Weimer
2020-10-01 16:50 ` [PATCH 00/28] glibc-hwcaps support H.J. Lu
2020-10-01 16:54 ` Florian Weimer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=010f9832-5287-1004-8c73-a012b3b89c7f@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.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.
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).