From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 098473858D33 for ; Mon, 25 Mar 2024 17:52:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 098473858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 098473858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::436 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711389180; cv=none; b=l0hpM3+Pwy+uXEFaavIdNowneoofteNXWIT8dj15G8OfkX6f0Aknbyvnxx7AVfKyUdac/KKGzBE+HwM8FYrO0WLZoE7cAoLoJ1uEVn6M6n70GxaYq67PpgBPy6ORZSA0tdSX0OqHPEATL3OfVzQsthHnYyVzAC4temzUcFrnP4s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711389180; c=relaxed/simple; bh=BGjIhQZcXsR23rF7NALQxyR9qCTtGA3CdlnxyULlieo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=X5L4jAf/8wXbb7t0ZM2OtdBbZPPnf9l2ATjfabqFW6Ff1bxyFNyF+ljSvZWawRTqa9KMAc7so1Vzo1gX9qf9svmFiZALvfOHED0/VV1la0QUP8Kyh8bRt6R7C7l9DQEHjrrlmiv1rIcmijce6lz44KLAg7kiCLYMR8caGWu6ilM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6e6082eab17so3508459b3a.1 for ; Mon, 25 Mar 2024 10:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1711389178; x=1711993978; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=iduAaWNmznZwNbEOndK8s/EBT0hAuoCcT/2BAYa2P6c=; b=GBoNQggvnEc9CoyXx1Te/s5ozU2uwr4AFI2zWA7j166JrTpGL6dMolknBicKNgjs8w 1HZZvWesonM29seAlah93YbpzaVhClz/yD8nqFEu6xEuTxzWiNo/5kk2wa7SJuw3webJ cJfSFFSd2tYwchcF0vfeFDMSvbNYdmcNbyZ+haAGTslyzQPatnije11wm1COSLnTOiT2 +Sm8l1xK/jsNib2W50Tf2y4XkdzS+1vgih+U0kQbuTh+0xeI4nC8KbMrFhGFGJgvXCV3 c/uv1eWfnKd7Eo4/azp9ejiNn688/t7vbwgejmHpqA2xi+VXypTTpVHNwaPMvdcEAHnH hNPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711389178; x=1711993978; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iduAaWNmznZwNbEOndK8s/EBT0hAuoCcT/2BAYa2P6c=; b=reLiaFDDZ/NtfsGEdTWyWxniLd0Dn/E8/9RlsJviua2eEKzZyoAilR2+bx/DynQe1W 38wd0QhiV0LY3qR6QxUT9kRPqZXNNH1amsCBnE60qCjVnqNpYW0SaCn9sRReNrVIl3Wv fpYrd6QYAKCVa8fYNW3fSoa7xVxx9DWTZS8btZ0TNlNytI4YWezKXWVVfd8ZBwtjBsji HbZdhyC4FEV/4CE9v8caQ/qx67MahH8ki8CL/V0oNDQrPMJnlO6uCpN+/NKQvuvQ5dQw w4qpKTVPLGCBIahQ7dLBpe1f3BOnPy9qHfgI70Kax5MxsWVDhTTRI3p2I/dAwhDJa78h GgJg== X-Forwarded-Encrypted: i=1; AJvYcCXmlkuWmK+ZgIgUMCorLD4s3v+pqrhT3UP0yGMK/j99GD90v2rDMvIy0KEg5ZJFWx4dfCBc4LEpShMaByDN4iyRBnJKpaevX7Cl X-Gm-Message-State: AOJu0YwNECCZkLmgacO6V1Z4mKc7CdUPPPpn0DOCsPrAY2jFtuZ8EZH8 rf4RYiHpUCsswBb6oMOQKOYaUEbwBO0SeI0cFYWVNOzE5rB+WTnlqi3yI32pbig= X-Google-Smtp-Source: AGHT+IHOvKt0haT9Spb2qLy+q9egN0HuNIcWNuNf6sy+UwMBPW6X/gvlSg8IZoFVrwHS9RYo0hx7ag== X-Received: by 2002:a05:6a20:6a08:b0:1a3:c8d5:707a with SMTP id p8-20020a056a206a0800b001a3c8d5707amr694478pzk.7.1711389177942; Mon, 25 Mar 2024 10:52:57 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:1d04:59b1:88e7:3675:b14? ([2804:1b3:a7c3:1d04:59b1:88e7:3675:b14]) by smtp.gmail.com with ESMTPSA id g16-20020aa79f10000000b006e669357e83sm4364028pfr.189.2024.03.25.10.52.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Mar 2024 10:52:57 -0700 (PDT) Message-ID: <77c0f38f-9124-4814-a8d7-0fc1dfb60dd0@linaro.org> Date: Mon, 25 Mar 2024 14:52:53 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] Add single-threaded fast path to rand() Content-Language: en-US To: Mathieu Desnoyers , Zack Weinberg , =?UTF-8?Q?Cristian_Rodr=C3=ADguez?= , Florian Weimer Cc: Wilco Dijkstra , GNU libc development , "Jason A. Donenfeld" References: <89b53f94-075f-4a34-99df-778271965de9@linaro.org> <878r2c11au.fsf@oldenburg.str.redhat.com> <40f9403d-5edc-47ae-8560-6549753ebf39@linaro.org> <17ac36a5-d5c0-4f71-8cf3-5eaf014194d6@linaro.org> <667f5ebb-13e5-4110-a002-3b2b0dfc2bdb@app.fastmail.com> <50b42519-4557-4e8c-8a58-0077168aa25d@linaro.org> <6a938fb2-30a5-4589-9b58-10828823df6f@efficios.com> <1ebd177e-8ad0-4bf1-84ea-40586bc3b00c@app.fastmail.com> <74a5680f-1f38-4c72-93ab-846ec1f795d3@efficios.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <74a5680f-1f38-4c72-93ab-846ec1f795d3@efficios.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 25/03/24 11:09, Mathieu Desnoyers wrote: > On 2024-03-23 11:23, Mathieu Desnoyers wrote: >> On 2024-03-23 10:01, Zack Weinberg wrote: >> >> [...] >> >>> ... >>>> If the goal is to let userspace know that it needs to reseed due to >>>> various kernel events happening, one way I see we could extend rseq >>>> to support this would be to add a 64-bit "seed generation counter" >>>> in the struct rseq per-thread area which would be incremented by the >>>> kernel when the seed needs to be updated in userspace. >>> >>> I don't know hardly anything about rseq.  I think that sounds workable >>> from libc's side of the fence; the remaining questions I see are >>> >>> 1) Will the kernel take your patch? >> >> I can start by creating a proof-of-concept patch. If there are >> use-cases justifying its integration, I don't see why the other >> rseq co-maintainers would object. > > Reading the follow-up discussion on the thread, I now understand > that a generation counter is probably not sufficient. Or maybe there > are more than one use-case here ? > > If the intended purpose is to have the kernel wipe out the keys > before going to sleep/hibernate, then you'll want an integration > similar to madvise MADV_WIPEONFORK, but with a new semantic that > also wipes on sleep/hibernate and other relevant events. I don't fully recall all the details, but I think that's was Jason idea with the getrandom vDSO strategy. It used a new syscall to allocate the state and this syscall used internally a new mmap flag to trigger the required wipe/reset on the required events. He also wanted to prevent userland to incorrectly use the syscall, so he moved the buffer allocation to vDSO as well. The vDSO implementation used the same cypher as the kernel one (chacha20, with a extra constraint to avoid leak internal state on the stack), and subdivides the state region in backets that were addressed based on thread pointer. Each bucket kept a generation counter, which was updated by the kernel. Any failure (either in generation check or contention on backets) fallback to getrandom syscall. > > If the intent is to make sure that random numbers get re-seeded > after those kernel events, then rseq with a generation counter > would work. > > Thanks,