svn commit: r351246 - in stable: 11/sys/opencrypto 12/sys/opencrypto

[mike tancsa]

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