From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B34E93831294 for ; Tue, 28 Jun 2022 12:19:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B34E93831294 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-83-0eldfqN_OJ2cP0WAdPKMUA-1; Tue, 28 Jun 2022 08:19:35 -0400 X-MC-Unique: 0eldfqN_OJ2cP0WAdPKMUA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F2CC9185A79C; Tue, 28 Jun 2022 12:19:34 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.0]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2912240CF916; Tue, 28 Jun 2022 12:19:33 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella via Libc-alpha Subject: Re: [PATCH v6 09/10] stdlib: Add TLS optimization to arc4random References: <20220518191424.3630729-1-adhemerval.zanella@linaro.org> <20220518191424.3630729-10-adhemerval.zanella@linaro.org> Date: Tue, 28 Jun 2022 14:19:32 +0200 In-Reply-To: <20220518191424.3630729-10-adhemerval.zanella@linaro.org> (Adhemerval Zanella via Libc-alpha's message of "Wed, 18 May 2022 16:14:23 -0300") Message-ID: <878rphf0a3.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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 12:19:39 -0000 * Adhemerval Zanella via Libc-alpha: > The arc4random state is moved to TCB, so there is no allocation > failure. It adds about 592 bytes struct pthread. > > 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. > > The state is also cleared on thread exit iff it was initialized (so if > arc4random is not called it is not touched). > > Although it is lock-free, arc4random is still not async-signal-safe > (the per thread state is not updated > > On x86_64 using AVX2 it shows a slight better performance: Should this be merged with the first patch? Can we allocate the memory dynamically, and fall back to direct kernel randomness based on allocation failure? Those 512 bytes of TCB space could be better used for increasing the static TLS reserve, I think. > 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 @@ > +void > +__glibc_tls_internal_free (void) > +{ > + struct pthread *self = THREAD_SELF; > + free (self->tls_state.strsignal_buf); > + free (self->tls_state.strerror_l_buf); > + > + if (self->tls_state.rnd_state.count != -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); > +} I think this should be explicit_bzero (currently for documentation purposes only). Thanks, Florian