| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <202508251623.uUGghjhZ-lkp@intel.com>
Date: Mon, 25 Aug 2025 16:47:07 +0800
From: kernel test robot <lkp@...el.com>
To: Osama Abdelkader <osama.abdelkader@...il.com>, tytso@....edu,
Jason@...c4.com
Cc: oe-kbuild-all@...ts.linux.dev, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org,
Osama Abdelkader <osama.abdelkader@...il.com>
Subject: Re: [PATCH] drivers/char/random.c: Clean up style issues
Hi Osama,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.17-rc2]
[also build test WARNING on linus/master]
[cannot apply to crng-random/master next-20250822]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Osama-Abdelkader/drivers-char-random-c-Clean-up-style-issues/20250821-010651
base: v6.17-rc2
patch link: https://lore.kernel.org/r/20250820170359.78811-1-osama.abdelkader%40gmail.com
patch subject: [PATCH] drivers/char/random.c: Clean up style issues
config: sparc-randconfig-r071-20250825 (https://download.01.org/0day-ci/archive/20250825/202508251623.uUGghjhZ-lkp@intel.com/config)
compiler: sparc-linux-gcc (GCC) 8.5.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@...el.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202508251623.uUGghjhZ-lkp@intel.com/
smatch warnings:
drivers/char/random.c:325 crng_fast_key_erasure() warn: inconsistent indenting
drivers/char/random.c:349 crng_make_state() warn: inconsistent indenting
vim +325 drivers/char/random.c
304
305 /*
306 * This generates a ChaCha block using the provided key, and then
307 * immediately overwrites that key with half the block. It returns
308 * the resultant ChaCha state to the user, along with the second
309 * half of the block containing 32 bytes of random data that may
310 * be used; random_data_len may not be greater than 32.
311 *
312 * The returned ChaCha state contains within it a copy of the old
313 * key value, at index 4, so the state should always be zeroed out
314 * immediately after using in order to maintain forward secrecy.
315 * If the state cannot be erased in a timely manner, then it is
316 * safer to set the random_data parameter to &chacha_state->x[4]
317 * so that this function overwrites it before returning.
318 */
319 static void crng_fast_key_erasure(u8 key[CHACHA_KEY_SIZE],
320 struct chacha_state *chacha_state,
321 u8 *random_data, size_t random_data_len)
322 {
323 u8 first_block[CHACHA_BLOCK_SIZE];
324
> 325 WARN_ON_ONCE(random_data_len > 32);
326 if (random_data_len > 32)
327 return;
328 chacha_init_consts(chacha_state);
329 memcpy(&chacha_state->x[4], key, CHACHA_KEY_SIZE);
330 memset(&chacha_state->x[12], 0, sizeof(u32) * 4);
331 chacha20_block(chacha_state, first_block);
332
333 memcpy(key, first_block, CHACHA_KEY_SIZE);
334 memcpy(random_data, first_block + CHACHA_KEY_SIZE, random_data_len);
335 memzero_explicit(first_block, sizeof(first_block));
336 }
337
338 /*
339 * This function returns a ChaCha state that you may use for generating
340 * random data. It also returns up to 32 bytes on its own of random data
341 * that may be used; random_data_len may not be greater than 32.
342 */
343 static void crng_make_state(struct chacha_state *chacha_state,
344 u8 *random_data, size_t random_data_len)
345 {
346 unsigned long flags;
347 struct crng *crng;
348
> 349 WARN_ON_ONCE(random_data_len > 32);
350 if (random_data_len > 32)
351 return;
352 /*
353 * For the fast path, we check whether we're ready, unlocked first, and
354 * then re-check once locked later. In the case where we're really not
355 * ready, we do fast key erasure with the base_crng directly, extracting
356 * when crng_init is CRNG_EMPTY.
357 */
358 if (!crng_ready()) {
359 bool ready;
360
361 spin_lock_irqsave(&base_crng.lock, flags);
362 ready = crng_ready();
363 if (!ready) {
364 if (crng_init == CRNG_EMPTY)
365 extract_entropy(base_crng.key, sizeof(base_crng.key));
366 crng_fast_key_erasure(base_crng.key, chacha_state,
367 random_data, random_data_len);
368 }
369 spin_unlock_irqrestore(&base_crng.lock, flags);
370 if (!ready)
371 return;
372 }
373
374 local_lock_irqsave(&crngs.lock, flags);
375 crng = raw_cpu_ptr(&crngs);
376
377 /*
378 * If our per-cpu crng is older than the base_crng, then it means
379 * somebody reseeded the base_crng. In that case, we do fast key
380 * erasure on the base_crng, and use its output as the new key
381 * for our per-cpu crng. This brings us up to date with base_crng.
382 */
383 if (unlikely(crng->generation != READ_ONCE(base_crng.generation))) {
384 spin_lock(&base_crng.lock);
385 crng_fast_key_erasure(base_crng.key, chacha_state,
386 crng->key, sizeof(crng->key));
387 crng->generation = base_crng.generation;
388 spin_unlock(&base_crng.lock);
389 }
390
391 /*
392 * Finally, when we've made it this far, our per-cpu crng has an up
393 * to date key, and we can do fast key erasure with it to produce
394 * some random data and a ChaCha state for the caller. All other
395 * branches of this function are "unlikely", so most of the time we
396 * should wind up here immediately.
397 */
398 crng_fast_key_erasure(crng->key, chacha_state, random_data, random_data_len);
399 local_unlock_irqrestore(&crngs.lock, flags);
400 }
401
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Powered by blists - more mailing lists