From owner-freebsd-stable@freebsd.org Tue Aug 27 00:25:30 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2AD19C12F9 for ; Tue, 27 Aug 2019 00:25:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HV5Q0JHsz4582; Tue, 27 Aug 2019 00:25:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 8642D1F85F; Tue, 27 Aug 2019 00:25:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r351246 - in stable: 11/sys/opencrypto 12/sys/opencrypto To: mike tancsa , freebsd-stable@freebsd.org References: <201908200130.x7K1UajV079446@repo.freebsd.org> <3101bd14-316a-baaa-6269-297903c45f23@FreeBSD.org> <39c6d016-fecb-306e-32f2-7fdabad32122@sentex.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <75b07433-91a2-0dbd-0dc2-0880e20df659@FreeBSD.org> Date: Mon, 26 Aug 2019 17:25:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <39c6d016-fecb-306e-32f2-7fdabad32122@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 00:25:30 -0000 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