* [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization
@ 2022-08-01 10:35 Florian Weimer
2022-08-01 13:42 ` Adhemerval Zanella Netto
2022-08-02 9:04 ` Using arc4random() in the library (was Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization) Yann Droneaud
0 siblings, 2 replies; 5+ messages in thread
From: Florian Weimer @ 2022-08-01 10:35 UTC (permalink / raw)
To: libc-alpha
Cancellation currently cannot happen at this point because dlopen
as used by the unwind link always performs additional allocations
for libgcc_s.so.1, even if it has been loaded already as a dependency
of the main executable. But it seems prudent not to rely on this
quirk.
---
malloc/malloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/malloc/malloc.c b/malloc/malloc.c
index bd3c76ed31..430d204156 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -254,6 +254,7 @@
/* For tcache double-free check. */
#include <random-bits.h>
#include <sys/random.h>
+#include <not-cancel.h>
/*
Debugging:
@@ -3153,7 +3154,7 @@ static uintptr_t tcache_key;
static void
tcache_key_initialize (void)
{
- if (__getrandom (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
+ if (__getrandom_nocancel (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
!= sizeof (tcache_key))
{
tcache_key = random_bits ();
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization
2022-08-01 10:35 [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization Florian Weimer
@ 2022-08-01 13:42 ` Adhemerval Zanella Netto
2022-08-02 9:04 ` Using arc4random() in the library (was Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization) Yann Droneaud
1 sibling, 0 replies; 5+ messages in thread
From: Adhemerval Zanella Netto @ 2022-08-01 13:42 UTC (permalink / raw)
To: Florian Weimer, libc-alpha
On 01/08/22 07:35, Florian Weimer via Libc-alpha wrote:
> Cancellation currently cannot happen at this point because dlopen
> as used by the unwind link always performs additional allocations
> for libgcc_s.so.1, even if it has been loaded already as a dependency
> of the main executable. But it seems prudent not to rely on this
> quirk.
>
LGTM, thanks.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> ---
> malloc/malloc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/malloc/malloc.c b/malloc/malloc.c
> index bd3c76ed31..430d204156 100644
> --- a/malloc/malloc.c
> +++ b/malloc/malloc.c
> @@ -254,6 +254,7 @@
> /* For tcache double-free check. */
> #include <random-bits.h>
> #include <sys/random.h>
> +#include <not-cancel.h>
>
> /*
> Debugging:
> @@ -3153,7 +3154,7 @@ static uintptr_t tcache_key;
> static void
> tcache_key_initialize (void)
> {
> - if (__getrandom (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
> + if (__getrandom_nocancel (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
> != sizeof (tcache_key))
> {
> tcache_key = random_bits ();
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Using arc4random() in the library (was Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization)
2022-08-01 10:35 [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization Florian Weimer
2022-08-01 13:42 ` Adhemerval Zanella Netto
@ 2022-08-02 9:04 ` Yann Droneaud
2022-08-02 9:44 ` Florian Weimer
1 sibling, 1 reply; 5+ messages in thread
From: Yann Droneaud @ 2022-08-02 9:04 UTC (permalink / raw)
To: libc-alpha
Hi,
Le 01/08/2022 à 12:35, Florian Weimer via Libc-alpha a écrit :
> Cancellation currently cannot happen at this point because dlopen
> as used by the unwind link always performs additional allocations
> for libgcc_s.so.1, even if it has been loaded already as a dependency
> of the main executable. But it seems prudent not to rely on this
> quirk.
>
> ---
> malloc/malloc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/malloc/malloc.c b/malloc/malloc.c
> index bd3c76ed31..430d204156 100644
> --- a/malloc/malloc.c
> +++ b/malloc/malloc.c
> @@ -254,6 +254,7 @@
> /* For tcache double-free check. */
> #include <random-bits.h>
> #include <sys/random.h>
> +#include <not-cancel.h>
>
> /*
> Debugging:
> @@ -3153,7 +3154,7 @@ static uintptr_t tcache_key;
> static void
> tcache_key_initialize (void)
> {
> - if (__getrandom (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
> + if (__getrandom_nocancel (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
Is this a place where arc4random() could be used in the future ?
aka. is there a policy on using arc4random() instead of getrandom() in
the library ?
--
Yann Droneaud
OPTEYA
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using arc4random() in the library (was Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization)
2022-08-02 9:04 ` Using arc4random() in the library (was Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization) Yann Droneaud
@ 2022-08-02 9:44 ` Florian Weimer
2022-08-03 13:50 ` Cristian Rodríguez
0 siblings, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2022-08-02 9:44 UTC (permalink / raw)
To: Yann Droneaud; +Cc: libc-alpha
* Yann Droneaud:
> Hi,
>
> Le 01/08/2022 à 12:35, Florian Weimer via Libc-alpha a écrit :
>> Cancellation currently cannot happen at this point because dlopen
>> as used by the unwind link always performs additional allocations
>> for libgcc_s.so.1, even if it has been loaded already as a dependency
>> of the main executable. But it seems prudent not to rely on this
>> quirk.
>>
>> ---
>> malloc/malloc.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/malloc/malloc.c b/malloc/malloc.c
>> index bd3c76ed31..430d204156 100644
>> --- a/malloc/malloc.c
>> +++ b/malloc/malloc.c
>> @@ -254,6 +254,7 @@
>> /* For tcache double-free check. */
>> #include <random-bits.h>
>> #include <sys/random.h>
>> +#include <not-cancel.h>
>> /*
>> Debugging:
>> @@ -3153,7 +3154,7 @@ static uintptr_t tcache_key;
>> static void
>> tcache_key_initialize (void)
>> {
>> - if (__getrandom (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
>> + if (__getrandom_nocancel (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
>
>
> Is this a place where arc4random() could be used in the future ?
>
> aka. is there a policy on using arc4random() instead of getrandom() in
> the library ?
Currently there is not much of a difference between arc4random_buf and
getrandom on current kernels. We'll see where getrandom is heading (and
if vDSO acceleration will end up in the kernel), and if it will involve
malloc in some way. If it does, we can't use arc4random from malloc, we
have to use the system call.
Thanks,
Florian
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using arc4random() in the library (was Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization)
2022-08-02 9:44 ` Florian Weimer
@ 2022-08-03 13:50 ` Cristian Rodríguez
0 siblings, 0 replies; 5+ messages in thread
From: Cristian Rodríguez @ 2022-08-03 13:50 UTC (permalink / raw)
To: Florian Weimer; +Cc: Yann Droneaud, libc-alpha
On Tue, Aug 2, 2022 at 5:44 AM Florian Weimer via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> Currently there is not much of a difference between arc4random_buf and
> getrandom on current kernels. We'll see where getrandom is heading (and
> if vDSO acceleration will end up in the kernel), and if it will involve
> malloc in some way.
The current experimental interface between vdso an userspace does not
involve malloc, state has to be allocated by calling
void *getrandom_alloc([inout] size_t *num, [out] size_t *size_per_each);
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-08-03 13:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-01 10:35 [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization Florian Weimer
2022-08-01 13:42 ` Adhemerval Zanella Netto
2022-08-02 9:04 ` Using arc4random() in the library (was Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization) Yann Droneaud
2022-08-02 9:44 ` Florian Weimer
2022-08-03 13:50 ` Cristian Rodríguez
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).