Re: Quite a lot of time spent in ssh_get_random

[Aris Adamantiadis <aris@xxxxxxxxxx>]

Hi Rich,

I'm a bit surprised that it's taking so much resource. It's probably 
because it's rehashing the whole entropy pool every time we read it. 
packet_send uses random input in the padding field. I'm not sure that 
simply using zeroes would be fine, but we certainly don't need very high 
quality random numbers.

Is your program running in FIPS mode? FIPS adds a few requirements on 
the prng, like using a certified (slow) DRBG.

Aris

Le 19/02/21 à 17:42, Richard W.M. Jones a écrit :
> I've been profiling our SSH plugin:
> https://gitlab.com/nbdkit/nbdkit/-/tree/master/plugins/ssh
> http://oirase.annexia.org/tmp/ssh_get_random.svg
>
> One observation is it seems to spend a lot of time in ssh_get_random;
> something like a third of the time in sftp_packet_write is spent
> there.  Is there anything we should know to make this faster?  I
> believe we are using the openssl (libcrypto) backend.
>
> The hardware is AMD Ryzen 9 3900X 12-Core Processor with these flags:
>
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall sev_es fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca
>
> Rich.