Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp6146511iog; Thu, 23 Jun 2022 12:18:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uSxVv9uA6P7woF7MMlR4ND1XJQOcm1A6pKpnsdjp98laCmq/m7dFHS58LX6trSkxDaQSB0 X-Received: by 2002:a17:902:f688:b0:16a:1dfe:9712 with SMTP id l8-20020a170902f68800b0016a1dfe9712mr23876677plg.112.1656011896631; Thu, 23 Jun 2022 12:18:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656011896; cv=none; d=google.com; s=arc-20160816; b=S9wktLhy0YZQRx3CGu7qDwq8IFg9hmpYupq1W0O8z06IMsniLgGD/VFDiYgV1ZDRIF tPF0A2xKDZ0QeMjx3N/KGYtOcmF8YDZ0qyRBRMSVsa88gebQFK9bkuIZwbihDdtxLPHu v7LBkEq4OxnROaSaajs4RgHdAgaqSi1v0bZnxm7SwxiwM6zZOdOxBNpDR958goXiQEXa Uq89cVLfsZCXXCrz3fBsqlopIR1geHh2EFOzv1rAbHPMVQmHSm1V7NLPZmgSKPqtpnmZ xbe8AtQwL5VEM1GMD1iszSfBomnL6q/+MPKfwSx8jwSKi0OGVERwyW1d++/YwtpUrHJg Ms4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=hOrOAOutYNQZjR6uOI7BzA2kZKfSGsICQeb4izYkM0U=; b=dWhUqnue/3BBRhTT/Ha9VF59RxVRWofxTNM1P++KqIvBk4cGGfvFAPDCGvjU3irjnx 3Mtfhv7NKuFXsSEbiyD3auJshvAyGsLaD2rQ0AFRpvS8iWfqnymp3RrHnyOuFiOJ6W4A 0x3hhQ8lcdXlrqIjNrqayEYaB22rnfxH6ND6j1wpSFiq5plZxWEADfXCWBf8vNDyj1rN /wWiSebDrUcRxu8AqOukMUkZ0NuQqeQJGvi6MugUblWH+dK5DFAYpcgY7O1CxjsXgMxB ZS6GwX1wMTJFtePzPA8jEgdttf4ikgA9z1CmO+Zg5TEERADob66+enTLQ9lfjsyfPxWL FTqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Oy4IEVPr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f5-20020a625105000000b0052527705946si37432pfb.47.2022.06.23.12.18.05; Thu, 23 Jun 2022 12:18:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=@linuxfoundation.org header.s=korg header.b=Oy4IEVPr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236543AbiFWSNr (ORCPT + 99 others); Thu, 23 Jun 2022 14:13:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236611AbiFWSMc (ORCPT ); Thu, 23 Jun 2022 14:12:32 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 969759BB70; Thu, 23 Jun 2022 10:20:51 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3137AB82480; Thu, 23 Jun 2022 17:20:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 951BFC3411B; Thu, 23 Jun 2022 17:20:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656004849; bh=V4/dyybGn3xUa1f3oO8fcXk2IMhWQqFvgIBWsKDBplk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Oy4IEVPrkrookxYFfDI1UoZDRKpdfEUcBgifDSAZ/3C8gXWTTtahYQRhJ+cla5UVz GkpJr9Nop/B9GT2/30CROTkuyhsZP8mFZMynYD+gVXH4/l+e9/wV5K2KCN6HfwSwAK lRQK4ch3XdWX+uHgUxSTG/FzwfSkp1NUe4g01BFU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jann Horn , Theodore Tso , "Jason A. Donenfeld" Subject: [PATCH 4.19 130/234] random: check for signals every PAGE_SIZE chunk of /dev/[u]random Date: Thu, 23 Jun 2022 18:43:17 +0200 Message-Id: <20220623164346.737961784@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220623164343.042598055@linuxfoundation.org> References: <20220623164343.042598055@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,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 lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Jason A. Donenfeld" commit e3c1c4fd9e6d14059ed93ebfe15e1c57793b1a05 upstream. In 1448769c9cdb ("random: check for signal_pending() outside of need_resched() check"), Jann pointed out that we previously were only checking the TIF_NOTIFY_SIGNAL and TIF_SIGPENDING flags if the process had TIF_NEED_RESCHED set, which meant in practice, super long reads to /dev/[u]random would delay signal handling by a long time. I tried this using the below program, and indeed I wasn't able to interrupt a /dev/urandom read until after several megabytes had been read. The bug he fixed has always been there, and so code that reads from /dev/urandom without checking the return value of read() has mostly worked for a long time, for most sizes, not just for <= 256. Maybe it makes sense to keep that code working. The reason it was so small prior, ignoring the fact that it didn't work anyway, was likely because /dev/random used to block, and that could happen for pretty large lengths of time while entropy was gathered. But now, it's just a chacha20 call, which is extremely fast and is just operating on pure data, without having to wait for some external event. In that sense, /dev/[u]random is a lot more like /dev/zero. Taking a page out of /dev/zero's read_zero() function, it always returns at least one chunk, and then checks for signals after each chunk. Chunk sizes there are of length PAGE_SIZE. Let's just copy the same thing for /dev/[u]random, and check for signals and cond_resched() for every PAGE_SIZE amount of data. This makes the behavior more consistent with expectations, and should mitigate the impact of Jann's fix for the age-old signal check bug. ---- test program ---- #include #include #include #include static unsigned char x[~0U]; static void handle(int) { } int main(int argc, char *argv[]) { pid_t pid = getpid(), child; signal(SIGUSR1, handle); if (!(child = fork())) { for (;;) kill(pid, SIGUSR1); } pause(); printf("interrupted after reading %zd bytes\n", getrandom(x, sizeof(x), 0)); kill(child, SIGTERM); return 0; } Cc: Jann Horn Cc: Theodore Ts'o Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman --- drivers/char/random.c | 41 ++++++++++++++++++++--------------------- 1 file changed, 20 insertions(+), 21 deletions(-) --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -523,9 +523,7 @@ EXPORT_SYMBOL(get_random_bytes); static ssize_t get_random_bytes_user(void __user *buf, size_t nbytes) { - bool large_request = nbytes > 256; - ssize_t ret = 0; - size_t len; + size_t len, left, ret = 0; u32 chacha_state[CHACHA20_BLOCK_SIZE / sizeof(u32)]; u8 output[CHACHA20_BLOCK_SIZE]; @@ -537,46 +535,47 @@ static ssize_t get_random_bytes_user(voi * bytes, in case userspace causes copy_to_user() below to sleep * forever, so that we still retain forward secrecy in that case. */ - crng_make_state(chacha_state, (u8 *)&chacha_state[4], CHACHA_KEY_SIZE); + crng_make_state(chacha_state, (u8 *)&chacha_state[4], CHACHA20_KEY_SIZE); /* * However, if we're doing a read of len <= 32, we don't need to * use chacha_state after, so we can simply return those bytes to * the user directly. */ - if (nbytes <= CHACHA_KEY_SIZE) { - ret = copy_to_user(buf, &chacha_state[4], nbytes) ? -EFAULT : nbytes; + if (nbytes <= CHACHA20_KEY_SIZE) { + ret = nbytes - copy_to_user(buf, &chacha_state[4], nbytes); goto out_zero_chacha; } - do { - if (large_request) { - if (signal_pending(current)) { - if (!ret) - ret = -ERESTARTSYS; - break; - } - cond_resched(); - } - + for (;;) { chacha20_block(chacha_state, output); if (unlikely(chacha_state[12] == 0)) ++chacha_state[13]; len = min_t(size_t, nbytes, CHACHA20_BLOCK_SIZE); - if (copy_to_user(buf, output, len)) { - ret = -EFAULT; + left = copy_to_user(buf, output, len); + if (left) { + ret += len - left; break; } - nbytes -= len; buf += len; ret += len; - } while (nbytes); + nbytes -= len; + if (!nbytes) + break; + + BUILD_BUG_ON(PAGE_SIZE % CHACHA20_BLOCK_SIZE != 0); + if (ret % PAGE_SIZE == 0) { + if (signal_pending(current)) + break; + cond_resched(); + } + } memzero_explicit(output, sizeof(output)); out_zero_chacha: memzero_explicit(chacha_state, sizeof(chacha_state)); - return ret; + return ret ? ret : -EFAULT; } /*