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

John Baldwin jhb at FreeBSD.org
Tue Aug 27 21:30:24 UTC 2019


On 8/26/19 5:25 PM, John Baldwin wrote:
> 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 shows
> 
> Ok, 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.)

I've committed a fix to head and will MFC it in a few days.  Thanks for tracking
this down!

-- 
John Baldwin


More information about the freebsd-stable mailing list