From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id 26E9D3857347 for ; Thu, 14 Apr 2022 19:26:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26E9D3857347 Received: by mail-oi1-x230.google.com with SMTP id bj24so1005681oib.11 for ; Thu, 14 Apr 2022 12:26:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Uw38a7KhuEWLQa2Owan1iVk/m4hx9PLgESB6V1n6l4w=; b=evAhGmtrFhirCSGDRE2wp0/BNgSze4PQgaQyI16nEYS+ljF/VDJyzyvUDngFNmdo4Z WVx4VxgFs32lQr65+OwXg7gMUvL8ee6ddgowXMLv5Pe15Upn4UuuGZIpnpgChjBPvrbU 8G51j0WkvKnUvwDumU95BAbCUA9qHT8kf3eCiwPNDGOrtrhm+pkdDsA8m4Tb6RGj61p8 y3Pb+BrVekxn7pdgVvo3nuUTm7lMTdeVhtaYQna1PRHkzE9h/5OlbrLkoIMbE0EbLuwN 5bLDDZNZPEapF6RfFjCwUOTnu3h0/ZxMDzAKa3aAS8qsU3t3cDzRlZ4jkHEJslW+GCg3 8/7Q== X-Gm-Message-State: AOAM530oou2faplexCAftkqpFHnlx7qbZsLGZuiE1yqQi8IJFsjHFDUe XWjvx+8jSSPqNd/88TIdeqdEygOB3sk60g== X-Google-Smtp-Source: ABdhPJzaUISPbGsstDfPANLhoDCfF/Ii8zZEMzeozQ+9sVc8AlpP5XMUlvnp1M4W75/B+jIy36swMg== X-Received: by 2002:a05:6808:2183:b0:2da:6d62:6ec6 with SMTP id be3-20020a056808218300b002da6d626ec6mr56294oib.51.1649964399329; Thu, 14 Apr 2022 12:26:39 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:431f:3dc9:7133:8dac:5273? ([2804:431:c7ca:431f:3dc9:7133:8dac:5273]) by smtp.gmail.com with ESMTPSA id k14-20020a4a2a0e000000b0032ec90bf156sm358080oof.25.2022.04.14.12.26.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Apr 2022 12:26:38 -0700 (PDT) Message-ID: Date: Thu, 14 Apr 2022 16:26:36 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH 0/7] Add arc4random support Content-Language: en-US To: =?UTF-8?Q?Cristian_Rodr=c3=adguez?= Cc: libc-alpha@sourceware.org References: <20220413202401.408267-1-adhemerval.zanella@linaro.org> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 14 Apr 2022 19:26:42 -0000 On 14/04/2022 08:49, Cristian Rodríguez wrote: > If this interface is gonna added, GNU extensions that return uint64_t > of arc4random and arc4random_uniform will be extremely cool. > Even cooler if there is no global state. I don't think adding a uint64_t interface for arc4random would improve much, specially because a simple wrapper using arc4random_buf should be suffice. It would also require portable code to handle another GNU extension over a BSD defined interface that is presented in multiple systems. Also performance-wise I think it would be much different than arc4random_buf. It make some sense for arc4random_uniform, but I don't have a strong opinion. The global state adds some hardening by 'slicing up the stream' since multiple consumers getting different pieces add backtracking and prediction resistance. Theo de Raadt explains a bit why OpenBSD has added this concept [1] (check about minute 26) on its arc4random implementation. As he puts, there is no formal proof, but I agree that the ideas are reasonable. Also, not using a global state means we will need to add a per-thread or per-cpu state which is at least one page (due MADV_WIPEONFORK). The per-cpu state is only actually possible on newer Linux kernels that support rseq. We might just not care about MADV_WIPEONFORK and use a malloc buffer which would be reset by the atfork internal handler. [1] https://www.youtube.com/watch?v=gp_90-3R0pE