From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id C79993857BA8 for ; Tue, 28 Jun 2022 19:45:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C79993857BA8 Received: by mail-oi1-x22b.google.com with SMTP id r82so9933637oig.2 for ; Tue, 28 Jun 2022 12:45:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3zT3oARQU8AVHSapU9I148eDqWM7uBIhUELAUCc3B+A=; b=G9+5RqLIiFsw7z3xudXWRJt5eJequiaOU7RIRASygzIsIzFdln2AXc5w9vQHz8oZ+n CPG8FikXUbjpg2VPO5nY4D4tJyXTtwBdwC5iUIXzDOewOAbpW/UJ+rwfr02JhctJK7ht 0cJEbWEYj9m9wAnNeRJyMXEtAV7flOMeF1Lqpjglm9WabhSy3xcBMZF6afN9c+fisf1z UVMO5kXW+rOIJC9YRtojqihjLggUTMsTxjD5w2g3Kk7jsXSD3XwJBSRUg6yg0kFOHzzi UbLymH5QSS14g5Yo4RTC/hSq/0cycxAtaSmf8EyZmcZOPYRrGIivrNLPabYihyJ5PD/Q hvXg== X-Gm-Message-State: AJIora/3X5WMKYP+z/L5UNMh3in2QwJ6/8Efho9Gu3aUIJnKrzOrB5NJ 8yYhshz9R/ugvWoZ1JKMyKvdgsuawlDehAjf X-Google-Smtp-Source: AGRyM1u3NKkfEoZ9ke5Ge0i3hZ6HSSgZNN0JFcD87sDNw5V4a2kaRhd5MsK8WbtVphyVad3fTAfFqA== X-Received: by 2002:a05:6808:e82:b0:322:4c17:2f61 with SMTP id k2-20020a0568080e8200b003224c172f61mr837302oil.131.1656445520028; Tue, 28 Jun 2022 12:45:20 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7ca:6d95:25db:29b6:be9b:9202]) by smtp.gmail.com with ESMTPSA id a3-20020a544e03000000b0032efe5871b0sm7373859oiy.45.2022.06.28.12.45.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jun 2022 12:45:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: [PATCH v6 09/10] stdlib: Add TLS optimization to arc4random From: Adhemerval Zanella In-Reply-To: <878rphf0a3.fsf@oldenburg.str.redhat.com> Date: Tue, 28 Jun 2022 16:45:17 -0300 Cc: Adhemerval Zanella via Libc-alpha Content-Transfer-Encoding: quoted-printable Message-Id: <2CB410EE-045D-48CF-B521-F43C47BB5A38@linaro.org> References: <20220518191424.3630729-1-adhemerval.zanella@linaro.org> <20220518191424.3630729-10-adhemerval.zanella@linaro.org> <878rphf0a3.fsf@oldenburg.str.redhat.com> To: Florian Weimer X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2022 19:45:22 -0000 > On 28 Jun 2022, at 09:19, Florian Weimer wrote: >=20 > * Adhemerval Zanella via Libc-alpha: >=20 >> The arc4random state is moved to TCB, so there is no allocation >> failure. It adds about 592 bytes struct pthread. >>=20 >> Now that the state is thread private within a shared struct, the >> MADV_WIPEONFORK usage is removed. The cipher state reset is done >> solely by the atfork internal handler. >>=20 >> The state is also cleared on thread exit iff it was initialized (so = if >> arc4random is not called it is not touched). >>=20 >> Although it is lock-free, arc4random is still not async-signal-safe >> (the per thread state is not updated >>=20 >> On x86_64 using AVX2 it shows a slight better performance: >=20 > Should this be merged with the first patch? I only split it to make it easier to drop if the strategy would not be desirable, but I think make sense to merge. >=20 > Can we allocate the memory dynamically, and fall back to direct kernel > randomness based on allocation failure? >=20 > Those 512 bytes of TCB space could be better used for increasing the > static TLS reserve, I think. Alright, it should be feasible since it already has to handle getentropy failure on normal code path. >> diff --git a/sysdeps/unix/sysv/linux/tls-internal.c = b/sysdeps/unix/sysv/linux/tls-internal.c >> index 6e25b021ab..75bc4b3b48 100644 >> --- a/sysdeps/unix/sysv/linux/tls-internal.c >> +++ b/sysdeps/unix/sysv/linux/tls-internal.c >> @@ -1 +1,32 @@ >=20 >> +void >> +__glibc_tls_internal_free (void) >> +{ >> + struct pthread *self =3D THREAD_SELF; >> + free (self->tls_state.strsignal_buf); >> + free (self->tls_state.strerror_l_buf); >> + >> + if (self->tls_state.rnd_state.count !=3D -1) >> + /* Clear any lingering random state prior so if the thread stack is >> + cached it won't leak any data. */ >> + memset (&self->tls_state.rnd_state, 0, sizeof = self->tls_state.rnd_state); >> +} >=20 > I think this should be explicit_bzero (currently for documentation > purposes only). Indeed, it would be good to clear it even when it would be dynamically allocated. >=20 > Thanks, > Florian