Remote (unbound-anchor) increase CPU after unbound 1.5.8

Fri Nov 25 16:16:38 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Luiz,

I have fixed that it uses less CPU.  It needs openssl 1.1, and sets
the security level to 0, and then uses no encryption (that means, even
less CPU than dh1024 was using) over the unix socket.  The changes are
committed to the code repository.

Best regards, Wouter

On 10/11/16 05:02, Luiz Fernando Softov via Unbound-users wrote:
>  Hi all.
> 
> I have a custom daemon  in C , that connect to unbound (remove
> control)  and get stats  , using stat_noreset.
> 
> Using this I can create real - time stats, in interface, like  
> http://prntscr.com/d5cecc 
> 
> So, a fter unbound 1.5.8 (eg: 1.5.9, 1.5.10) , using calls like
> unbound-control does, the use of CPU increase significantly.
> 
> And, it's increase de CPU of both daemons unbound and my daemon.
> 
> I was thinking this is because SSL. Because I was using 1.0.1,
> and unbound in ports (freebrs), force to install openssl 1.0.2.
> 
> But, s ince I'm in loopback (localhost), and,  I'm using
> 
>  control-use-cert: no 
> 
> I think this problem was introduced after the version i was using 
> before (1.5.3).
> 
> 
> After some research, reinstall openSSL  (this is hard, because i
> need to recompile a lot of daemons after this) ,  my daemon (of
> course), use another machine, etc.   I found  this :
> 
> -  [bugzilla: 770 ] - F ix Small subgroup attack on DH used in
> unix pipe on localhost if unbound   control uses a unix local
> named pipe.
> 
> So, i get the source of 1.5.10, and make some changes to do like
> before, in 1.5.8.
> 
> I put back in daemon/remote.c the get_dh1024()  function  ( 
> With some changes, if/else like in source of 1.5.10 ) .
> 
> Then, is work well, the cpu is 0%, with the daemon calling
> stat_noreset each second.
> 
> You can try this, calling unbound-anchor stats_noreset, more than
> you call, more the CPU get high.
> 
> This change , in  bugzilla 770 , is really necessary? 
> 
> 
> I also ready the last comment.
> 
> -  This is not a security issue.  The control socket is intended
> to be protected only by Unix file and directory permissions.  The
> only reason why the connection is encrypted is that there is no
> clean separation in the code and adding support for an unencrypted
> control connection would have required a huge amount of
> refactoring.
> 
> Since this is not a secure issue, and this can increase CPU without
> need.
> 
> The daemon and unbound are in the same machine, in a custom
> release, where the user can't have access, and can't do anything.
> 
> 
> Maybe a change in unbound, to get a new unbound.conf, to not use
> SSL at all (i know this is hard to be done) or make it to consume
> less CPU, alternates to use between 1024 or 2048. This is the first
> time I am reading unbound source, and I not know much about
> libssl.
> 
> But, in this case, i need a way to chose between security and
> performance.
> 
> ps, I also recommend to do a if before calling SSL_CTX_set_tmp_dh 
> , to check if get_dh is called right.
> 
> 
>    dh =  get_dh1024(); 
> 
>  if (dh == NULL) {
> 
>  log_crypto_err("Failed to get DH params");
> 
>  daemon_remote_delete(rc); return NULL;  }
> 
>  if(!SSL_CTX_set_tmp_dh(rc->ctx, dh)) {
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYOGPhAAoJEJ9vHC1+BF+NJ88P/3MKnqe0gOs9FLSNpiiHiLR9
Amyts5HNAHp5MuaRGISuuDMFtBTBzG7Hin0fIFYZpTpmHow03MwiE4VBVsQysDR2
nurBOoL2h7r0lwowh0oJxYLnOVdqHkJgSFmTxdeGV2tPctC0Tm8p49bQA1J0UOBM
BzfJpd+VbCMz1UR+OUCeEf5RdfNK6+ZG0bofLch1xqH2JyFRZWsY0e/ZfuCMBCj0
BZ0WMbv8gKr1rIpojUtt70gJCths6p8gRa0wmhpAaLf5WVln2KbfBaUvA3ZBIFE6
R21xUqMyZJFDtb6uLKR7oE0FU5p5UHBloCqCFgJsxcLrfpRVOnGCilzFuKww7p+K
TwE1aGQGjotdRy1SGFBqJx+zfMCvMMmTYG2lafwCILeJXxVwkzB9TL53t905j0+z
dpjlz79wAYQ6WoO7B8zBxh+qTWNHm436Lltdy2goehoVnwcKA6DcKNp/U+2KQCIm
JVaI0I7Bbb9fMEkVgORxpArDiDnQah0H/AEE2v7NRp87+J/68/mcRpSf2/lXtwPr
GWxNItQcx7BhPhm4N1n5xj5/HITjg5Kprq+RfQewfbi+tyoAR5oBjUu5cotagnfA
Yfv3+p0DO5Rrign9ZPQWKorGw3TuasPVi2/2QtsezuQFy4mCiTKed1t0z0TtXDjh
nN3X+k7f1YRy0Zs5Z0v4
=CZum
-----END PGP SIGNATURE-----