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.
