Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp14495032rwb; Mon, 28 Nov 2022 01:30:29 -0800 (PST) X-Google-Smtp-Source: AA0mqf7jM0pL5rktnUmi94QluCGQF1T/S9GMbdE6xVieBhXZOqVdyVmNwWwjAL4l+gMGt7BkvlzF X-Received: by 2002:a17:902:8d83:b0:189:6de9:975f with SMTP id v3-20020a1709028d8300b001896de9975fmr13057974plo.12.1669627829054; Mon, 28 Nov 2022 01:30:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669627829; cv=none; d=google.com; s=arc-20160816; b=gBEKVod9KoimMa5985VGZFzlc9i3L2G9e2GUFag2NuDZsrXKsMSpTa5EFN7DTCJhzn yuuyzPBX9wn3fVc+6UTZGiSGPrzkMVTUCoGiWnQ//D/dadYG18KMsh6pHWAOumYBA5Ic XJ196mSp29wJIHBBGtJe/aVTocamgjkPWCCPP7KoQbcqwW/wzNX7USxjxpINCzoYKgHl /lOontNfUgVfBUBHLKQv2vq2W66zwKmK61iYXhi67/UOxOevps8VYLQCc8JaqPI/i3yL DqOtY+PkjmkbZMtBufVMVEuehxQC6cxvGhDx/vktji/0vFrXQYOAjDJ7Be42Mg95UMYH BxXA== 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=hzfUYrqVvJQIGgcRMIOY/c4k5K9QDq4xHL6fNLFlt4I=; b=yiCviamDiIndBKFrYDWNifPrtPWw/l89AyjWbowRsF85LbPdH+PAxW0h1p3icYnjOw bytdlD3YdDB0uaRo7RnL8N2hZ2ygpEBroslGNVP2x2SJgKZeUYhTxf4f5b25+V8eaQry AXNLGC/wfSzIpZpIdG6nVJ22IwN0KkrEixorzoLKUlOfnhLv46TYZQA5wHr1F9Q0P9c1 ovX5bbEZedPD0kgw/draiDOFu1o8NrHOU5bCK3WVfE91RCiBcEN/HnsSH5PFBKGLu4uS CTdutDhg4GFzC7WSSxgDkPDoh0ZagLgQtr3Yu1e9LiILuN7GlNAWvv06nFC7rjHbNeM/ xveQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=vFlaGgqT; dkim=neutral (no key) header.i=@linutronix.de header.b=RWiPwXFc; 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 i35-20020a632223000000b004609faa2dbesi12631007pgi.285.2022.11.28.01.30.12; Mon, 28 Nov 2022 01:30:29 -0800 (PST) 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=vFlaGgqT; dkim=neutral (no key) header.i=@linutronix.de header.b=RWiPwXFc; 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 S229670AbiK1JZf (ORCPT + 99 others); Mon, 28 Nov 2022 04:25:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229568AbiK1JZf (ORCPT ); Mon, 28 Nov 2022 04:25:35 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9403CC59; Mon, 28 Nov 2022 01:25:33 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669627531; 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=hzfUYrqVvJQIGgcRMIOY/c4k5K9QDq4xHL6fNLFlt4I=; b=vFlaGgqTq4SSxWVW9zjseTZNcJEtNK9yLI0h/G4LglDwd2N7LUgKp1vKi4zjOtNPabn/zM eKu7ntMUxfC7KuniqlX5bvzSe9atRWpOh+jzQSIFnS18ilXmBsCK37x4Hb0joDTcDkIRhw VRJj8F5PdNFYvGpXdqmNlNl4Qs0ArIM/z+NAosC2y1X7hrBxf7NNAV6kpq6UBPic3M2SSJ PepAVY/z+EZrUrHQsnG5FGQf3jCyiMzsXFNALme5lGOIYz5pFUfrw+7Wr8BRnzpeH0AXD+ tDMpjg0fyL0EsmMlWc4O1IlutVVDVVZAezq9nFrfDyPC9AsSD3kQCmdGN2XnSg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669627531; 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=hzfUYrqVvJQIGgcRMIOY/c4k5K9QDq4xHL6fNLFlt4I=; b=RWiPwXFcsMegNyR14z4aHc9KTk+n4lRAcBTWyVvxOKEN4nJ5k0ru2sJBdWe73CW4gV8W15 t+Kl7rTGr0wWiUBQ== To: "Jason A. Donenfeld" Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev, linux-crypto@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, Greg Kroah-Hartman , Adhemerval Zanella Netto , Carlos O'Donell , Florian Weimer , Arnd Bergmann , Christian Brauner Subject: Re: [PATCH v7 2/3] random: introduce generic vDSO getrandom() implementation In-Reply-To: References: <20221124165536.1631325-1-Jason@zx2c4.com> <20221124165536.1631325-3-Jason@zx2c4.com> <877cziy7zg.ffs@tglx> Date: Mon, 28 Nov 2022 10:25:31 +0100 Message-ID: <87lenvwhv8.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 Jason! On Sun, Nov 27 2022 at 22:52, Jason A. Donenfeld wrote: > On Fri, Nov 25, 2022 at 11:39:15PM +0100, Thomas Gleixner wrote: >> If you really need anything from fs.h then please isolate it out into a >> separate header file which is included by fs.h and here. > > Hm. I need MAX_RW_COUNT from linux/fs.h. I could just hardcode `(INT_MAX > & PAGE_MASK)`, though, if you'd prefer, and leave a comment. I'll do > that. Or I could move MAX_RW_COUNT into linux/kernel.h? But maybe that's > undesirable. > > So: > > ssize_t ret = min_t(size_t, INT_MAX & PAGE_MASK /* = MAX_RW_COUNT */, len); > > I'll do that, if it's okay with you. Or tell me if you want me to > instead move MAX_RW_COUNT into linux/kernel.h. > > Also, if I remove linux/fs.h, I need to include linux/time.h in its > place, because vdso/datapage.h implicitly depends on it. Alternatively, > I could add linux/time.h to vdso/datapage.h, but I don't want to touch > too many files uninvited. Actually the minimal includes are those: --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -8,8 +8,9 @@ * 32 Bit compat layer by Stefani Seibold * sponsored by Rohde & Schwarz GmbH & Co. KG Munich/Germany */ -#include +#include #include +#include #include #include "../../../../lib/vdso/gettimeofday.c" >> > + batch_len = min_t(size_t, sizeof(state->batch) - state->pos, len); >> >> Where is the sanity check for state->pos <= sizeof(state->batch)? > > That condition cannot happen. "Does the compiler or some other checker > prove that as part of the development cycle?" No, unfortunately. So what > would you like to do here? Per Linus' email on an unrelated topic [1], > "We don't test for things that can't happen." And there's no > WARN_ON/BUG_ON primitive that'd be wise to use here -- nobody wants to > emit a ud2 into vDSO code I assume. So what would you like? For me to > add that check and bail out of the function if it's wrong, even if that > should normally never happen? Or adhere to the [1] more strictly and do > nothing, as is the case now? I'll do what you want here. I think we can do without any further checks. If the callsite fiddles with state then the resulting memcpy will go into lala land and the process can keep the pieces. Thanks, tglx