From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Siddhesh Poyarekar <siddhesh@sourceware.org>, libc-alpha@sourceware.org
Subject: Re: [PATCH v3 11/19] elf: Do not duplicate the GLIBC_TUNABLES string
Date: Wed, 22 Nov 2023 10:03:47 -0300 [thread overview]
Message-ID: <2d25f3e5-6433-4c42-a4e1-eb80b973d21a@linaro.org> (raw)
In-Reply-To: <7692cb6a-0832-403c-b704-b4f143b21e12@sourceware.org>
On 22/11/23 09:23, Siddhesh Poyarekar wrote:
> On 2023-11-21 13:12, Adhemerval Zanella Netto wrote:
>>>> -tunable_initialize (tunable_t *cur, const char *strval)
>>>> +tunable_initialize (tunable_t *cur, const char *strval, size_t len)
>>>> {
>>>> - tunable_val_t val;
>>>> + tunable_val_t val = { 0 };
>>>> if (cur->type.type_code != TUNABLE_TYPE_STRING)
>>>> val.numval = (tunable_num_t) _dl_strtoul (strval, NULL);
>>>
>>> There's an implicit assumption that strval is NULL terminated for numeric values. Is that safe? Maybe all you need to do here is copy strval into a static buffer of size 21 (basically size of the string representing -1ULL) and pass that to _dl_strtoul.
>>
>> Afaiu the environment variable will always be NULL terminated (although some
>> might overlap). This is due how the kernel will layout the argv/envp on
>> process creation at sys_execve:
>
> Sure, but the strval here should not be the entire envvar, just the value portion of it. Granted that _dl_strtoul will bail out on the first non-numeric character, so maybe it's not
For the GLIBC_TUNABLES itself, parse_tunables will pass the correct length
for each tunable. For the alias case, get_next_env will pass the value
length (which I fixed on v4 btw). So I think there is no need to copy the
value on a temporary value, parsing can be done in-place since kernel ensures
the string will be null-terminated.
>
>>>> - if (disable)
>>>> + if (n.disable)
>>>> {
>>>> CHECK_GLIBC_IFUNC_CPU_OFF (n, cpu_features, POPCNT, 6);
>>>> CHECK_GLIBC_IFUNC_CPU_OFF (n, cpu_features, SSE4_1, 6);
>>>> CHECK_GLIBC_IFUNC_CPU_OFF (n, cpu_features, SSE4_2, 6);
>>>> - if (memcmp (n, "XSAVEC", 6) == 0)
>>>> + if (memcmp (n.str, "XSAVEC", 6) == 0)
>>>
>>> Why does this use the bare memcmp and not the tunables_strcmp?
>>
>> If I recall correctly, I did tried it and it resulted in worse codegen. The
>> tunable_str_comma_strcmp also checks the size, which on the x86 code is not
>> required and for some reason compiler can not eliminate.
>
> Why isn't it required? Couldn't n.str be smaller than 6 chars?
No because on the start of the loop the switch checks for 'n.len'.
next prev parent reply other threads:[~2023-11-22 13:03 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 20:25 [PATCH v3 00/19] Improve loader environment variable handling Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 01/19] elf: Remove /etc/suid-debug support Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 02/19] elf: Add GLIBC_TUNABLES to unsecvars Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 03/19] elf: Ignore GLIBC_TUNABLES for setuid/setgid binaries Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 04/19] elf: Add all malloc tunable to unsecvars Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 05/19] elf: Do not process invalid tunable format Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 06/19] elf: Do not parse ill-formatted strings Adhemerval Zanella
2023-11-20 21:48 ` Siddhesh Poyarekar
2023-11-06 20:25 ` [PATCH v3 07/19] elf: Fix _dl_debug_vdprintf to work before self-relocation Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 08/19] elf: Emit warning if tunable is ill-formatted Adhemerval Zanella
2023-11-20 21:50 ` Siddhesh Poyarekar
2023-11-06 20:25 ` [PATCH v3 09/19] x86: Use dl-symbol-redir-ifunc.h on cpu-tunables Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 10/19] s390: " Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 11/19] elf: Do not duplicate the GLIBC_TUNABLES string Adhemerval Zanella
2023-11-20 22:44 ` Siddhesh Poyarekar
2023-11-21 18:12 ` Adhemerval Zanella Netto
2023-11-22 11:39 ` Adhemerval Zanella Netto
2023-11-22 12:23 ` Siddhesh Poyarekar
2023-11-22 13:03 ` Adhemerval Zanella Netto [this message]
2023-11-22 13:24 ` Siddhesh Poyarekar
2023-11-22 14:13 ` Adhemerval Zanella Netto
2023-11-06 20:25 ` [PATCH v3 12/19] elf: Ignore LD_PROFILE for setuid binaries Adhemerval Zanella
2023-11-20 22:47 ` Siddhesh Poyarekar
2023-11-06 20:25 ` [PATCH v3 13/19] elf: Remove LD_PROFILE for static binaries Adhemerval Zanella
2023-11-20 22:55 ` Siddhesh Poyarekar
2023-11-06 20:25 ` [PATCH v3 14/19] elf: Ignore loader debug env vars for setuid Adhemerval Zanella
2023-11-20 22:57 ` Siddhesh Poyarekar
2023-11-21 18:24 ` Adhemerval Zanella Netto
2023-11-06 20:25 ` [PATCH v3 15/19] elf: Remove any_debug from dl_main_state Adhemerval Zanella
2023-11-20 22:58 ` Siddhesh Poyarekar
2023-11-06 20:25 ` [PATCH v3 16/19] elf: Ignore LD_LIBRARY_PATH and debug env var for setuid for static Adhemerval Zanella
2023-11-20 22:59 ` Siddhesh Poyarekar
2023-11-06 20:25 ` [PATCH v3 17/19] elf: Add comments on how LD_AUDIT and LD_PRELOAD handle __libc_enable_secure Adhemerval Zanella
2023-11-06 20:25 ` [PATCH v3 18/19] elf: Ignore LD_BIND_NOW and LD_BIND_NOT for setuid binaries Adhemerval Zanella
2023-11-20 23:02 ` Siddhesh Poyarekar
2023-11-06 20:25 ` [PATCH v3 19/19] elf: Refactor process_envvars Adhemerval Zanella
2023-11-20 23:09 ` Siddhesh Poyarekar
2023-11-21 19:00 ` Adhemerval Zanella Netto
2023-11-20 23:12 ` [PATCH v3 00/19] Improve loader environment variable handling Siddhesh Poyarekar
2023-11-21 19:37 ` Adhemerval Zanella Netto
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=2d25f3e5-6433-4c42-a4e1-eb80b973d21a@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=siddhesh@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).