Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp2581959imn; Tue, 2 Aug 2022 08:20:16 -0700 (PDT) X-Google-Smtp-Source: AGRyM1slh4Zpp3PO7Nw7IrBiFZlll67PoS0G9a1/1WYsZg7iW5ICTNgYGs5p3PDc8zuDFnR/p9V3 X-Received: by 2002:aa7:cd99:0:b0:43c:4f9c:4977 with SMTP id x25-20020aa7cd99000000b0043c4f9c4977mr21210139edv.303.1659453616328; Tue, 02 Aug 2022 08:20:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659453616; cv=none; d=google.com; s=arc-20160816; b=w2VX3tq7YltcmLsK3iAT46YAaJHoQ7zUTWRpAmerCIaLqKBYSQJd6Q/Zqja/T2vLX0 DYCPyh/8Puxlxy8ANZ58aEgT+ilN1C9EZE63x5/IIAwC5r5AZGNtlFtSLO9U56yfOQKD vVTwhwurir3gAoqjkdwCge8AlnLu4bFhxkCZU59HUxVvEdGkdJspOYxeJ/Pi+UPr1388 de7OP1EiD1kgrB0o2IJD0J8OXpmNv+2ZEbvSiSTxWcKPKz89GueX0it7GqJ4mEgcG0EI dHFYi6xi1EOEh+HpBN6TeoV2mYGzjG41qS4hZYnZCTvHwPE5SQuxaB+ylbb2aDm4h0dw YxIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=fS08hswxcKCvH2MW48Lg06ZhM4anuBSKvkfXm133UYc=; b=o0yCJ7RMliEILgKskAN7LRXKXb7vEWjFaz7TyvmnujlL4hGdt6S5U28FYHIXvx6QaM rRS7/2m9IGKZEX69g0bszz7VqdAPcLqA7mgR8W3m0eLAeirN7nbDj4gp1wgki5eXw5wU gnsdOZVpir3nrLI/W8SwApEzqVTOVTSDmALbUtKCQQB54wV2/Rkdlr2XTtAoF4CxypMr ImvwA4EJjZp0RVOm8Ekl4YTjy/O7rFtRdP7wEe2r0NaHdKGdpvX7FLIUFn50HmTomG80 H64/ARy34jf/SmkzlQ0EDyytGbPbvLMZ84lbih6V6fAafAilAd5Y0suuwKUTREOVKL52 yulg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=sfQdP4Tr; dkim=neutral (no key) header.i=@linutronix.de header.b=edQRKstJ; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gn8-20020a1709070d0800b0070fc7c9d71dsi15105078ejc.989.2022.08.02.08.19.42; Tue, 02 Aug 2022 08:20:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=sfQdP4Tr; dkim=neutral (no key) header.i=@linutronix.de header.b=edQRKstJ; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237476AbiHBPPp (ORCPT + 99 others); Tue, 2 Aug 2022 11:15:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237534AbiHBPPW (ORCPT ); Tue, 2 Aug 2022 11:15:22 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD7FF1A82F; Tue, 2 Aug 2022 08:15:00 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1659453298; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fS08hswxcKCvH2MW48Lg06ZhM4anuBSKvkfXm133UYc=; b=sfQdP4Tr5Ewrm9HBIgTeQ12Y/PhHlnjP1VJvn+ecexrguaK6TdjHh2u6ci6eCOeffHeOlY NNImo5tXkYFZoBJgTRMDNmd/Cf9UCwfmI7bzo4oEntcC5CelDq0Ej2hri3BZ0CJzn5XNII sf90vo7Wu/TlHiOuGYN0h/zvUVrvMILPc1Nt/S6VkAePgviLp2KWWIE7XdNpAs7/oflan6 Co2Lm8Pefr3Vcao7j+J5ptsLeuWCw+0CKfSK7LRP2WczUY2TFviFJ3heRI2rVjHZDI163I 7t1Rl8vQdix59NtocgBNjKqiVK5T0QR7EeYlCHjdSb/kYfy5vP4gDM+XrTM5eg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1659453298; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fS08hswxcKCvH2MW48Lg06ZhM4anuBSKvkfXm133UYc=; b=edQRKstJDks0wpeZ/5DFs7BY8Lq6Cq4fjT/7SUqBOey3xJuZPvRfq8iiK0SOt8UCS9W3fc W6fYQkrA0Ixz1wCA== To: "Jason A. Donenfeld" Cc: Linus Torvalds , linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, x86@kernel.org, Nadia Heninger , Thomas Ristenpart , Theodore Ts'o , Vincenzo Frascino , Adhemerval Zanella Netto , Florian Weimer Subject: Re: [PATCH RFC v1] random: implement getrandom() in vDSO In-Reply-To: References: <20220729145525.1729066-1-Jason@zx2c4.com> <87zggnsqwj.ffs@tglx> <87bkt2sqq4.ffs@tglx> Date: Tue, 02 Aug 2022 17:14:57 +0200 Message-ID: <878ro6smmm.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Aug 02 2022 at 15:59, Jason A. Donenfeld wrote: > On Tue, Aug 02, 2022 at 03:46:27PM +0200, Thomas Gleixner wrote: >> Right now the Linux VDSO functions are 1:1 replacements for system calls >> and not adding a magic pile of functionality which is otherwise not >> available. >> >> What you are proposing is to have an implementation which is not >> available via a regular syscall. Which means you are creating a VDSO >> only syscall which still has the same problem as any other syscall in >> terms of API design and functionality which needs to be supported >> forever. > > Wait, what? That's not correct. The WHOLE point is that vdso getrandom() > will generate bytes in the same way as the ordinary syscall, without > differences. Same function name, same algorithm. But just faster, > because vDSO. I explicitly don't want to dip into introducing something > different. That's the big selling point: that vDSO getrandom() and > syscall getrandom() are the same thing. If you trust one, you can trust > the other. If you expect properties of one, you get that from the other. > If you know the API of one, you can use the other. Seriously no. All existing VDSO functions have exactly the same function signature and semantics as their syscall counterparts. So they are drop in equivalent. But: ssize_t getrandom(void *, void *, size_t, unsigned int); is very much different than ssize_t getrandom(void *, size_t, unsigned int); Different signature and different semantics. So you have to go through the whole process of a new ABI whether you like it or not. It does not matter whether they both produce random numbers. If your argument would hold true, then you can also claim that openat(2) and openat2(2) are the same thing because they both open a file. Thanks, tglx