mike tancsa
2019-Aug-26 20:59 UTC
svn commit: r351246 - in stable: 11/sys/opencrypto 12/sys/opencrypto
On 8/22/2019 6:51 PM, John Baldwin wrote:> On 8/21/19 5:47 PM, Mike Tancsa wrote: >> On 8/21/2019 6:38 PM, John Baldwin wrote: >>> On 8/21/19 9:08 AM, mike tancsa wrote: >>>> On 8/21/2019 12:00 PM, John Baldwin wrote: >>>>> dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count()' >>>> Thanks, I am not familiar with dtrace at all. This command gives a >>>> syntax error >>>> >>>> 0(cage)# dtrace -n 'fbt::_gone_in:entry { >>>> @counts[curthread->td_proc->p_comm] = count()' >>>> dtrace: invalid probe specifier fbt::_gone_in:entry { >>>> @counts[curthread->td_proc->p_comm] = count(): syntax error near end of >>>> input >>>> 1(cage)# >>> Oops, I forgot the closing }. First, do "dtrace -l | grep _gone_in" to make >>> sure dtrace is loaded. You should see something like this: >>> >>> # dtrace -l | grep _gone_in >>> 87003 fbt kernel _gone_in entry >>> 87004 fbt kernel _gone_in return >>> 98682 fbt kernel _gone_in_dev entry >>> 98683 fbt kernel _gone_in_dev return >>> >>> Then this should work: >>> >>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count() }' >>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >>> >> Thanks! >> >> #? dtrace -l | grep _gone_in >> 15632??????? fbt??????????? kernel????????????????????????? _gone_in entry >> 22693??????? fbt??????????? kernel????????????????????? _gone_in_dev entry >> >> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] >> count() }' >> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >> >> However, It doesnt show anything after that even as I get the >> deprecation messages in dmesg > Can you hit Ctrl-C after seeing some of the messages? This trace won't > show any results until you exit dtrace.Hi, ??? I am still having problems tracking it down via dtrace, but I am able to create the problem on demand on sshd.? Whats odd is that if I restrict the list of ciphers in sshd and even specify something like aes-128 on the client, I still get warnings on the server. e.g from a client, % ssh -c aes128-cbc console1 uptime ?4:53PM? up? 1:02, 3 users, load averages: 0.04, 0.08, 0.08 The server shows Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): ARC4 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): 3DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): Blowfish cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): CAST128 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): ARC4 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): 3DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): Blowfish cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): CAST128 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): ARC4 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): 3DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): Blowfish cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): CAST128 cipher via /dev/crypto Despite having Ciphers??????? aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com in /etc/ssh/sshd_config Doing ssh -v from the client doesnt show any of the warning ciphers being used or proposed at all. Just wondering what the value of the warnings are if there is no way to really deal with them or even track down where the issues are ?? Rather than filling up the logs, would it be possible to have kern.cryptodev_warn_interval=0 to disable ? ??? ---Mike
John Baldwin
2019-Aug-27 00:25 UTC
svn commit: r351246 - in stable: 11/sys/opencrypto 12/sys/opencrypto
On 8/26/19 1:59 PM, mike tancsa wrote:> On 8/22/2019 6:51 PM, John Baldwin wrote: >> On 8/21/19 5:47 PM, Mike Tancsa wrote: >>> On 8/21/2019 6:38 PM, John Baldwin wrote: >>>> On 8/21/19 9:08 AM, mike tancsa wrote: >>>>> On 8/21/2019 12:00 PM, John Baldwin wrote: >>>>>> dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count()' >>>>> Thanks, I am not familiar with dtrace at all. This command gives a >>>>> syntax error >>>>> >>>>> 0(cage)# dtrace -n 'fbt::_gone_in:entry { >>>>> @counts[curthread->td_proc->p_comm] = count()' >>>>> dtrace: invalid probe specifier fbt::_gone_in:entry { >>>>> @counts[curthread->td_proc->p_comm] = count(): syntax error near end of >>>>> input >>>>> 1(cage)# >>>> Oops, I forgot the closing }. First, do "dtrace -l | grep _gone_in" to make >>>> sure dtrace is loaded. You should see something like this: >>>> >>>> # dtrace -l | grep _gone_in >>>> 87003 fbt kernel _gone_in entry >>>> 87004 fbt kernel _gone_in return >>>> 98682 fbt kernel _gone_in_dev entry >>>> 98683 fbt kernel _gone_in_dev return >>>> >>>> Then this should work: >>>> >>>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count() }' >>>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >>>> >>> Thanks! >>> >>> #? dtrace -l | grep _gone_in >>> 15632??????? fbt??????????? kernel????????????????????????? _gone_in entry >>> 22693??????? fbt??????????? kernel????????????????????? _gone_in_dev entry >>> >>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] >>> count() }' >>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >>> >>> However, It doesnt show anything after that even as I get the >>> deprecation messages in dmesg >> Can you hit Ctrl-C after seeing some of the messages? This trace won't >> show any results until you exit dtrace. > > Hi, > > ??? I am still having problems tracking it down via dtrace, but I am > able to create the problem on demand on sshd.? Whats odd is that if I > restrict the list of ciphers in sshd and even specify something like > aes-128 on the client, I still get warnings on the server. > > e.g from a client, > > % ssh -c aes128-cbc console1 uptime > ?4:53PM? up? 1:02, 3 users, load averages: 0.04, 0.08, 0.08 > > The server showsOk, I was able to reproduce this on an 11.x VM. It appears to only be something that the crypto engine in OpenSSL 1.0.x does (1.1.1 used in 12.0 and later has a rewritten /dev/crypto engine). I'll see if I can find a way to tone down the warning. Maybe if sshd is only creating sessions and not using them I can restrict it to warning the first time a session tries to perform an operation using a deprecated algorithm. (There are separate ioctls for creating a sessions vs doing actual crypto ops and the warning is in the session creation currently.)> kern.cryptodev_warn_interval=0I'll try to get this tracked down this week, but this should be a suitable workaround for now. -- John Baldwin