From: Jens Axboe <axboe@kernel.dk>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: tytso@mit.edu, hch@lst.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] random: convert to using fops->read_iter()
Date: Thu, 19 May 2022 17:21:32 -0600 [thread overview]
Message-ID: <8251e0d7-d506-16ea-7bc8-4c8bf098deea@kernel.dk> (raw)
In-Reply-To: <YobQt1Fbae0KtEFw@zx2c4.com>
On 5/19/22 5:20 PM, Jason A. Donenfeld wrote:
> On Fri, May 20, 2022 at 01:12:04AM +0200, Jason A. Donenfeld wrote:
>> Hi Jens,
>>
>> On Thu, May 19, 2022 at 01:31:32PM -0600, Jens Axboe wrote:
>>> for (;;) {
>>> chacha20_block(chacha_state, output);
>>> if (unlikely(chacha_state[12] == 0))
>>> ++chacha_state[13];
>>>
>>> block_len = min_t(size_t, len, CHACHA_BLOCK_SIZE);
>>> - left = copy_to_user(ubuf, output, block_len);
>>> - if (left) {
>>> - ret += block_len - left;
>>> + block_len = copy_to_iter(output, block_len, to);
>>> + if (!block_len)
>>> break;
>>> - }
>>>
>>> - ubuf += block_len;
>>> ret += block_len;
>>> len -= block_len;
>>> - if (!len)
>>> - break;
>>>
>>> BUILD_BUG_ON(PAGE_SIZE % CHACHA_BLOCK_SIZE != 0);
>>> if (ret % PAGE_SIZE == 0) {
>>> if (signal_pending(current))
>>> break;
>>> cond_resched();
>>> }
>>> }
>>
>> This isn't quite the same, is it? Before, it would immediately break out
>> of the loop on any short copy. Now, it will only break out on a zero
>> copy, which means it's possible that ret % PAGE_SIZE == 0, and there'll
>> be an unnecessary cond_resched() before copy_to_iter() runs again and
>> then breaks.
>
> Maybe something like the below would do the trick?
>
>
> static ssize_t get_random_bytes_user(struct iov_iter *to)
> {
> size_t block_len, copied, ret = 0, len = iov_iter_count(to);
> u32 chacha_state[CHACHA_STATE_WORDS];
> u8 output[CHACHA_BLOCK_SIZE];
>
> if (!len)
> return 0;
>
> /*
> * Immediately overwrite the ChaCha key at index 4 with random
> * 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);
> /*
> * 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 (len <= CHACHA_KEY_SIZE) {
> ret = copy_to_iter(&chacha_state[4], len, to);
> goto out_zero_chacha;
> }
>
> for (;;) {
> chacha20_block(chacha_state, output);
> if (unlikely(chacha_state[12] == 0))
> ++chacha_state[13];
>
> block_len = min_t(size_t, len, CHACHA_BLOCK_SIZE);
> copied = copy_to_iter(output, block_len, to);
> ret += copied;
> if (block_len != copied)
> break;
> len -= copied;
Yep, that looks good! Do you still want a v2?
--
Jens Axboe
next prev parent reply other threads:[~2022-05-19 23:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-19 19:31 [PATCHSET 0/2] Fix splice from random/urandom Jens Axboe
2022-05-19 19:31 ` [PATCH 1/2] random: convert to using fops->read_iter() Jens Axboe
2022-05-19 23:12 ` Jason A. Donenfeld
2022-05-19 23:20 ` Jason A. Donenfeld
2022-05-19 23:21 ` Jens Axboe [this message]
2022-05-19 23:21 ` Jason A. Donenfeld
2022-05-19 23:21 ` Jens Axboe
2022-05-19 19:31 ` [PATCH 2/2] random: wire up fops->splice_read_iter() Jens Axboe
2022-05-19 19:48 ` [PATCHSET 0/2] Fix splice from random/urandom Christoph Hellwig
2022-05-19 19:55 ` Jens Axboe
2022-05-20 6:02 ` Christoph Hellwig
2022-05-20 12:51 ` Jens Axboe
2022-05-19 20:05 ` Jason A. Donenfeld
2022-05-19 20:49 ` Jens Axboe
2022-05-19 21:02 ` Jens Axboe
2022-05-19 23:15 ` Jason A. Donenfeld
2022-05-19 23:22 ` Jens Axboe
2022-05-19 23:25 ` Jason A. Donenfeld
2022-05-19 23:33 ` Jens Axboe
2022-05-19 23:39 ` Jason A. Donenfeld
2022-05-19 23:44 ` Jens Axboe
2022-05-19 23:13 ` Jason A. Donenfeld
2022-05-19 23:19 ` Jens Axboe
2022-05-19 23:23 ` Jason A. Donenfeld
2022-05-19 23:25 ` Jens Axboe
2022-05-19 23:27 ` Jason A. Donenfeld
2022-05-19 23:57 ` Jens Axboe
2022-05-20 0:00 ` Jason A. Donenfeld
2022-05-20 0:02 ` Jens Axboe
2022-05-20 0:48 ` Jason A. Donenfeld
2022-05-20 0:56 ` Jens Axboe
2022-05-20 1:00 ` Jason A. Donenfeld
2022-05-20 1:05 ` Jens Axboe
2022-05-20 1:10 ` Jens Axboe
2022-05-20 12:43 ` Jason A. Donenfeld
2022-05-20 12:49 ` Jens Axboe
2022-05-20 13:04 ` Jason A. Donenfeld
-- strict thread matches above, loose matches on Subject: below --
2022-05-19 23:31 [PATCHSET v2 " Jens Axboe
2022-05-19 23:31 ` [PATCH 1/2] random: convert to using fops->read_iter() Jens Axboe
2022-05-20 3:11 ` Al Viro
2022-05-20 3:26 ` Jens Axboe
2022-05-20 9:14 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8251e0d7-d506-16ea-7bc8-4c8bf098deea@kernel.dk \
--to=axboe@kernel.dk \
--cc=Jason@zx2c4.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox