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.)
> kern.cryptodev_warn_interval=0
I'll try to get this tracked down this week, but this should be a
suitable workaround for now.
--
John Baldwin
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
