Broken RDRAND causes infinite looping

[Xyene]

Some CPUs, like the Ryzen 3600X, report having RDRAND in cpuid, but actually executing RDRAND returns an endless stream of 0xFFFFFFFF. This causes json-c to lock up retrying RDRAND, but never trying another source of entropy.

json-c/linkhash.c

Lines 467 to 469 in 31f1ab2

	/* we can't use -1 as it is the unitialized sentinel */
	while ((seed = json_c_get_random_seed()) == -1) {}
	#if SIZEOF_INT == 8 && defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8

A number of Arch Linux users reported issues with this in swaywm/sway#5290, where json-c was recently upgraded from 0.13 to 0.14. There, this problem manifested as the window manager entirely locking up during JSON IPC.

The kernel supports a nordrand flag, but that has no effect on the availability of RDRAND signaled by cpuid. The workaround here is to update BIOS to a version that fixes this issue, but considering the number of reports in that project alone, it might be worthwhile to include fallback logic in json-c itself, and use a different random source if RDRAND fails too many times. I'm happy to submit such a patch, if desired.

[hawicz]

oof, yeah, a patch to disable the use of RDRAND would be quite welcome. Perhaps check, in random_seed.c, for Ryzen CPUs, and if so, check whether the first dozen or so calls to RDRAND all return 0xFFFFFFFF, and don't use it in that case?

[hawicz]

Oh, just noticed you have a PR #589 open. I'm closing this ticket in favor of that one.