Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Checking your configfile (/etc/syslog-ng/syslog-ng... STUCK
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3546
Location: Illinois, USA

PostPosted: Fri Nov 08, 2019 3:19 pm    Post subject: Reply with quote

Quote:
config RANDOM_TRUST_CPU
bool "Trust the CPU manufacturer to initialize Linux's CRNG"
depends on X86 || S390 || PPC
default n
help
Assume that CPU manufacturer (e.g., Intel or AMD for RDSEED or
RDRAND, IBM for the S390 and Power PC architectures) is trustworthy
for the purposes of initializing Linux's CRNG. Since this is not
something that can be independently audited, this amounts to trusting
that CPU manufacturer (perhaps with the insistence or mandate
of a Nation State's intelligence or law enforcement agencies)
has not installed a hidden back door to compromise the CPU's
random number generation facilities.

Is this even an issue? I have it off, apparently by default. Maybe I'm naive, but why would I not trust AMD to not install spyware? It sounds very tin-foil hat to me.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14971

PostPosted: Sat Nov 09, 2019 1:13 am    Post subject: Reply with quote

As described in the quoted Kconfig text, there is no way to verify that the rdrand instruction is safe. Installing spyware on a system would be detectable by inspecting the system state with the right forensics tools. Building spyware into the CPU is considered infeasible, so it is considered a non-issue. rdrand occupies a special place of paranoia though. Suppose a malicious party sold a CPU that, rather than returning random numbers, returned the result of low-32-bits-of(aes256(secretkey, counter++)). For a well-chosen key, this output would appear random to anyone who did not know the derivation function (secretkey, aes256, any IV, and which bits of the result are returned to the application). However, it would be very predictable for anyone who knew the derivation function and guessed the current value of counter, which might not be hard if an application used rdrand in a way that most or all of its bits were observable. This would then allow the adversary to predict your random numbers in advance. Many cryptographic algorithms assume an unpredictable source of randomness is used. If your adversary predicts your random numbers, then the algorithm fails to provide the designed secrecy. I'm not aware of any evidence that there are commercially available CPUs with intentionally weakened derivation functions (given the recent resurfacing of the AMD chip that returns a steady string of -1 as its random numbers, I can't write "with unnecessarily weakened derivation functions", but that fault is so embarrassingly obvious that I can't believe it's an intentional weakness), but the problem is that if someone did make such a CPU, the number of people who would know about it could be kept quite small.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3546
Location: Illinois, USA

PostPosted: Sat Nov 09, 2019 3:27 am    Post subject: Reply with quote

Thank you for that detailed explanation, Hu.
Still, if it is required for syslog-ng to work properly, it seems to be the way to go. Or is it like urandom vs random, in that it depends on what one is doing?
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1741

PostPosted: Sat Nov 09, 2019 6:59 am    Post subject: Reply with quote

Quote:
Still, if it is required for syslog-ng to work properly, it seems to be the way to go. Or is it like urandom vs random, in that it depends on what one is doing?


It's not that syslog-ng needs this kernel setting to function, it is boiling completely down to random/urandom (the entropy) which could use it. I specifically stress the key word could, meaning it does not need to use it; and can work well without it. Alas, this issue ends up looking like another issue caused by when the kernel made urandom a blocking instruction and not providing an initial entropy seed. Now one thing to note, the kernel change on urandom was done in 2017 or earlier; while this trust option was later added in 2018...
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14971

PostPosted: Sat Nov 09, 2019 5:02 pm    Post subject: Reply with quote

My understanding was that /dev/urandom never fails to return data (that is its entire point), though it can return low-quality data if the good entropy has been drained. There is also a syscall getrandom, which pulls from urandom and defaults to blocking unless told otherwise. Many programs that don't need cryptographically strong random numbers nonetheless use the blocking mode, which causes problems when the kernel has insufficient entropy. The kernel developers' position is that programs that need good random numbers shouldn't be blocking on them during early boot, and programs that need random numbers, but not high quality ones, should be requesting non-blocking mode. For the latter, consider applications like mktemp: it needs a random source, but if it gets a weak random number, that's OK, because it will either work anyway (and the value doesn't need to be secret, just unique) or it will collide and mktemp can try again.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1741

PostPosted: Sat Nov 09, 2019 5:30 pm    Post subject: Reply with quote

I admit I wasn't completely correct on urandom in that it is blocking; however urandom interface will only return up to as much entropy as it has available (it is not a infinite source). So urandom may not return as much random bytes as requested to the point the entropy is depleted and it ends up giving a noticable delay. This is according to urandom's man page.

Quote:
Linux 3.17 and later provides the simpler and safer getrandom(2) interface which re‐
quires no special files; see the getrandom(2) manual page for details.

When read, the /dev/urandom device returns random bytes using a pseudorandom number
generator seeded from the entropy pool. Reads from this device do not block (i.e., the
CPU is not yielded), but can incur an appreciable delay when requesting large amounts
of data.

When read during early boot time, /dev/urandom may return data prior to the entropy
pool being initialized. If this is of concern in your application, use getrandom(2) or
/dev/random instead.

The /dev/random device is a legacy interface which dates back to a time where the cryp‐
tographic primitives used in the implementation of /dev/urandom were not widely
trusted. It will return random bytes only within the estimated number of bits of fresh
noise in the entropy pool, blocking if necessary. /dev/random is suitable for applica‐
tions that need high quality randomness, and can afford indeterminate delays.

When the entropy pool is empty, reads from /dev/random will block until additional en‐
vironmental noise is gathered. If open(2) is called for /dev/random with the O_NON‐
BLOCK flag, a subsequent read(2) will not block if the requested number of bytes is not
available. Instead, the available bytes are returned. If no byte is available,
read(2) will return -1 and errno will be set to EAGAIN.
Back to top
View user's profile Send private message
solamour
l33t
l33t


Joined: 21 Dec 2004
Posts: 645
Location: San Diego, CA

PostPosted: Tue Nov 12, 2019 12:34 am    Post subject: Reply with quote

I just had the same problem, and here is how my case was.

On one machine with an Intel i7 (not sure it has anything to do with the processor make/type, though), "CONFIG_RANDOM_TRUST_CPU=y" in kernel (Device Drivers -> Trust the CPU manufacturer to initialize Linux's CRNG) was all I needed.

But another machine with AMD Temash, the kernel config didn't work; if I disable "syslog_ng" from starting, then it gets stuck at "netmount", which (I think) is the next service in line. Disabling it, and now it gets stuck at "distccd", and so on.

What worked was adding rc_syslog_ng_need="haveged" in /etc/rc.conf, as @gr3m1in mentioned.

And then there is a very old, old machine with AMD Geode, which worked without the kernel config nor "haveged".
__
sol
Back to top
View user's profile Send private message
tgnb
Apprentice
Apprentice


Joined: 16 Apr 2002
Posts: 208
Location: New York, NY

PostPosted: Mon Dec 16, 2019 5:58 pm    Post subject: Reply with quote

Stolz wrote:
I was having the same issue. syslog-ng was frozen during boot waiting for entropy. I had to move the mouse or press keys to unfreeze it. In my case I didn't have to install Haveged, I just enabled one kernel option: CONFIG_RANDOM_TRUST_CPU=y


I owe you a beer for this as well. Thanks!
Back to top
View user's profile Send private message
agg3l
n00b
n00b


Joined: 19 Dec 2019
Posts: 1

PostPosted: Thu Dec 19, 2019 4:51 am    Post subject: Reply with quote

Stolz wrote:
I was having the same issue. syslog-ng was frozen during boot waiting for entropy. I had to move the mouse or press keys to unfreeze it. In my case I didn't have to install Haveged, I just enabled one kernel option: CONFIG_RANDOM_TRUST_CPU=y


Whoa, I've found the solution finally. Spent couple of days on this mess.
Surprising thing is, during migrating two close to similar Gentoo VMs from VirtualBox to KVM, having identical kernel config & startup services; both worked correctly before, one booted like a charm with qemu, while another got dead stuck on with this specific problem (and solution worked). Wish I know why... The only significant difference between two is vHDD partitioning and openSSL version (1.0 / 1.1). Latter went bad

Many thanks anyway :D
Back to top
View user's profile Send private message
pa4wdh
Guru
Guru


Joined: 16 Dec 2005
Posts: 352

PostPosted: Sat Jan 11, 2020 10:12 am    Post subject: Reply with quote

I just had the same problem, enabling the kernel option CONFIG_RANDOM_TRUST_CPU indeed fixed it.

As for the security implications:
I think the risk of using the (unverified) CPU RNG is quite low as it's only used to seed Linux' RNG. Before data is handed out via (u)random or the getrandom function (which syslog-ng uses) it is passed through sha1 together with other sources of randomness, and don't forget that later in the boot process the RNG is seeded with the seed saved at shutdown time.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

Free as in Freedom is not limited to software only:
Music: http://www.jamendo.com
Recipes: http://www.opensourcefood.com
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum