From: Florian Weimer <fweimer@redhat.com>
To: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH 22/28] elf: Add extension mechanism to ld.so.cache
Date: Fri, 30 Oct 2020 13:22:40 +0100 [thread overview]
Message-ID: <87sg9vnbsf.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <ac1f1717-84af-7b9b-039d-ce70cd2d0f92@linaro.org> (Adhemerval Zanella via Libc-alpha's message of "Thu, 15 Oct 2020 14:52:25 -0300")
* 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.
>> @@ -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?
>> +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.
>> +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.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
next prev parent reply other threads:[~2020-10-30 12:22 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 [this message]
2020-11-03 12:45 ` Adhemerval Zanella
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=87sg9vnbsf.fsf@oldenburg2.str.redhat.com \
--to=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).