From owner-freebsd-current@freebsd.org Mon Oct 16 10:34:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA6C2E35C6E for ; Mon, 16 Oct 2017 10:34:59 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3D247646B for ; Mon, 16 Oct 2017 10:34:59 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id f20so15558045ioj.9 for ; Mon, 16 Oct 2017 03:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BwV9beMn8GDsyO1fZvH1fEVM6qRgIbEFtMnmHVrs0Gk=; b=Jq8r6P9odG6jtvDWr7oMdMxstZoOxJax9t5qmyKc7bSMgBrQq58bG4qBxzanHbFN+C sB9lpOvePEa/s3E5eYHy9PDEFrqfRNN2eHuY73uJNne1LHfi2/TqBqiWAPB0SrJBdjgH Dk/MjGd/aUMRKtU5omU7lOHgkiRimoJVRL59q6KDZfz0shrQc4VuQfEkh4OmyjFC6lQu L1687+J+lgkyI+XyBmgz39YE+J9KKbDumxt3ImLKkeif+PehjVU1LdxsL/o6qti5G74h WyE7HJKDUZvxwuxrIpIGddJ5MqhdLejOIH0fjunNdw49HRztp6woUajaxCbUf3owivQk onKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BwV9beMn8GDsyO1fZvH1fEVM6qRgIbEFtMnmHVrs0Gk=; b=sDQDyRYAkrk1tQCqs/AK2eT0xaCsRdJpgwjZCvJg02JhcjlNNFjTeE8peZBVyA50vW fzWfJBVrRtC/97Xn5kZ9p3nE8pk1Lybozk5YzQSto9wm2yrLo1ciwoVgCtogb4aQFQ3l 3Uk7lKBlbqDF7Iz8BJdWzAJQC7ekXPPQWAi7w2mNbFioXfLsDf1k4/C3UvNlu2q6r4Vr UB/Jpq4AyxzLNiWp2NN7sjJx8AyK6NafKxwPuMfaoR79XBf9wzF1/AuBqJmX59WXQx+E YikeXm6/XXcBP0voiX2XiVu6q7F9LZZk7Z7G1jjDeMRS/0o4T7MYmz6viPazPOp3b7So EnbQ== X-Gm-Message-State: AMCzsaWbO/70M97eEhDrQluZTxbd9AD7t+0YI5NjUTMOgGgQuk4fa5g9 YwiBydsaznOEj9k7+SYJqjMYc6nPCuEmBqBPsmRH/A== X-Google-Smtp-Source: AOwi7QAnyJh1d7aCN2ZDXm69PkSKFejtASd4RC6GWdWl2C7ChYFeWXH6WpqaoKRoqmSeaqqiVXYW7TP0SwZS5jQrqbA= X-Received: by 10.107.114.5 with SMTP id n5mr12744935ioc.291.1508150098808; Mon, 16 Oct 2017 03:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.66 with HTTP; Mon, 16 Oct 2017 03:34:58 -0700 (PDT) From: blubee blubeeme Date: Mon, 16 Oct 2017 18:34:58 +0800 Message-ID: Subject: cve-2017-13077 - WPA2 security vulni To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 10:35:00 -0000 Does anyone on FreeBSD know if it's affected by this? https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077 From owner-freebsd-current@freebsd.org Mon Oct 16 10:36:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11833E35D7E for ; Mon, 16 Oct 2017 10:36:09 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CDF16765C2 for ; Mon, 16 Oct 2017 10:36:08 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 32F3027347; Mon, 16 Oct 2017 10:36:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9GAZjRf002231; Mon, 16 Oct 2017 10:35:45 GMT (envelope-from phk@phk.freebsd.dk) To: blubee blubeeme cc: FreeBSD current Subject: Re: cve-2017-13077 - WPA2 security vulni In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2229.1508150145.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Oct 2017 10:35:45 +0000 Message-ID: <2230.1508150145@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 10:36:09 -0000 -------- In message , blubee blubeeme writes: >Does anyone on FreeBSD know if it's affected by this? >https://cve.mitre.org/cgi-bin/cvename.cgi?name=3D2017-13077 It is, same as Linux, we use the same wpa_supplicant software -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Mon Oct 16 10:38:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9ED15E35F36 for ; Mon, 16 Oct 2017 10:38:31 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65D1D7675B for ; Mon, 16 Oct 2017 10:38:31 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x230.google.com with SMTP id n195so593815itg.2 for ; Mon, 16 Oct 2017 03:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3qvVP+Vsp20QDmodiALYSVv88QPcR3lGmxderoZ01fg=; b=DRxgrSKnlon3Vq18rqPMyzP+TsqrlLcOivfXMZEVZW+Gf0aqt7RDjgyv/PqKnp0ba6 rLnrbAztQ26GHfzgeNRxmNsGydjsfYRWvpOt7PVkKMvq2CQDrNzlef7vBn98qe97+45o focJ5DtbBEMW/7QReAdqjhymSu7PpfVz1Yzp8AJyKc4UaRYpkejqvEQCjIsrwQ4o4m8X 0CGcc/tKTlFVFJ2xvc28feVshBqwdUivBVN2WR6HoQ1B5YNikd1SZK4bcftJRsb6YRTu M7zWabO9S1XXe6dSB0ESLJcKfe5IQpQ9dahweEjRHArRCZQ5KVDLMuR+0TAFC+gN00Pz I+rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3qvVP+Vsp20QDmodiALYSVv88QPcR3lGmxderoZ01fg=; b=BiHlHNn9VSrfF8DcD8fgni4fr2uiY8MVgl8SFjVFPxPjSvEt6MCsJWwP0nRgNVWygq mJKeYlL5zBGfjvJ4D4p9z7TzsgcDkDWN1IvYDetaKDv/4gbS3oweOJoo/9rlZYR5NULo 94MEoASL8szjfpeQCsUDSVmIgmUDQekjAPf41ZpvGe7bSmTMQzlHewibTMzAAnecBF/G PPAmFo2S9+fmymH6m8g+n/RuklFVgRyy4GuN8x2ml8OF1Iyk2bsdJPs5QccpB8Bi/v0W ptxsrm09IsIlPRvBepr8w05rZPJpjIxjjRj1EQ76T63jwU+oXKwBgkNxHcityPmm+Rek cA1A== X-Gm-Message-State: AMCzsaXxMqjJzViVWDQeV5V1gtwXlpOaJKnadOuu2/H/nLNR7MOjv5m1 trN8q7LxnPiXZMTfBDDTWvXDr60pyjbh0K0ykU8= X-Google-Smtp-Source: ABhQp+RdO6tyX1dkRmHcm+RmmOuzIe5gMJXEnucIT5z+H/V3VWgzpJSSllQsi6wSIxudbj+wUcOKA7E1j45c4E3PfPQ= X-Received: by 10.36.139.130 with SMTP id g124mr560130ite.100.1508150310732; Mon, 16 Oct 2017 03:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.66 with HTTP; Mon, 16 Oct 2017 03:38:30 -0700 (PDT) In-Reply-To: <2230.1508150145@critter.freebsd.dk> References: <2230.1508150145@critter.freebsd.dk> From: blubee blubeeme Date: Mon, 16 Oct 2017 18:38:30 +0800 Message-ID: Subject: Re: cve-2017-13077 - WPA2 security vulni To: Poul-Henning Kamp Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 10:38:31 -0000 well, that's a cluster if I ever seen one. On Mon, Oct 16, 2017 at 6:35 PM, Poul-Henning Kamp wrote: > -------- > In message gmail.com> > , blubee blubeeme writes: > > >Does anyone on FreeBSD know if it's affected by this? > >https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077 > > It is, same as Linux, we use the same wpa_supplicant software > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > From owner-freebsd-current@freebsd.org Mon Oct 16 11:19:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C89DAE36DF9 for ; Mon, 16 Oct 2017 11:19:24 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout09.t-online.de (mailout09.t-online.de [194.25.134.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85B567790B for ; Mon, 16 Oct 2017 11:19:24 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd39.aul.t-online.de (fwd39.aul.t-online.de [172.20.27.138]) by mailout09.t-online.de (Postfix) with SMTP id 90B194243480 for ; Mon, 16 Oct 2017 13:19:16 +0200 (CEST) Received: from Stefans-MBP-2.fritz.box (Xpuij-ZlZhigU0fK9kIgUimCOtRL-pulDnPzKxM7WCk+JEpYfG+04KCdKu60k2HQMa@[87.151.210.245]) by fwd39.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1e43QS-3AUGh60; Mon, 16 Oct 2017 13:19:16 +0200 Subject: Re: cve-2017-13077 - WPA2 security vulni To: freebsd-current@freebsd.org References: <2230.1508150145@critter.freebsd.dk> From: Stefan Esser Message-ID: <21896d6e-75be-3376-bc32-9d911227de5c@freebsd.org> Date: Mon, 16 Oct 2017 13:19:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------FDEAD5A07F7807785CA9C662" Content-Language: de-DE X-ID: Xpuij-ZlZhigU0fK9kIgUimCOtRL-pulDnPzKxM7WCk+JEpYfG+04KCdKu60k2HQMa X-TOI-MSGID: 20c05c16-1fd0-4e0f-ac22-6b4d608e1be7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 11:19:24 -0000 This is a multi-part message in MIME format. --------------FDEAD5A07F7807785CA9C662 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Am 16.10.17 um 12:38 schrieb blubee blubeeme: > well, that's a cluster if I ever seen one. > > On Mon, Oct 16, 2017 at 6:35 PM, Poul-Henning Kamp > wrote: > >> -------- >> In message > gmail.com> >> , blubee blubeeme writes: >> >>> Does anyone on FreeBSD know if it's affected by this? >>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077 >> >> It is, same as Linux, we use the same wpa_supplicant software The attached patch includes the official patch applied by the WPA developers in https://w1.fi/cgit/hostap/commit/?id=a00e946 but for our version of wpa_supplicant in /usr/src/contrib. Regards, STefan --------------FDEAD5A07F7807785CA9C662 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="wpa.c-CVE-2017-13077.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="wpa.c-CVE-2017-13077.patch" Index: contrib/wpa/src/rsn_supp/wpa.c =================================================================== --- contrib/wpa/src/rsn_supp/wpa.c (Revision 324638) +++ contrib/wpa/src/rsn_supp/wpa.c (Arbeitskopie) @@ -1534,6 +1534,14 @@ sm->ptk_set = 1; os_memcpy(&sm->ptk, &sm->tptk, sizeof(sm->ptk)); os_memset(&sm->tptk, 0, sizeof(sm->tptk)); + /* + * This assures the same TPTK in sm->tptk can never be + * copied twice to sm->pkt as the new PTK. In + * combination with the installed flag in the wpa_ptk + * struct, this assures the same PTK is only installed + * once. + */ + sm->renew_snonce = 1; } } --------------FDEAD5A07F7807785CA9C662-- From owner-freebsd-current@freebsd.org Mon Oct 16 11:47:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C54CE37AD2 for ; Mon, 16 Oct 2017 11:47:13 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC9A57CC38; Mon, 16 Oct 2017 11:47:12 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id r127so777942itb.5; Mon, 16 Oct 2017 04:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HvBhjvXJ/8x3ULYmTJWfYVN93YmDEWKh/bK05sGPWIM=; b=TQ5AgwNLqQnbmiMWI3QF0aXZHDOIMZPCbRiYQYVAiG02KUAbuMMZcukqzdw3u0kuJb bDk3uj7rcMWs7FMqObr3gnjt+SLhIAg4/XcR6S4xXk2WWecHZVbq1vzykqIFF3X67EtM b6yq1FvRaRwCnixO0r6trYkAjjpjMd1w30i2afpWHL3WdTFaTy+A8NlJgQyoTbdrgmOW lklp2wO7SFd9db2V9oiHq0/r8FHS0oYNJiHbta6e0+eqC2AWQTXVE0pfN4EI6yIuINke KqAPpXML+vjVntoQJe6wDO61aJmaGWrM5HQkewwWdsJ17hj/Ip+A/FSlc5W/Lns70BZc P0dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HvBhjvXJ/8x3ULYmTJWfYVN93YmDEWKh/bK05sGPWIM=; b=S2F+onsIJO3tSS3GqJR2S8TvmfDDS4Xi6XexZgAnvbL2kb2HzHuGf/RgScJnIfAEMm UJ03EJNYHv6CTe7/TddBw8+PTpFJnjsdor1qnLQ3aMpliZLecMGdjNobFly7sx/Oafsb oiMMYBhDkyAxi/GIGaHFsP/4yYa1ujZOULwp/PXZTm7HxavCTuFKbYvB+b5unIrx2BN4 ZZkrce6Yvvvi0liTI67W2jdk57Ox5eT3WtveGufcubGmJ+CpLsWfgSik+oH4vd6w5sPI W+rTyJg+T1Vkqe4TN+3ptNZ8lusBuLftDH/QO2b5K3Jhj6c3swKg7UNPs8pYzgkDxyLG ovHg== X-Gm-Message-State: AMCzsaUCqnP85ln1a49jrAsVhNg2KglzDy6teejBMqn0LXxfPFAL5j7h OX2ZHglN/V9f/+MBCPFpk3J+ce50oSwPSC9xwdU= X-Google-Smtp-Source: ABhQp+Rqx2lCLP+voYWp7V626mtVUAnxRQzGoCAZm1ompoQOJKSug1kDh5Vc3ZzGGVLj4NaTIGz6YTk1gZzx6oiEJ00= X-Received: by 10.36.64.19 with SMTP id n19mr628142ita.119.1508154431756; Mon, 16 Oct 2017 04:47:11 -0700 (PDT) MIME-Version: 1.0 References: <2230.1508150145@critter.freebsd.dk> <21896d6e-75be-3376-bc32-9d911227de5c@freebsd.org> In-Reply-To: <21896d6e-75be-3376-bc32-9d911227de5c@freebsd.org> From: blubee blubeeme Date: Mon, 16 Oct 2017 11:47:01 +0000 Message-ID: Subject: Re: cve-2017-13077 - WPA2 security vulni To: Stefan Esser Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 11:47:13 -0000 This is awesome, thanks! On Mon, Oct 16, 2017, 19:19 Stefan Esser wrote: > Am 16.10.17 um 12:38 schrieb blubee blubeeme: > > well, that's a cluster if I ever seen one. > > > > On Mon, Oct 16, 2017 at 6:35 PM, Poul-Henning Kamp > > wrote: > > > >> -------- > >> In message >> gmail.com> > >> , blubee blubeeme writes: > >> > >>> Does anyone on FreeBSD know if it's affected by this? > >>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077 > >> > >> It is, same as Linux, we use the same wpa_supplicant software > > The attached patch includes the official patch applied by the WPA > developers in https://w1.fi/cgit/hostap/commit/?id=a00e946 but > for our version of wpa_supplicant in /usr/src/contrib. > > Regards, STefan > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Oct 16 12:14:18 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FC2DE39018 for ; Mon, 16 Oct 2017 12:14:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD8B7E0E2 for ; Mon, 16 Oct 2017 12:14:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 5BDECA74; Mon, 16 Oct 2017 15:14:11 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: cve-2017-13077 - WPA2 security vulni To: blubee blubeeme , Poul-Henning Kamp Cc: FreeBSD current References: <2230.1508150145@critter.freebsd.dk> From: Lev Serebryakov Organization: FreeBSD Message-ID: <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org> Date: Mon, 16 Oct 2017 15:14:10 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 12:14:18 -0000 On 16.10.2017 13:38, blubee blubeeme wrote: > well, that's a cluster if I ever seen one. It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. -- // Lev Serebryakov From owner-freebsd-current@freebsd.org Mon Oct 16 13:02:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27CDFE3A4F3 for ; Mon, 16 Oct 2017 13:02:12 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E1F348015B; Mon, 16 Oct 2017 13:02:11 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 451ueT9iQM9gt451wenXD7; Mon, 16 Oct 2017 07:02:04 -0600 X-Authority-Analysis: v=2.2 cv=a+JAzQaF c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=02M-m0pO-4AA:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=sMBj6sIwAAAA:8 a=yaAG3qJ-AAAA:8 a=YxBL1-UpAAAA:8 a=k_vEdIhUomsFTEsDafIA:9 a=CjuIK1q_8ugA:10 a=GFfUI7B0NGUA:10 a=IjZwj45LgO3ly-622nXo:22 a=tjUNV7USy4TualkcfLLZ:22 a=oLVlbjkABFOu4cUI0CGI:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 9F4ED410; Mon, 16 Oct 2017 06:02:02 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v9GD22aC011647; Mon, 16 Oct 2017 06:02:02 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201710161302.v9GD22aC011647@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Stefan Esser cc: freebsd-current@freebsd.org Subject: Re: cve-2017-13077 - WPA2 security vulni In-Reply-To: Message from Stefan Esser of "Mon, 16 Oct 2017 13:19:15 +0200." <21896d6e-75be-3376-bc32-9d911227de5c@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11645.1508158922.1@slippy> Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Oct 2017 06:02:02 -0700 X-CMAE-Envelope: MS4wfO8nz3MX/8z/gU9u7H7/5c7X2YQ5+QfCO3KPVw5tBLfu6cZKiS+BwfT7s74jOVum9XkFGFaczxvfeYGeSkEUT+nffo9WznFc8Tsdh8IEcll6OqKTCCW9 pR0uk8wphfHdE5WEVgRksrIW9zik+KBwu8GLZ96MrqnrlvpQSqXGN48oA/tGYrOFnc6Pecbl6Tj0LgWUe7WJAre+cZjMgKUYfV4= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 13:02:12 -0000 In message <21896d6e-75be-3376-bc32-9d911227de5c@freebsd.org>, Stefan Esse= r = wri tes: > Am 16.10.17 um 12:38 schrieb blubee blubeeme: > > well, that's a cluster if I ever seen one. > > = > > On Mon, Oct 16, 2017 at 6:35 PM, Poul-Henning Kamp > > wrote: > > = > >> -------- > >> In message >> gmail.com> > >> , blubee blubeeme writes: > >> > >>> Does anyone on FreeBSD know if it's affected by this? > >>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=3D2017-13077 > >> > >> It is, same as Linux, we use the same wpa_supplicant software > = > The attached patch includes the official patch applied by the WPA > developers in https://w1.fi/cgit/hostap/commit/?id=3Da00e946 but > for our version of wpa_supplicant in /usr/src/contrib. > = > Regards, STefan > Index: contrib/wpa/src/rsn_supp/wpa.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- contrib/wpa/src/rsn_supp/wpa.c (Revision 324638) > +++ contrib/wpa/src/rsn_supp/wpa.c (Arbeitskopie) > @@ -1534,6 +1534,14 @@ > sm->ptk_set =3D 1; > os_memcpy(&sm->ptk, &sm->tptk, sizeof(sm->ptk)); > os_memset(&sm->tptk, 0, sizeof(sm->tptk)); > + /* > + * This assures the same TPTK in sm->tptk can never be > + * copied twice to sm->pkt as the new PTK. In > + * combination with the installed flag in the wpa_ptk > + * struct, this assures the same PTK is only installed > + * once. > + */ > + sm->renew_snonce =3D 1; > } > } > = > = We should also patch the wpa_supplicant and hostapd ports. Also rmove peer= key functionality: http://w1.fi/cgit/hostap/commit/?id=3De760851176c77ae6d= e19821bb1d5bf3ae2cb5187 Looks like hostapd is also affected. Simple for us, not so simple if you'v= e purchased a commodity wirless router. I doubt most of the vendors will d= o anything. There are over a dozen (excluding tests and debugging outputs, 16 by my co= unt) commits our upstream have applied to hostapd and wpa_supplicant. Rather than commit a blob, we should a) mirror their commits which can be = MFCed to stable and b) then update head and ports to the latest upstream. = B could be MFCed at a later date. -- = Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Mon Oct 16 13:04:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00E14E3A652 for ; Mon, 16 Oct 2017 13:04:23 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C03668035B; Mon, 16 Oct 2017 13:04:22 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4543eTADnM9gt4544enXdE; Mon, 16 Oct 2017 07:04:21 -0600 X-Authority-Analysis: v=2.2 cv=a+JAzQaF c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=02M-m0pO-4AA:10 a=6I5d2MoRAAAA:8 a=yaAG3qJ-AAAA:8 a=oneE3R1DAAAA:8 a=YxBL1-UpAAAA:8 a=0T3iPXDYWNLbjhcSX9QA:9 a=CjuIK1q_8ugA:10 a=Ytm8v_FqGBcA:10 a=q0T5EV-wlGoA:10 a=IjZwj45LgO3ly-622nXo:22 a=oLVlbjkABFOu4cUI0CGI:22 a=2Fs401WYdkfDm1j_wOhm:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 7150442F; Mon, 16 Oct 2017 06:04:15 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v9GD4Fbh011760; Mon, 16 Oct 2017 06:04:15 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201710161304.v9GD4Fbh011760@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: lev@FreeBSD.org cc: blubee blubeeme , Poul-Henning Kamp , FreeBSD current Subject: Re: cve-2017-13077 - WPA2 security vulni In-Reply-To: Message from Lev Serebryakov of "Mon, 16 Oct 2017 15:14:10 +0300." <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Oct 2017 06:04:15 -0700 X-CMAE-Envelope: MS4wfPBVyZb5DVcpqgZ/tJFYQcTsZizEkbRkuA9D2OFd0vG8qz4CWqFiDDrQiXNkqsAhXexreGfHQtGkrMHCKYF6i3nWOdHbNDxZnLHmMGyIbD9R0WrDtN48 sSare41SEN39zFW5L3KDD5ZOjnHl4QSDoj8VYqQR/nJx1UnQRUVxpW3QIOwJF/sayS3DBZdbswIj1BOd6cl/6mFiJRMhJQmbzJnF7tejjajaW64DK1XqfdS/ P5m+VXy2aSYVppaKhd2uzFQyyPhyUBASt19psSJVjMg= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 13:04:23 -0000 In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev Serebryakov writes: > On 16.10.2017 13:38, blubee blubeeme wrote: > > > well, that's a cluster if I ever seen one. > It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, > CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, > CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. The gory details are here: https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt The announcement is here: https://www.krackattacks.com/ -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Mon Oct 16 15:55:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B34EAE3DCEB for ; Mon, 16 Oct 2017 15:55:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41E69E0E; Mon, 16 Oct 2017 15:55:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id b189so4739620wmd.4; Mon, 16 Oct 2017 08:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vJDt2gYIrg4Nkt7bjxJucLRGAvjVdrbT9m9Y0tyOUK0=; b=RabIUtawegsuf3d5wA33tNX5JrVaSnNuFcYH4cSd8qrSlbEHrAx0/pL1W24VvFyqye 9AHjvTZ/Ah7WojLTsbkNOjtHI21H+3kNVoDDRgoiyW2WaaZMDz1ipuNBNJ4UI9X5L7Id gSKbQdA4ufqiXkdjpQE2uvaDsxA6pMrBm/M3rJ9+AhFYRsEguN07KA6FOUMNyv4nk119 7vm/zmNyNE6WqhNNEqfirc50uD2Otd2W8QJwwPOoTzmDXuUeNVmAYxAH5lIwitFXt1NT utLuTgUH6zzXDgDsyWLNz6o9tRQz4KtJ2/UIOZq3ENhB56GyRsmS38zJHUJfGAzR2laj Qr7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vJDt2gYIrg4Nkt7bjxJucLRGAvjVdrbT9m9Y0tyOUK0=; b=o3VX1uXBOH2wGaqNGfcS3r2L6iu2tPdrgmIN7uaICt83Q5qokRne9DQ4UFEvo/PJAZ StD4+V2gKe2SVaTJXGBkXryTLHAFgI5lGHuKrIZwAyhflVwWqWAKfYPgm0K59t9P7kCK 8VFyBWUxWRx0JtU4KX/OkxBQEP81gre7YAWR4TVYDp8FwGz1jigfs2fRR9Kq1qemJMRn r+joa4ab3OZbnJh7wMjBn3HgJudwmBtO96aWktcGXEAyRq7IOFi5ZZ+ELr/gTB2ChFsU NikzXENh0C9BEw0oSoUlo0MsCbm+RMCgf6oG1dDGuZThyTuUtlQCpKAGEeDJoJWkLOHE C+Sg== X-Gm-Message-State: AMCzsaVWHcIrsYvgRoC7Q+Hkx7v6PhXqbTVoEobQF2a8aZ6ipUbK6X9N SLHLAJM6tJr48kWeJMsR/P6sJAwbAeHxUBUN0ZgIlA== X-Google-Smtp-Source: ABhQp+R/cdjdaRBqdfJRgLHeP93JBpEDUqooJzlzGGo0oC/7c6Muue/aEIyxTe34afrCBPW3mFZSfP/CseUICf3l+10= X-Received: by 10.28.181.144 with SMTP id e138mr1408418wmf.115.1508169321478; Mon, 16 Oct 2017 08:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.86.70 with HTTP; Mon, 16 Oct 2017 08:55:20 -0700 (PDT) In-Reply-To: <201710161304.v9GD4Fbh011760@slippy.cwsent.com> References: <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org> <201710161304.v9GD4Fbh011760@slippy.cwsent.com> From: Adrian Chadd Date: Mon, 16 Oct 2017 08:55:20 -0700 Message-ID: Subject: Re: cve-2017-13077 - WPA2 security vulni To: Cy Schubert Cc: Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 15:55:23 -0000 hi, I got the patches a couple days ago. I've been busy with personal life stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If someone beats me to it, great, otherwise I'll try to do it in the next couple days. I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update everything to but so far nope. It should be easy enough to update the port for now as it's at 2.6. -adrian On 16 October 2017 at 06:04, Cy Schubert wrote: > In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev Serebryakov > writes: >> On 16.10.2017 13:38, blubee blubeeme wrote: >> >> > well, that's a cluster if I ever seen one. >> It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. > > The gory details are here: https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt > > The announcement is here: > https://www.krackattacks.com/ > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Oct 16 17:19:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5B28E3FA3F for ; Mon, 16 Oct 2017 17:19:29 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A0D6636D7; Mon, 16 Oct 2017 17:19:29 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id q13so8156377vkb.2; Mon, 16 Oct 2017 10:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rVxPQkB293eSxcYPyFLne74aGMbavL2gA42/7JW7JI8=; b=UFKXK41M1Mb69NJ6c3phQ7eHBcJyWfNzGbtkfR6KfnMa/xkSdyMOhARkm33aQxa6c+ K2gLFxsuXx/jTYU5nhdG0803b7sCCxRSzv38uXKeqR9guG8IQDchdCorr7HJEtm6KL7O rgU3uDqM928AOu0qw2pH+stkxs+HapIAKqCMkhFe5GRpFIgxR7vVSE6oDGGYTi/wB8CT k0QJTEdwkrVcZr0FH0JQmlT4T8uVEKjvQp9waa3TfK7z4JDRhrJWdW5TqFibMKk91+gY NUCxt51B08US4t9V3xN1qOHmU+ltPKNtuwkqVJAtCCjpi0aHXeXEcqS3PFb/x5gmT8Rd UtcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rVxPQkB293eSxcYPyFLne74aGMbavL2gA42/7JW7JI8=; b=Xjv3LxVIgXeJDLsqrFD0vAo18caJOlXj6eQQnpDU1V0NAwz6YQcyJ01j9lSDIRV7sU lSAg3B/YIIDAr5ZEIi58BSLy85PHPsCliHjCsYkEtdQcdl8LBiPiXxv97/lDrxdkz1Ee kVA38k8adj/s+6S6ghyTB6C2DIVML7lD4c6EkZA3u9rEHuVwtTvIIwEZvd90/iJWoMZy vmFaVPjvuXhK9jOhG5cTPuOHI/tB6uNFhaOWPjrIYtHRijK4OtXlR5PEIzcUK8M9rVRw brb7VHUbiH1sPn5drOhf0GE6j76a2fkGLWFVAUrI4Tv9dpUZCeNRYch6BAg5Afc2TNzi 1fMw== X-Gm-Message-State: AMCzsaWfdlgjwcC+inq5zAtSP4D9fuvvPuKpCKrlJlw7RA4Lpa4ikMSE Acqch82+mwLPexGao00OKG7tMg+6+P4PRlrLKXA= X-Google-Smtp-Source: ABhQp+R3M6WL8xZYovMuuoJ5LaKZzYrKWeUvkA3TD/J2i/hPpe+MbuGZXY3HcVxKfZan8DDnonwWT2nXKAfH2DekfFI= X-Received: by 10.31.66.68 with SMTP id p65mr1089864vka.0.1508174368457; Mon, 16 Oct 2017 10:19:28 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.85.8 with HTTP; Mon, 16 Oct 2017 10:19:28 -0700 (PDT) In-Reply-To: References: <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org> <201710161304.v9GD4Fbh011760@slippy.cwsent.com> From: Kevin Oberman Date: Mon, 16 Oct 2017 10:19:28 -0700 X-Google-Sender-Auth: zDFM0Kq5X1s7K1E2Sd-9Leihvck Message-ID: Subject: Re: cve-2017-13077 - WPA2 security vulni To: Adrian Chadd Cc: Cy Schubert , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 17:19:29 -0000 On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd wrote: > hi, > > I got the patches a couple days ago. I've been busy with personal life > stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If > someone beats me to it, great, otherwise I'll try to do it in the next > couple days. > > I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update > everything to but so far nope. It should be easy enough to update the > port for now as it's at 2.6. > > > > -adrian > > > On 16 October 2017 at 06:04, Cy Schubert wrote: > > In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev > Serebryakov > > writes: > >> On 16.10.2017 13:38, blubee blubeeme wrote: > >> > >> > well, that's a cluster if I ever seen one. > >> It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, > >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, > >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. > > > > The gory details are here: https://w1.fi/security/2017-1/ > wpa-packet-number-reuse-with-replayed-messages.txt > > > > The announcement is here: > > https://www.krackattacks.com/ > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > While I do not encourage waiting, it is quite likely that the upstream patch wil show up very soon now that the vulnerability is public. It's also worth noting that fixing either end of the connection is all that is required, as I understand it. So getting an update for your AP is not required. That is very fortunate as the industry has a rather poor record of getting out firmware updates for hardware more than a few months old. Also, it appears that Windows and iOS are not vulnerable due to flaws in their implementation of the WPA2 spec. (Of course, if you update your AP(s), you no longer need to worry about your end devices. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Mon Oct 16 17:56:53 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF872E40A1C for ; Mon, 16 Oct 2017 17:56:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CA366607D; Mon, 16 Oct 2017 17:56:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id f4so5682233wme.0; Mon, 16 Oct 2017 10:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w3eoD9VCROoJa7Eoao0tOAZRAVZ9T0r05cf2J8sZESs=; b=BVF9P97JJM9GqC6i6E85UuI+rXer/M6+gzcCMU75FkFuN3zbQEsZVStaud6ky9DWHa 63YP6dnZW31KPTIT8wRO9+ChTPzyXUwZudkmqyu9Kpn6vEzLBADozXxWFYXnEDg18wPA DonZXUmO8mQIgh9XYYGs19/lX/tmeKXsXt2SrJOdl9DdtX1hsHUoR2WPw2DLfCRMphlB +w2o9Kt57u3Qj4CH+MIJL/mUJ2W9h1PsYEGHU1Y2tC7X1SGoPsGGVYMgw5BBXscXoYfC XDXc99c8IFgv42CUdvE3wEaIkbp53kHOm3PMqkh8RdtUrvDVppITK8ScHbvFW43aEW44 m73g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w3eoD9VCROoJa7Eoao0tOAZRAVZ9T0r05cf2J8sZESs=; b=ZPF4k4K/7S91AAQX+1g943n5xZqrpi/wPgibHLAWC8UjZ6T7hMo9iFcDSckY6hBcww cDUOdFlZyeWMmciR/UTLHMGmeoLilJKWZRlthgQA7fXdRPichujZjD2nrAJCLF7s3Lcp AyRuRpKA+H7TjMF3c1q8AmnCa01jme+aOtwaAZwfeKGIPtfuaYZqGy9ht3/pc3galU78 I+YB0kc7XAUghQ648d4G3HBqwv32KcWNtv6ufjt4+nv7UXi+r1peo7zJ/5VLEQdSxBVp 1NJPlWG1eECOkhXBznkwxjv12Vrqb7m2lRvBgsQtPJTpYBu4xQSwBmHd3e4ISn1/xYzO tBjg== X-Gm-Message-State: AMCzsaWxdpj19ePlpTXPgFz7wifJgiiIJ+GE3yT8BKogQQuwAukK7avx +XpKh8eqZvD+Ng0wme6VN2y19w7uriyeEg/HmKY= X-Google-Smtp-Source: ABhQp+SE1uQkt7a3iS8V29ypIoRSIHY5PT2qqce1mQWQ5iFCp0Y3amPONU8eQ6js57R6WUHs2zYaSQ6wRhtv8IxmUlc= X-Received: by 10.28.31.76 with SMTP id f73mr1621260wmf.139.1508176611549; Mon, 16 Oct 2017 10:56:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.86.70 with HTTP; Mon, 16 Oct 2017 10:56:50 -0700 (PDT) In-Reply-To: References: <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org> <201710161304.v9GD4Fbh011760@slippy.cwsent.com> From: Adrian Chadd Date: Mon, 16 Oct 2017 10:56:50 -0700 Message-ID: Subject: Re: cve-2017-13077 - WPA2 security vulni To: Kevin Oberman Cc: Cy Schubert , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 17:56:53 -0000 Right, there are backported patches against 2.6, but we're running 2.5 in contrib/ . This is all "I'm out of time right now", so if someone wants to do the ports work and/or the contrib work with the patches for this vuln then please do. I should be able to get to it in the next few days but I'm busy with family and employment. -adrian On 16 October 2017 at 10:19, Kevin Oberman wrote: > On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd > wrote: >> >> hi, >> >> I got the patches a couple days ago. I've been busy with personal life >> stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If >> someone beats me to it, great, otherwise I'll try to do it in the next >> couple days. >> >> I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update >> everything to but so far nope. It should be easy enough to update the >> port for now as it's at 2.6. >> >> >> >> -adrian >> >> >> On 16 October 2017 at 06:04, Cy Schubert wrote: >> > In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev >> > Serebryakov >> > writes: >> >> On 16.10.2017 13:38, blubee blubeeme wrote: >> >> >> >> > well, that's a cluster if I ever seen one. >> >> It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, >> >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, >> >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. >> > >> > The gory details are here: >> > https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt >> > >> > The announcement is here: >> > https://www.krackattacks.com/ >> > >> > >> > -- >> > Cheers, >> > Cy Schubert >> > FreeBSD UNIX: Web: http://www.FreeBSD.org >> > >> > The need of the many outweighs the greed of the few. >> > > > > While I do not encourage waiting, it is quite likely that the upstream patch > wil show up very soon now that the vulnerability is public. > > It's also worth noting that fixing either end of the connection is all that > is required, as I understand it. So getting an update for your AP is not > required. That is very fortunate as the industry has a rather poor record of > getting out firmware updates for hardware more than a few months old. Also, > it appears that Windows and iOS are not vulnerable due to flaws in their > implementation of the WPA2 spec. (Of course, if you update your AP(s), you > no longer need to worry about your end devices. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Mon Oct 16 18:09:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39528E40F00 for ; Mon, 16 Oct 2017 18:09:40 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B32A1669FA for ; Mon, 16 Oct 2017 18:09:39 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-wm0-x22e.google.com with SMTP id k4so5742003wmc.1 for ; Mon, 16 Oct 2017 11:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jL0pJAUnh1X+j+cbXMyl3G0ETRhhOEVz/2O5ffKJEFw=; b=qDhwP7F608n8a+8GGneht+xwSZpfnsinXBb85jOF4nOw12uR3SFCaVW5FjaLv7iFeH KuTVWE7g7QFuXMclelvqJ4hGAlQ1nthlaZqrwhpSihKrogmOyXb93pzsTyexOMc2FYt1 2YhzJz7uKldAq190MoThTf3flZ0cdsyM364a6CJyMNDFzA/Lf3nm1EtyjgXl2yFuRXH4 ImgDtLV8PLjo3mkYsMLco9t/Wc1Bkkn+8fBKxGF/AzIt1mcKW+kAO3Kq5KpbPHTFX0lo 8PBhhLOeG8iBRgsd16O0oIqOqqbPw7FKD5+v5u8gzdVYf45NkGT4J2srSHzbE7Y/Hkm7 rCYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jL0pJAUnh1X+j+cbXMyl3G0ETRhhOEVz/2O5ffKJEFw=; b=aDK10TlQLH+bKD3ZjBkMeH4bhjpkHIzL7zhgArC2H1n3NPDs02iOi6I8Nf/V5qCdgI Zm599DZwsSgk0Bfr+gF0l1mdqXwTVFQK8YGSepdnKFXWpt7qINntq3mYq9e0mRvnf9C/ hMTK5lheY3GJeFG24WRRYAgsp+McANS8AWTrwduauPv0zLjXEuDCYdA/2WmBFd0t81jU eOYZhshgqAhCv+TliXiVIcMZjamfjmQtZhXvx31pW0PjlkemoyJWfaoyO4bNPoi7Ub8x CptgfbVOZs8ST3HQIAZsBJrTCUgxYdZCIPuZrGfVGqYNThkUj8w61DU/1P1ncmQeNUyO 5Yag== X-Gm-Message-State: AMCzsaWprGWtXbi9M0ILeVuzT/Cb5e/Onlkfkjchlxx1xIwsYRbrg1h7 8U2xsnw03J9nHHzUkhjf6Qbiy4fq1uVZtfjOzNNnZA== X-Google-Smtp-Source: AOwi7QAhsp5ic4MCCWVwUzyE/tQ5LmVjJuyl8JK4x5Dt/mepgAQf1vTpzAnmr/EwVy8KnI53qa4RJhNOaBrJymeRC7A= X-Received: by 10.80.195.4 with SMTP id a4mr14022692edb.142.1508177378051; Mon, 16 Oct 2017 11:09:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.21 with HTTP; Mon, 16 Oct 2017 11:09:37 -0700 (PDT) In-Reply-To: References: <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org> <201710161304.v9GD4Fbh011760@slippy.cwsent.com> From: Oliver Pinter Date: Mon, 16 Oct 2017 20:09:37 +0200 Message-ID: Subject: Re: cve-2017-13077 - WPA2 security vulni To: Adrian Chadd Cc: Kevin Oberman , Cy Schubert , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 18:09:40 -0000 Hi Adrian! How big effort is to update he in-tree wpa_supplicant/hostapd to the latest supported version? Is there any known regression / feature loss when do the upgrade? On 10/16/17, Adrian Chadd wrote: > Right, there are backported patches against 2.6, but we're running 2.5 > in contrib/ . > > This is all "I'm out of time right now", so if someone wants to do the > ports work and/or the contrib work with the patches for this vuln then > please do. I should be able to get to it in the next few days but I'm > busy with family and employment. > > > > -adrian > > > On 16 October 2017 at 10:19, Kevin Oberman wrote: >> On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd >> wrote: >>> >>> hi, >>> >>> I got the patches a couple days ago. I've been busy with personal life >>> stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If >>> someone beats me to it, great, otherwise I'll try to do it in the next >>> couple days. >>> >>> I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update >>> everything to but so far nope. It should be easy enough to update the >>> port for now as it's at 2.6. >>> >>> >>> >>> -adrian >>> >>> >>> On 16 October 2017 at 06:04, Cy Schubert >>> wrote: >>> > In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev >>> > Serebryakov >>> > writes: >>> >> On 16.10.2017 13:38, blubee blubeeme wrote: >>> >> >>> >> > well, that's a cluster if I ever seen one. >>> >> It is really cluster: CVE-2017-13077, CVE-2017-13078, >>> >> CVE-2017-13079, >>> >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, >>> >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. >>> > >>> > The gory details are here: >>> > https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt >>> > >>> > The announcement is here: >>> > https://www.krackattacks.com/ >>> > >>> > >>> > -- >>> > Cheers, >>> > Cy Schubert >>> > FreeBSD UNIX: Web: http://www.FreeBSD.org >>> > >>> > The need of the many outweighs the greed of the few. >>> > >> >> >> While I do not encourage waiting, it is quite likely that the upstream >> patch >> wil show up very soon now that the vulnerability is public. >> >> It's also worth noting that fixing either end of the connection is all >> that >> is required, as I understand it. So getting an update for your AP is not >> required. That is very fortunate as the industry has a rather poor record >> of >> getting out firmware updates for hardware more than a few months old. >> Also, >> it appears that Windows and iOS are not vulnerable due to flaws in their >> implementation of the WPA2 spec. (Of course, if you update your AP(s), >> you >> no longer need to worry about your end devices. >> -- >> Kevin Oberman, Part time kid herder and retired Network Engineer >> E-mail: rkoberman@gmail.com >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon Oct 16 18:50:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6464BE41DFC for ; Mon, 16 Oct 2017 18:50:55 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13B8367E8B; Mon, 16 Oct 2017 18:50:54 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4ATMeaTVI8LPZ4ATNedYr7; Mon, 16 Oct 2017 12:50:48 -0600 X-Authority-Analysis: v=2.2 cv=e552ceh/ c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=02M-m0pO-4AA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=yaAG3qJ-AAAA:8 a=oneE3R1DAAAA:8 a=wjnT2uRbSL4dhbCOqnIA:9 a=A5avnIW0mJSAs4rF:21 a=lCep0r7k_pUFfa6V:21 a=CjuIK1q_8ugA:10 a=a4w0SzYmEskA:10 a=Ytm8v_FqGBcA:10 a=vCSivk8bNPtGoeRK4R8A:9 a=N3Fj-2trIw4JOXQY:21 a=cr1uzddsactaBIWy:21 a=aiaJdd3xnvG7-4FN:21 a=_W_S_7VecoQA:10 a=Fj9iO6pqr7gSyLvOkxId:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=pxhY87DP9d2VeQe4joPk:22 a=oLVlbjkABFOu4cUI0CGI:22 a=2Fs401WYdkfDm1j_wOhm:22 Received: from [25.172.12.81] (S0106d4ca6d8943b0.gv.shawcable.net [24.68.134.59]) by spqr.komquats.com (Postfix) with ESMTPSA id 94859750; Mon, 16 Oct 2017 11:50:12 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: cve-2017-13077 - WPA2 security vulni Date: Mon, 16 Oct 2017 11:50:20 -0700 To: "Rodney W. Grimes" , Kevin Oberman CC: Adrian Chadd , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Message-Id: <20171016185014.94859750@spqr.komquats.com> X-CMAE-Envelope: MS4wfLTQq3DnJi2O3LnP1j3rCbciNmGrk6LlXWMkwqSR9P0f+aj63KJpPnQQIc9FC0IEphJxf24pVdoSH6kxMdTeTHOzjiR1RzNZw9wWh3vGokIhynVOAgi0 eEVbp9Jh1H38bY4Cgg3LiRtbE3pvcLye3ba96SXpZ2eWAy+ujIFCQ2Xo2AtmHidMfKr996OAE5RjqApzjuWbSSiYI+woSqdeHTtHniVj+0laOOFCu2HG/7Tk u5rzooWO4K2L5eA2JtgrPIbK1JkMiWadYDJUQuYLxHT3q9HX1VNDjjbYmMssQ968V3ykm+8NGNfmiVq0iFLmaEkdtve1HN1IRl3Mt6nPFS/0S4nEf3rSdAVW XFwg1KvKkCd1JGArkR+Hud8YF2ycBZoBHD+guAZFM+/AlwNLcPc= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 18:50:55 -0000 Eight patches have been posted so, it should be easy to patch 2.5, MFC, and= bring head up to 2.6 later. This should avoid the risk of possible regress= ions. I haven't looked at the ports. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Cy Schubert or -----Original Message----- From: Rodney W. Grimes Sent: 16/10/2017 11:14 To: Kevin Oberman Cc: Adrian Chadd; Cy Schubert; Lev Serebryakov; blubee blubeeme; Poul-Henni= ng Kamp; FreeBSD current Subject: Re: cve-2017-13077 - WPA2 security vulni > On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd > wrote: >=20 > > hi, > > > > I got the patches a couple days ago. I've been busy with personal life > > stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If > > someone beats me to it, great, otherwise I'll try to do it in the next > > couple days. > > > > I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update > > everything to but so far nope. It should be easy enough to update the > > port for now as it's at 2.6. > > > > > > > > -adrian > > > > > > On 16 October 2017 at 06:04, Cy Schubert wro= te: > > > In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev > > Serebryakov > > > writes: > > >> On 16.10.2017 13:38, blubee blubeeme wrote: > > >> > > >> > well, that's a cluster if I ever seen one. > > >> It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-1307= 9, > > >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, > > >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. > > > > > > The gory details are here: https://w1.fi/security/2017-1/ > > wpa-packet-number-reuse-with-replayed-messages.txt > > > > > > The announcement is here: > > > https://www.krackattacks.com/ > > > > > > > > > -- > > > Cheers, > > > Cy Schubert > > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > > > The need of the many outweighs the greed of the few. > > > > > >=20 > While I do not encourage waiting, it is quite likely that the upstream > patch wil show up very soon now that the vulnerability is public. >=20 > It's also worth noting that fixing either end of the connection is all th= at > is required, as I understand it. So getting an update for your AP is not > required. That is very fortunate as the industry has a rather poor record > of getting out firmware updates for hardware more than a few months old. > Also, it appears that Windows and iOS are not vulnerable due to flaws in > their implementation of the WPA2 spec. (Of course, if you update your > AP(s), you no longer need to worry about your end devices. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >From my reading of the attack it is the client side that must be fixed, you can not mitigate the client side bug by an update to the AP. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >=20 --=20 Rod Grimes rgrimes@freebsd.= org From owner-freebsd-current@freebsd.org Mon Oct 16 18:56:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61522E420B8 for ; Mon, 16 Oct 2017 18:56:11 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d7::103:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27B9468485; Mon, 16 Oct 2017 18:56:11 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [IPv6:2001:470:25:233:95c8:93e7:5fdd:3562] (unknown [IPv6:2001:470:25:233:95c8:93e7:5fdd:3562]) by host64.shmhost.net (Postfix) with ESMTPSA id 9E23E160E60; Mon, 16 Oct 2017 20:56:05 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: cve-2017-13077 - WPA2 security vulni From: Franco Fichtner In-Reply-To: <20171016185014.94859750@spqr.komquats.com> Date: Mon, 16 Oct 2017 20:56:03 +0200 Cc: "Rodney W. Grimes" , Kevin Oberman , Adrian Chadd , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: <4CF70CE3-AC4B-4AFE-BF14-C78C5310F2EB@lastsummer.de> References: <20171016185014.94859750@spqr.komquats.com> To: Cy Schubert X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at host64.shmhost.net X-Virus-Status: Clean X-Spam-Flag: NO X-Spam-Score: -1.0 X-Spam-Status: No score=-1.0 tagged_above=10.0 required=10.0 tests=[ALL_TRUSTED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 18:56:11 -0000 > On 16. Oct 2017, at 8:50 PM, Cy Schubert = wrote: >=20 > Eight patches have been posted so, it should be easy to patch 2.5, = MFC, and bring head up to 2.6 later. This should avoid the risk of = possible regressions. Nope, does not apply easily. Refactoring changed contexts, function = names and variable usage logic between 2.5 and 2.6. Cheers, Franco= From owner-freebsd-current@freebsd.org Mon Oct 16 19:36:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17F20E42FC7 for ; Mon, 16 Oct 2017 19:36:49 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D166269C6D; Mon, 16 Oct 2017 19:36:48 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4BBteajTS8LPZ4BBvedlFl; Mon, 16 Oct 2017 13:36:47 -0600 X-Authority-Analysis: v=2.2 cv=e552ceh/ c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=02M-m0pO-4AA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=yaAG3qJ-AAAA:8 a=oneE3R1DAAAA:8 a=YCqnUBC7WgR2pJLgrhsA:9 a=CjuIK1q_8ugA:10 a=a4w0SzYmEskA:10 a=Ytm8v_FqGBcA:10 a=Fj9iO6pqr7gSyLvOkxId:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=pxhY87DP9d2VeQe4joPk:22 a=oLVlbjkABFOu4cUI0CGI:22 a=2Fs401WYdkfDm1j_wOhm:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id D5FAC7A4; Mon, 16 Oct 2017 12:36:44 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v9GJaRLo072189; Mon, 16 Oct 2017 12:36:27 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201710161936.v9GJaRLo072189@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Oliver Pinter cc: Adrian Chadd , Kevin Oberman , Cy Schubert , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Subject: Re: cve-2017-13077 - WPA2 security vulni In-Reply-To: Message from Oliver Pinter of "Mon, 16 Oct 2017 20:09:37 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Oct 2017 12:36:27 -0700 X-CMAE-Envelope: MS4wfI485B0FgU3vH7nz2LsXNWRUR4YHRw/AEs8ZhwLOjM45Oxt+dclYevbA7npuUSkdPjTk8yeUe2La6ct6N6R+7cENFt6YoGjmloRHzymsZWM17I+3becG dqesWUyWCgLgoahEQ36wviDUewgwZd3UIVuNJUUOFKXqeE6T/LQrgf0PVF1aNtJ6orSrq27HSiEVTOsKRvOOcFEu6bH+YwkvCRbJvl3j/Ej26OVE2StW2o4r mOGJtRj3nNefu06SQgb7u8mt/wvuWtBDw51a3uUaWglY37/lbc/tYtlhzCyA4pf5KkJj6LJZT8u+gHdCCmkSCDlHM1zOFl9OcjzQZCVYifm/t4WN3GbJE045 xA5wpQeeT15De+e6OLKxcmFjMnDObA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 19:36:49 -0000 Looking at the wpa_supplicant port, it may be a quicker win than base at the moment. I don't have much of my lunch hour left to complete anything. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. In message , Oliver Pinter writes: > Hi Adrian! > > How big effort is to update he in-tree wpa_supplicant/hostapd to the > latest supported version? > Is there any known regression / feature loss when do the upgrade? > > On 10/16/17, Adrian Chadd wrote: > > Right, there are backported patches against 2.6, but we're running 2.5 > > in contrib/ . > > > > This is all "I'm out of time right now", so if someone wants to do the > > ports work and/or the contrib work with the patches for this vuln then > > please do. I should be able to get to it in the next few days but I'm > > busy with family and employment. > > > > > > > > -adrian > > > > > > On 16 October 2017 at 10:19, Kevin Oberman wrote: > >> On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd > >> wrote: > >>> > >>> hi, > >>> > >>> I got the patches a couple days ago. I've been busy with personal life > >>> stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If > >>> someone beats me to it, great, otherwise I'll try to do it in the next > >>> couple days. > >>> > >>> I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update > >>> everything to but so far nope. It should be easy enough to update the > >>> port for now as it's at 2.6. > >>> > >>> > >>> > >>> -adrian > >>> > >>> > >>> On 16 October 2017 at 06:04, Cy Schubert > >>> wrote: > >>> > In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev > >>> > Serebryakov > >>> > writes: > >>> >> On 16.10.2017 13:38, blubee blubeeme wrote: > >>> >> > >>> >> > well, that's a cluster if I ever seen one. > >>> >> It is really cluster: CVE-2017-13077, CVE-2017-13078, > >>> >> CVE-2017-13079, > >>> >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, > >>> >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. > >>> > > >>> > The gory details are here: > >>> > https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-mes > sages.txt > >>> > > >>> > The announcement is here: > >>> > https://www.krackattacks.com/ > >>> > > >>> > > >>> > -- > >>> > Cheers, > >>> > Cy Schubert > >>> > FreeBSD UNIX: Web: http://www.FreeBSD.org > >>> > > >>> > The need of the many outweighs the greed of the few. > >>> > > >> > >> > >> While I do not encourage waiting, it is quite likely that the upstream > >> patch > >> wil show up very soon now that the vulnerability is public. > >> > >> It's also worth noting that fixing either end of the connection is all > >> that > >> is required, as I understand it. So getting an update for your AP is not > >> required. That is very fortunate as the industry has a rather poor record > >> of > >> getting out firmware updates for hardware more than a few months old. > >> Also, > >> it appears that Windows and iOS are not vulnerable due to flaws in their > >> implementation of the WPA2 spec. (Of course, if you update your AP(s), > >> you > >> no longer need to worry about your end devices. > >> -- > >> Kevin Oberman, Part time kid herder and retired Network Engineer > >> E-mail: rkoberman@gmail.com > >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Mon Oct 16 18:28:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A0C3E417F2 for ; Mon, 16 Oct 2017 18:28:09 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16F7B673B9; Mon, 16 Oct 2017 18:28:08 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v9GIDNCn011294; Mon, 16 Oct 2017 11:13:23 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v9GIDNrm011293; Mon, 16 Oct 2017 11:13:23 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201710161813.v9GIDNrm011293@pdx.rh.CN85.dnsmgr.net> Subject: Re: cve-2017-13077 - WPA2 security vulni In-Reply-To: To: Kevin Oberman Date: Mon, 16 Oct 2017 11:13:23 -0700 (PDT) CC: Adrian Chadd , Cy Schubert , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 16 Oct 2017 19:50:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 18:28:09 -0000 > On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd > wrote: > > > hi, > > > > I got the patches a couple days ago. I've been busy with personal life > > stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If > > someone beats me to it, great, otherwise I'll try to do it in the next > > couple days. > > > > I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update > > everything to but so far nope. It should be easy enough to update the > > port for now as it's at 2.6. > > > > > > > > -adrian > > > > > > On 16 October 2017 at 06:04, Cy Schubert wrote: > > > In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev > > Serebryakov > > > writes: > > >> On 16.10.2017 13:38, blubee blubeeme wrote: > > >> > > >> > well, that's a cluster if I ever seen one. > > >> It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, > > >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, > > >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. > > > > > > The gory details are here: https://w1.fi/security/2017-1/ > > wpa-packet-number-reuse-with-replayed-messages.txt > > > > > > The announcement is here: > > > https://www.krackattacks.com/ > > > > > > > > > -- > > > Cheers, > > > Cy Schubert > > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > > > The need of the many outweighs the greed of the few. > > > > > > > While I do not encourage waiting, it is quite likely that the upstream > patch wil show up very soon now that the vulnerability is public. > > It's also worth noting that fixing either end of the connection is all that > is required, as I understand it. So getting an update for your AP is not > required. That is very fortunate as the industry has a rather poor record > of getting out firmware updates for hardware more than a few months old. > Also, it appears that Windows and iOS are not vulnerable due to flaws in > their implementation of the WPA2 spec. (Of course, if you update your > AP(s), you no longer need to worry about your end devices. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >From my reading of the attack it is the client side that must be fixed, you can not mitigate the client side bug by an update to the AP. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Oct 16 20:07:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDA09E43D4A for ; Mon, 16 Oct 2017 20:07:17 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 91CF86B08A; Mon, 16 Oct 2017 20:07:17 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4BfOeatv18LPZ4BfPedsj1; Mon, 16 Oct 2017 14:07:16 -0600 X-Authority-Analysis: v=2.2 cv=e552ceh/ c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=02M-m0pO-4AA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=VxmjJ2MpAAAA:8 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=yaAG3qJ-AAAA:8 a=oneE3R1DAAAA:8 a=DrAYh1O1B3FoTUCQS64A:9 a=CjuIK1q_8ugA:10 a=a4w0SzYmEskA:10 a=Ytm8v_FqGBcA:10 a=Fj9iO6pqr7gSyLvOkxId:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=7gXAzLPJhVmCkEl4_tsf:22 a=pxhY87DP9d2VeQe4joPk:22 a=oLVlbjkABFOu4cUI0CGI:22 a=2Fs401WYdkfDm1j_wOhm:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 7CA7F7EF; Mon, 16 Oct 2017 13:07:14 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v9GK6v7G077342; Mon, 16 Oct 2017 13:06:57 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201710162006.v9GK6v7G077342@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: Oliver Pinter , Adrian Chadd , Kevin Oberman , Cy Schubert , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Subject: Re: cve-2017-13077 - WPA2 security vulni In-Reply-To: Message from Cy Schubert of "Mon, 16 Oct 2017 12:36:27 -0700." <201710161936.v9GJaRLo072189@slippy.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Oct 2017 13:06:57 -0700 X-CMAE-Envelope: MS4wfBkOGfq2kWPsEvTsdD7jSyfdFc1O5Pd4m8SNUv0KoOoFAqHHT11Se9Jk9RyJXpkEGBVNWFBZsnFVSkCHsoYoH8Ku3rKXvzycapZYjLVVq6dWWOMGzmLy 7xJaMYzoyxeJ42VSTsKDa+sQEB99gYzWlLfk+QbePtzNA6dzgLLtCQq0B/gTOVfJkv6xx+aniZILKFh22VKUoEhQPRspI3AjFuDCJ/I1l+WuFjteTdvS46db QKmS/t8MqteIvuTxbXbPwKM2J73OEAoZ68vfWRr2ttwIsxuoCDa5SzISG5XIosxjT9cVI2H7qFD3JFcbRzitrcEsrLGDOohCq3/JjU211UCbNpacr5WLG5bO SJz6+xUu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 20:07:17 -0000 I'll commit the wpa_supplicant port now but I don't have enough time this lunch hour to create a vuxml entry or to update the hostapd port. It may be simpler to update base to 2.6 to facilitate patching. What do people think? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. In message <201710161936.v9GJaRLo072189@slippy.cwsent.com>, Cy Schubert writes: > Looking at the wpa_supplicant port, it may be a quicker win than base at > the moment. > > I don't have much of my lunch hour left to complete anything. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > In message om> > , Oliver Pinter writes: > > Hi Adrian! > > > > How big effort is to update he in-tree wpa_supplicant/hostapd to the > > latest supported version? > > Is there any known regression / feature loss when do the upgrade? > > > > On 10/16/17, Adrian Chadd wrote: > > > Right, there are backported patches against 2.6, but we're running 2.5 > > > in contrib/ . > > > > > > This is all "I'm out of time right now", so if someone wants to do the > > > ports work and/or the contrib work with the patches for this vuln then > > > please do. I should be able to get to it in the next few days but I'm > > > busy with family and employment. > > > > > > > > > > > > -adrian > > > > > > > > > On 16 October 2017 at 10:19, Kevin Oberman wrote: > > >> On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd > > >> wrote: > > >>> > > >>> hi, > > >>> > > >>> I got the patches a couple days ago. I've been busy with personal life > > >>> stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If > > >>> someone beats me to it, great, otherwise I'll try to do it in the next > > >>> couple days. > > >>> > > >>> I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update > > >>> everything to but so far nope. It should be easy enough to update the > > >>> port for now as it's at 2.6. > > >>> > > >>> > > >>> > > >>> -adrian > > >>> > > >>> > > >>> On 16 October 2017 at 06:04, Cy Schubert > > >>> wrote: > > >>> > In message <44161b4d-f834-a01d-6ddb-475f208762f9@FreeBSD.org>, Lev > > >>> > Serebryakov > > >>> > writes: > > >>> >> On 16.10.2017 13:38, blubee blubeeme wrote: > > >>> >> > > >>> >> > well, that's a cluster if I ever seen one. > > >>> >> It is really cluster: CVE-2017-13077, CVE-2017-13078, > > >>> >> CVE-2017-13079, > > >>> >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, > > >>> >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. > > >>> > > > >>> > The gory details are here: > > >>> > https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-m > es > > sages.txt > > >>> > > > >>> > The announcement is here: > > >>> > https://www.krackattacks.com/ > > >>> > > > >>> > > > >>> > -- > > >>> > Cheers, > > >>> > Cy Schubert > > >>> > FreeBSD UNIX: Web: http://www.FreeBSD.org > > >>> > > > >>> > The need of the many outweighs the greed of the few. > > >>> > > > >> > > >> > > >> While I do not encourage waiting, it is quite likely that the upstream > > >> patch > > >> wil show up very soon now that the vulnerability is public. > > >> > > >> It's also worth noting that fixing either end of the connection is all > > >> that > > >> is required, as I understand it. So getting an update for your AP is not > > >> required. That is very fortunate as the industry has a rather poor recor > d > > >> of > > >> getting out firmware updates for hardware more than a few months old. > > >> Also, > > >> it appears that Windows and iOS are not vulnerable due to flaws in their > > >> implementation of the WPA2 spec. (Of course, if you update your AP(s), > > >> you > > >> no longer need to worry about your end devices. > > >> -- > > >> Kevin Oberman, Part time kid herder and retired Network Engineer > > >> E-mail: rkoberman@gmail.com > > >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > > > > From owner-freebsd-current@freebsd.org Mon Oct 16 20:20:06 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 328B3E4424B for ; Mon, 16 Oct 2017 20:20:06 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F1FC06BA60; Mon, 16 Oct 2017 20:20:05 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4BrgeVPWNM9gt4BrhepI8m; Mon, 16 Oct 2017 14:19:59 -0600 X-Authority-Analysis: v=2.2 cv=a+JAzQaF c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=02M-m0pO-4AA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=beCajIYSYeKNm25g5KgA:9 a=CjuIK1q_8ugA:10 a=a3SBYUOku7_WlhUB:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=pxhY87DP9d2VeQe4joPk:22 Received: from [25.172.12.81] (S0106d4ca6d8943b0.gv.shawcable.net [24.68.134.59]) by spqr.komquats.com (Postfix) with ESMTPSA id A2477AD; Mon, 16 Oct 2017 13:19:55 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: cve-2017-13077 - WPA2 security vulni Date: Mon, 16 Oct 2017 13:19:56 -0700 To: Franco Fichtner CC: "Rodney W. Grimes" , Kevin Oberman , Adrian Chadd , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Message-Id: <20171016201955.A2477AD@spqr.komquats.com> X-CMAE-Envelope: MS4wfMwVdCG6CDiuH4Jk9HcqMPvrSb3v488n2hHBfgT94qgbWty2+Me7ULsrLRJFJvLsjvLO9uUBEJAWJ2Xm6rBF1SnChlbBkwxRVtId0dI7IVlf1FMqpQ9r Xq/ajqCa7Cr5y3yJh5fgTjGvE1HanKUrbv0A7wA864tt0q90vziHzE2bOfzCmTz24cATF4fgHszpsa+fV7dJi6B9F52ENrCP+7JdgGxAnWfvuz43yr5jTyCt SyCJYtazxMRDKe5CmP8wIxtT0l3qMQxwqhbvkBw2iQuk1Uc3Ywb3HgxHNhfGmj7uOVZV4Crjg4cwOx9EO0bWedTTwxMmkzp5SMW2fadZ4NcRpQehndnfmHbo b9Mc28ruWA/e1WHsxFmLYkk5GhT9CRHLfHtysKW3CxTeXSjDEZ3123xQxZk2EjCo7G+jSBRy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 20:20:06 -0000 It doesn't, which is why I patched the port at lunch today. It's a quick wi= n with the time I had. I think we should update base to 2.6 and apply the patches. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Cy Schubert or -----Original Message----- From: Franco Fichtner Sent: 16/10/2017 11:57 To: Cy Schubert Cc: Rodney W. Grimes; Kevin Oberman; Adrian Chadd; Lev Serebryakov; blubee = blubeeme; Poul-Henning Kamp; FreeBSD current Subject: Re: cve-2017-13077 - WPA2 security vulni > On 16. Oct 2017, at 8:50 PM, Cy Schubert wrote= : >=20 > Eight patches have been posted so, it should be easy to patch 2.5, MFC, a= nd bring head up to 2.6 later. This should avoid the risk of possible regre= ssions. Nope, does not apply easily. Refactoring changed contexts, function names and variable usage logic between 2.5 and 2.6. Cheers, Franco From owner-freebsd-current@freebsd.org Mon Oct 16 20:33:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AB1DE44A87 for ; Mon, 16 Oct 2017 20:33:30 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [213.239.241.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E36FC6C4DD; Mon, 16 Oct 2017 20:33:29 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [IPv6:2001:470:25:233:d5b4:1be5:d68e:f1eb] (unknown [IPv6:2001:470:25:233:d5b4:1be5:d68e:f1eb]) by host64.shmhost.net (Postfix) with ESMTPSA id D9173160B94; Mon, 16 Oct 2017 22:33:24 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: cve-2017-13077 - WPA2 security vulni From: Franco Fichtner In-Reply-To: <20171016201955.A2477AD@spqr.komquats.com> Date: Mon, 16 Oct 2017 22:33:24 +0200 Cc: "Rodney W. Grimes" , Kevin Oberman , Adrian Chadd , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: <17E2DA41-2CC4-42DE-A833-10A69F660105@lastsummer.de> References: <20171016201955.A2477AD@spqr.komquats.com> To: Cy Schubert X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at host64.shmhost.net X-Virus-Status: Clean X-Spam-Flag: NO X-Spam-Score: -1.0 X-Spam-Status: No score=-1.0 tagged_above=10.0 required=10.0 tests=[ALL_TRUSTED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 20:33:30 -0000 > On 16. Oct 2017, at 10:19 PM, Cy Schubert = wrote: >=20 > It doesn't, which is why I patched the port at lunch today. It's a = quick win with the time I had. Thank you, much appreciated. Will give it some testing. > I think we should update base to 2.6 and apply the patches. Sounds like a plan when the port gives no apparent issues. Cheers, Franco From owner-freebsd-current@freebsd.org Mon Oct 16 22:24:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA5CEE46E14 for ; Mon, 16 Oct 2017 22:24:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0051.outbound.protection.outlook.com [104.47.34.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 729C26FF8C for ; Mon, 16 Oct 2017 22:24:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB1898.CANPRD01.PROD.OUTLOOK.COM (52.132.49.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 16 Oct 2017 22:24:35 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::50ab:b8bf:bbb9:81f4]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::50ab:b8bf:bbb9:81f4%13]) with mapi id 15.20.0077.022; Mon, 16 Oct 2017 22:24:34 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" CC: "fabian.freyer@physik.tu-berlin.de" Subject: pfind_locked(pid) fails when in a jail? Thread-Topic: pfind_locked(pid) fails when in a jail? Thread-Index: AQHTRsy4PlPkoH+r1k6i+VZl2ipOVw== Date: Mon, 16 Oct 2017 22:24:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1898; 6:GOi1CKx5W7V5V1c0cGo5dHL7rTBmmxnFbz5Bt3W5QDgQ0WZRVhNlo9KW0iqx/+f4bfX59es3mT+tSRuSxbdjxQG9mIbRdq9JXjigP9wI4Hyjo0TgWiFaciCsmXCKShq4lO8VSryBbWX4C3TLcHnh97d4+L+2T69w3MiVljU3uHCDf9mWGZ6vpp2dziPmpKzwZhl7x2bQdoJh8J39fTM5AVZCXUeRR2wyJU+w4wfSvzGSm2LMOYudmATYGXroOOsQ8/sPTNiqe/l1I7OSM4ZP6FbvveOP9KEIPswplVtBuvYWoav8Yt+1PQiwU1X2TmDd/pHZOaPF334AB7aFqh8mNw==; 5:8eDVM9Yj8gOVn4q9M4Bg/zjL29fm1Ntw+9v6L1wBFwN9Pel//uR5v/bX7QmdDlutIfUXHpOUmZ2G+jdmarPVGqyDgtDLN3vf+tL/oxa1ug5+MXbdTjeu2AEsL37pt4FGyBNulHYr5u5a5arWIAdJDg==; 24:Rqw/HcQKrm/z0acpu3AD2aVyY0E/G5Qp0W1qw0ym7utdHf/zVxXOzoQwZRzNTo4gFjOS7AzUJwS58g37pBcAiB0zGyTOEiTYbcrjsgL6tTc=; 7:LU17x8Wkp0HmyYlpTepLy3nHd76yNZiI4r8Lnq0eHCchgU11bwfrykjn1bs3+KC5t1oAjKVtGM3MUS9ijvA9za6ZFjK5qaAUX64r4lM6jnHk3ObhCmtXlyOXS63G1kmFz3I/4VE5P7/UTDWLeKwlFKGwCIB8LM7m1rwDE3gano/vzQsMWz1/r8WI6jwsLe2R9MT9bv7YVfXsqz9F2MM8DJXtzdvHD5KRM1UDQZJQOYQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b9170dc4-35ae-4b50-1a9a-08d514e4ae17 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YTOPR0101MB1898; x-ms-traffictypediagnostic: YTOPR0101MB1898: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTOPR0101MB1898; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTOPR0101MB1898; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(51874003)(199003)(189002)(8936002)(786003)(316002)(2501003)(81156014)(81166006)(33656002)(102836003)(6506006)(6436002)(97736004)(3660700001)(9686003)(74482002)(68736007)(305945005)(5250100002)(7696004)(8676002)(189998001)(55016002)(74316002)(5660300001)(53936002)(105586002)(106356001)(2351001)(3280700002)(5640700003)(101416001)(2900100001)(6916009)(478600001)(14454004)(2906002)(86362001)(50986999)(4326008)(25786009)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1898; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 22:24:34.8173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1898 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 22:24:37 -0000 Hi, A problem w.r.t. the NFSv4 client's renew thread (nfscl) running up a lot o= f CPU when the NFSv4 mount is in a jail has been reported to the freebsd-stable@ mailing list. I know nothing about jails, but when looking at the code, the most obvious cause of this would be "pfind_locked(pid)" failing to find a process. - Will a jail affect how pfind_locked() behaves? - If the answer is "yes", then I need to know how to either... 1 - Make pfind_locked() work the same as when no jail exists. OR 2 - A way for the Renew thread can determine that a jail will affect pfi= nd_locked() behaviour, so it can avoid this problem. #1 is preferred, since #2 may not be 100% correct, although #2 would allow = the code to behave well for most cases. (The exception is a case where a file r= emains open for a long period of time, with different processes doing byte range l= ocks on the file.) Thanks in advance for any help w.r.t. jail behaviour, rick= From owner-freebsd-current@freebsd.org Mon Oct 16 22:32:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B956FE4706A for ; Mon, 16 Oct 2017 22:32:36 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8224470385; Mon, 16 Oct 2017 22:32:35 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4Dw0ewSniI8mC4Dw1eFpPq; Mon, 16 Oct 2017 16:32:35 -0600 X-Authority-Analysis: v=2.2 cv=HahkdmM8 c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=02M-m0pO-4AA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=beCajIYSYeKNm25g5KgA:9 a=CjuIK1q_8ugA:10 a=y1Rpy44EdsbgkCNY:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=pxhY87DP9d2VeQe4joPk:22 Received: from [25.172.12.81] (S0106d4ca6d8943b0.gv.shawcable.net [24.68.134.59]) by spqr.komquats.com (Postfix) with ESMTPSA id 923A0191; Mon, 16 Oct 2017 15:32:31 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: cve-2017-13077 - WPA2 security vulni Date: Mon, 16 Oct 2017 15:32:32 -0700 To: Franco Fichtner CC: "Rodney W. Grimes" , Kevin Oberman , Adrian Chadd , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Message-Id: <20171016223231.923A0191@spqr.komquats.com> X-CMAE-Envelope: MS4wfGwCY8x8FtSvLdxnSnEmV2Xo0/JwJyqpVzhTHDszXVE+RQA+LYTF58P/Bix05nYcipq0ybkdLl6hsPUA8KY11Dq6DKsGJimvq6nqQLKjMVWeyvg3LovY EiKMNpnYNmBrnDfdiFUJ2xRLe4uSx0VwWVPEShoA5e+fla+NnTt3xMfhRdGFyVz5qxB/343mMUKfI+8kaFvkXrwSfrwwH2FNdnUl4MNh+9oW+IZp9zVvgrqY UOUWbRUU7YJ/9UzRuLEE9Q5hNNePTX1G3t8unA7u0A7T8qC7aREK5ipcEwfBzZMO8OXcHF9lI7um904jp4g0Z2Op6UB55vBPBTDI7wnp3pamsdso/1783ycl /xcL5Sx2Pas66dZF0HYRuZvZWTPrn8E+Uf308UrPHrCZ+wcLyewF5Ksto0dJE2NfNR1W8X97 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 22:32:36 -0000 I'll test it when I get home tonight. The WiFi here at the tech park is ope= n so, I couldn't test here. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Cy Schubert or -----Original Message----- From: Franco Fichtner Sent: 16/10/2017 13:34 To: Cy Schubert Cc: Rodney W. Grimes; Kevin Oberman; Adrian Chadd; Lev Serebryakov; blubee = blubeeme; Poul-Henning Kamp; FreeBSD current Subject: Re: cve-2017-13077 - WPA2 security vulni > On 16. Oct 2017, at 10:19 PM, Cy Schubert wrot= e: >=20 > It doesn't, which is why I patched the port at lunch today. It's a quick = win with the time I had. Thank you, much appreciated. Will give it some testing. > I think we should update base to 2.6 and apply the patches. Sounds like a plan when the port gives no apparent issues. Cheers, Franco From owner-freebsd-current@freebsd.org Mon Oct 16 22:38:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3679CE4723B for ; Mon, 16 Oct 2017 22:38:20 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E341570591 for ; Mon, 16 Oct 2017 22:38:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x236.google.com with SMTP id 31so9599654qtz.9 for ; Mon, 16 Oct 2017 15:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zGL26q/V3Rn7ygDqcyQkCz9wMBVdouaIpcOuIkal4x4=; b=UlOpi16+p7D32vlV7p8owmuf7fSAS1rFqrXOYah88XOAphOdWaD9eNXe88CATf05hm SGhS1SJOyRZeths3UzR/ia9B67cppaqLzyrx4+a6AvK0FcDpPu9poII2sQCvH2OSzNvx CdYQwOSVqTQZIuogetj6z6tl0TLAWShwxV/xngVYTfHvlWaZB/dcg9nrNqueU1Pcn8zP fQCENujFcFnW3banflw/IxzjXZ1VqZrULFvKoFjh5vBtheEFpYTlj6Px1ex0EhitehYN 7KF4GLjmx6ToCJBYJwsatcFDbI8fo917JMKIyXkVTPDPyS1X4w/k6xqL6quVA7DhCLYk yp5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zGL26q/V3Rn7ygDqcyQkCz9wMBVdouaIpcOuIkal4x4=; b=oZYAuIJGBi6jK742vQruR/AMbzHv7W6FjRnD7G36dJUeTb6j7/KXqpycxZcEPWH5K5 vDdxpSrMT6HfwckPh7l4QU59BiPFCXfj6tPOBUuNimE/YsTp0xv01bzdIQPpLRPVLeDh VxDj98ruInGVuz6975wljr4Z8p4zWMX/Dubuy2KgbCW0LZli+j7qSBWcCNYmB0OSk+IS eZApwCvQuvNy3WzkGRHXVbjDolsob+T9Q/vVgvRFo52TeumpZMo8w588kkfEy/fiU9LE B5DjHksub0Fv9cW4/FNNeDxE9yJxjeUSBkO4BMRTiEp+/RgSyQSaVHslOBOPEFgFfXis Lqag== X-Gm-Message-State: AMCzsaW33+IBrHUFepMY6N2PGd1/Me6PjvmAd/5Vt1VAvF3DT9o4kitB j+dDxmslSNuzKTSj7dSehflyUOXO8kykIy+wfmo= X-Google-Smtp-Source: AOwi7QBIWcJy/7A/pcropJAvFMtn8zCxlHBnvJ5dUGFCCaZjiBNkYAHXnFPtxIw9hjkeUb2//Dv7SWm8CYj1BgB+lo4= X-Received: by 10.200.27.221 with SMTP id m29mr17108908qtk.152.1508193495894; Mon, 16 Oct 2017 15:38:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.51.167 with HTTP; Mon, 16 Oct 2017 15:38:15 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Tue, 17 Oct 2017 00:38:15 +0200 Message-ID: Subject: Re: pfind_locked(pid) fails when in a jail? To: Rick Macklem Cc: "freebsd-current@freebsd.org" , "fabian.freyer@physik.tu-berlin.de" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 22:38:20 -0000 On Tue, Oct 17, 2017 at 12:24 AM, Rick Macklem wrote: > Hi, > > A problem w.r.t. the NFSv4 client's renew thread (nfscl) running up a lot > of CPU > when the NFSv4 mount is in a jail has been reported to the freebsd-stable@ > mailing list. > > I know nothing about jails, but when looking at the code, the most obvious > cause of this would be "pfind_locked(pid)" failing to find a process. > - Will a jail affect how pfind_locked() behaves? > - If the answer is "yes", then I need to know how to either... > 1 - Make pfind_locked() work the same as when no jail exists. > OR > 2 - A way for the Renew thread can determine that a jail will affect > pfind_locked() > behaviour, so it can avoid this problem. > #1 is preferred, since #2 may not be 100% correct, although #2 would allow > the > code to behave well for most cases. (The exception is a case where a file > remains > open for a long period of time, with different processes doing byte range > locks on > the file.) > pfind* does not do any filtering. The real question though is why are you calling it in the first place. The calls I grepped in nfscl_procdoesntexist are highly suspicious - there is no guarantee the process you found here is the same you had at the time you were saving the pid. There is no usable process exit notification right now, but it can be added if necessary. -- Mateusz Guzik From owner-freebsd-current@freebsd.org Mon Oct 16 23:20:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C86B9E4826C for ; Mon, 16 Oct 2017 23:20:00 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FDB571B20 for ; Mon, 16 Oct 2017 23:19:59 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 81f256a7-b2c8-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 81f256a7-b2c8-11e7-a893-25625093991c; Mon, 16 Oct 2017 23:19:51 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9GNJkDJ002113; Mon, 16 Oct 2017 17:19:46 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508195986.74236.6.camel@freebsd.org> Subject: Re: pfind_locked(pid) fails when in a jail? From: Ian Lepore To: Mateusz Guzik , Rick Macklem Cc: "freebsd-current@freebsd.org" , "fabian.freyer@physik.tu-berlin.de" Date: Mon, 16 Oct 2017 17:19:46 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 23:20:00 -0000 On Tue, 2017-10-17 at 00:38 +0200, Mateusz Guzik wrote: > On Tue, Oct 17, 2017 at 12:24 AM, Rick Macklem wrote: > > > > > Hi, > > > > A problem w.r.t. the NFSv4 client's renew thread (nfscl) running up a lot > > of CPU > > when the NFSv4 mount is in a jail has been reported to the freebsd-stable@ > > mailing list. > > > > I know nothing about jails, but when looking at the code, the most obvious > > cause of this would be "pfind_locked(pid)" failing to find a process. > > - Will a jail affect how pfind_locked() behaves? > > - If the answer is "yes", then I need to know how to either... > >    1 - Make pfind_locked() work the same as when no jail exists. > >    OR > >    2 - A way for the Renew thread can determine that a jail will affect > > pfind_locked() > >      behaviour, so it can avoid this problem. > > #1 is preferred, since #2 may not be 100% correct, although #2 would allow > > the > > code to behave well for most cases. (The exception is a case where a file > > remains > > open for a long period of time, with different processes doing byte range > > locks on > > the file.) > > > pfind* does not do any filtering. > > The real question though is why are you calling it in the first place. The > calls > I grepped in nfscl_procdoesntexist are highly suspicious - there is no > guarantee > the process you found here is the same you had at the time you were saving > the pid. > > There is no usable process exit notification right now, but it can be added > if necessary. > Does that mean there is something wrong with the existing eventhandler notifications related to proc fork/exec/exit? -- Ian From owner-freebsd-current@freebsd.org Tue Oct 17 00:08:16 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D88CEE492CE for ; Tue, 17 Oct 2017 00:08:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0051.outbound.protection.outlook.com [104.47.34.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75D9B730DB; Tue, 17 Oct 2017 00:08:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB1308.CANPRD01.PROD.OUTLOOK.COM (52.132.45.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 17 Oct 2017 00:08:15 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::50ab:b8bf:bbb9:81f4]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::50ab:b8bf:bbb9:81f4%13]) with mapi id 15.20.0077.022; Tue, 17 Oct 2017 00:08:15 +0000 From: Rick Macklem To: Mateusz Guzik , Ian Lepore CC: "freebsd-current@freebsd.org" , "fabian.freyer@physik.tu-berlin.de" Subject: Re: pfind_locked(pid) fails when in a jail? Thread-Topic: pfind_locked(pid) fails when in a jail? Thread-Index: AQHTRsy4PlPkoH+r1k6i+VZl2ipOV6LnEU+AgAALmQCAAAVwgIAABEed Date: Tue, 17 Oct 2017 00:08:15 +0000 Message-ID: References: <1508195986.74236.6.camel@freebsd.org>, <20171016233912.7n6rosak5a5tzcbz@mguzik> In-Reply-To: <20171016233912.7n6rosak5a5tzcbz@mguzik> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1308; 6:O00Du9ou5r+guMPMcmVEPdzXL6h/vjYVHi6uhoQrhUekz3GqNl01d2WsM1oJCQouncyhoN1NBe4XnD0kDoti5ZU0mq0L9F6cPLy4LbczEoOFqevGmTQNBICqmFjTOH4MvTg0y1TFeYCxEWLca460wIfAEIszux+agPn4g8vSyfIxu3EH1DKPs7g6LKa0KKuV/U68xIlGpmZtgyCYnrkkeEAgyheAb6k4wC65ZF07r/AbLsCs7QDWZF0H/0ld3IQJfbnzchfwKCNACNZ+1Pa3X0KTE3VAl6cddEAhMNxnMevB/U9xhdpxMHn7OKz13NeFVe30bNvp+jrBh8aBaQEyQQ==; 5:TArJMld1hSaBPpI+RVFaVQKC9TSvGERBXadXjtcm204KiHMacVtoNkzH2+jcH58xGk6ox9Y8GoL6/6R66MBO3UB0f4dLidhiLc16R5hNnTNYzbp7eM7vGgUsfCfWEVqT1/FYTGlR/bcTbnvBmpWq+azSvKrR+ZtcFWhG9SIJBOA=; 24:b34n+p5a8e4JlM88TIvd59ek0R6IMiS90k9g69T0dsn/ww5amgZdDRPbWS4w/GnVWhBmjZjLeL1yHN3HIy/jL8rfrKCMR1BQQGTRVm42moo=; 7:13gPX1Kpqh0TREEDgi8wPlFvsF58v6tDjU2OFAyMoHCoWMhgDo48f0IUJYIqvv0rVZbicw1NAmaL4l1xEz0owiv3vetlBvNy/c259UKOaKh44LtYwcuyvBegrN+agD82WMBXRrp/65KMgQ9wIESUiPCa8qCfQw4GKXBnmzdIiP8U9Fc8eDn7ZStmOTfbzENUuxKU4Okd2tZiohKlTVaYefW6OVt99fyqgsT1xsy09ks= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e3c577b0-abf9-4477-06e3-08d514f329b8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YTOPR0101MB1308; x-ms-traffictypediagnostic: YTOPR0101MB1308: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTOPR0101MB1308; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTOPR0101MB1308; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(189002)(199003)(51914003)(8676002)(102836003)(189998001)(2950100002)(2900100001)(6506006)(25786009)(74482002)(68736007)(50986999)(39060400002)(229853002)(54356999)(76176999)(101416001)(81156014)(81166006)(97736004)(6436002)(7696004)(5660300001)(8936002)(14454004)(4326008)(478600001)(305945005)(55016002)(105586002)(74316002)(5250100002)(6246003)(9686003)(86362001)(93886005)(53936002)(54906003)(316002)(33656002)(3280700002)(106356001)(786003)(2906002)(110136005)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1308; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 00:08:15.2015 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1308 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 00:08:17 -0000 [stuff snipped] > > > > > pfind* does not do any filtering. > > Hmm, well I have no idea why the jailed mounts get looping in here then. > > The real question though is why are you calling it in the first place. = The > > calls > > I grepped in nfscl_procdoesntexist are highly suspicious - there is no > > guarantee > > the process you found here is the same you had at the time you were sav= ing > > the pid. > > Long long ago (about 2002) this code was written for OpenBSD2.6. I added a call from the kernel exit() code to do this. When I ported it to FreeBSD around 2005, I didn't find any way for a process exit notification to be do= ne, so I created the first version of this code. (This way of doing it was firs= t coded for Mac OS X 10.3, if I recall correctly.) Since it does check that the time of process creation is the same, it doesn= 't seem likely that it would find a different process (ie. two processes with = the same pid that were created at the same time within the clock resolution of that creation time seems highly unlikely in practice?). > > There is no usable process exit notification right now, but it can be a= dded > > if necessary. > > If there was a way for the NFS client to register to get a notification tha= t a given process is terminating (exit'ng), that could certainly be used instea= d of this code. I wouldn't want a call for every exit(), but only the ones that have NFSv4 = opens. >> >> Does that mean there is something wrong with the existing eventhandler >> notifications related to proc fork/exec/exit? >> > >I already noted in the other mail that the current mechanism has >avoidable global locking, lists traversals etc. But even with these >issues fixed it calls everything for everyone. > >What's needed is a mechanism to register per-process callbacks. Details >can be flamed over (e.g. should it require allocating a buffer per >process or perhaps just one and then point to it from a resizable >per-proc table when registered), but calling something which has nothing >to do in almost all cases and from in a super inefficient way at that is >definitely something we need to start cleaning up. Yes, I would agree, although it doesn't explain what this CPU hog case is caused by. Thanks for the comments and if you create/commit the above, let me know and I'll change the NFS client code to use it (if your patch doesn't do tha= t). rick From owner-freebsd-current@freebsd.org Tue Oct 17 00:12:56 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00FEFE49584 for ; Tue, 17 Oct 2017 00:12:56 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78801734BE for ; Tue, 17 Oct 2017 00:12:54 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v9H0DMlE036597 for ; Mon, 16 Oct 2017 17:13:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: Is there an RTC prejudice? Date: Mon, 16 Oct 2017 17:13:28 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <0f019102c38d089d28510c75f3450349@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 00:12:56 -0000 While I haven't [yet] experienced this problem. A bug[1] just came in on the amd64 list that is over a *year old*, and there are several individuals involved. As well as several [freebsd] versions. So I thought I'd raise the issue here. In case someone(tm) thinks they know what's wrong/ what to do. 1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207677 --Chris From owner-freebsd-current@freebsd.org Tue Oct 17 06:17:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 001AEE2E5A8 for ; Tue, 17 Oct 2017 06:17:30 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [213.239.241.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B943E864; Tue, 17 Oct 2017 06:17:30 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [IPv6:2001:470:25:233:e0d6:b7ed:5952:4c9d] (unknown [IPv6:2001:470:25:233:e0d6:b7ed:5952:4c9d]) by host64.shmhost.net (Postfix) with ESMTPSA id 0A30D160856; Tue, 17 Oct 2017 08:17:24 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: cve-2017-13077 - WPA2 security vulni From: Franco Fichtner In-Reply-To: <20171016223231.923A0191@spqr.komquats.com> Date: Tue, 17 Oct 2017 08:17:22 +0200 Cc: "Rodney W. Grimes" , Kevin Oberman , Adrian Chadd , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171016223231.923A0191@spqr.komquats.com> To: Cy Schubert X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at host64.shmhost.net X-Virus-Status: Clean X-Spam-Flag: NO X-Spam-Score: -1.0 X-Spam-Status: No score=-1.0 tagged_above=10.0 required=10.0 tests=[ALL_TRUSTED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 06:17:31 -0000 > On 17. Oct 2017, at 12:32 AM, Cy Schubert = wrote: >=20 > I'll test it when I get home tonight. The WiFi here at the tech park = is open so, I couldn't test here. Tested: hostapd 2.6_1 wpa_supplicant 2.6_2 No apparent issues with the ports, preliminary connectivity checks work as expected. Started a public CFT over at OPNsense to gather more feedback. Cheers, Franco= From owner-freebsd-current@freebsd.org Tue Oct 17 06:27:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4BF2E2EABA for ; Tue, 17 Oct 2017 06:27:05 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AAD5AE3F; Tue, 17 Oct 2017 06:27:05 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4LLAee64Y8LPZ4LLBefkS2; Tue, 17 Oct 2017 00:27:04 -0600 X-Authority-Analysis: v=2.2 cv=e552ceh/ c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=02M-m0pO-4AA:10 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=7S0vsDYvbZ0Ny6_31y0A:9 a=CjuIK1q_8ugA:10 a=pxhY87DP9d2VeQe4joPk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id A52F73F5; Mon, 16 Oct 2017 23:27:00 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v9H6R0XC078179; Mon, 16 Oct 2017 23:27:00 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201710170627.v9H6R0XC078179@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Franco Fichtner cc: Cy Schubert , "Rodney W. Grimes" , Kevin Oberman , Adrian Chadd , Lev Serebryakov , blubee blubeeme , Poul-Henning Kamp , FreeBSD current Subject: Re: cve-2017-13077 - WPA2 security vulni In-Reply-To: Message from Franco Fichtner of "Tue, 17 Oct 2017 08:17:22 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Oct 2017 23:27:00 -0700 X-CMAE-Envelope: MS4wfJQR6KzX0msSVfAAyaWrI5FrtNSSy5m9iVAZh65tDsGL7SQ/fCQGWitqxbjia6P+hxsOWRHrvScjipkGQTJDBwFjTnAkJN245FMHg1wYVdkanCNXEJe6 RX3KGHVTnsVTt1c9YjxftZEazL4TjPNrsYlgesaauhi6WTvyN6UmO47gJAPj9w8JyXpSKaadGYooXiMv6bdukZJwhffH6BVxZn8Cv/dAiAfbQYz7KpH+RBnY 9++2MreC87fPFSE1rzDskPZENThi5UK+rkc3h9hPqh7Z8gT9IbvvXDv3mDNrHh+1eJqw/YxXZgZLAYnCVnTsM84seSu6IJvyZ4oT0rXDk3SKJgHkNfcHN+JU YN+p58zy/1clEMkIG/Qzbj2gGoIKpgjIt2TKQN/lrH2WMInjKIKtD70x8Cl3TcHjJfZ/FCTM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 06:27:06 -0000 In message , Franco Fichtne r writes: > > > > On 17. Oct 2017, at 12:32 AM, Cy Schubert wrote: > > > > I'll test it when I get home tonight. The WiFi here at the tech park is ope > n so, I couldn't test here. > > Tested: > > hostapd 2.6_1 > wpa_supplicant 2.6_2 > > No apparent issues with the ports, preliminary connectivity > checks work as expected. Started a public CFT over at OPNsense > to gather more feedback. Agreed. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Tue Oct 17 12:58:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A605E39CB5 for ; Tue, 17 Oct 2017 12:58:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E63E96BD2D for ; Tue, 17 Oct 2017 12:58:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id E23B7E39CB4; Tue, 17 Oct 2017 12:58:37 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF953E39CB3 for ; Tue, 17 Oct 2017 12:58:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A88BB6BD2C for ; Tue, 17 Oct 2017 12:58:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v9HCwUmE035994; Tue, 17 Oct 2017 12:58:30 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v9HCwT8C035993; Tue, 17 Oct 2017 05:58:29 -0700 (PDT) (envelope-from david) Date: Tue, 17 Oct 2017 05:58:29 -0700 From: David Wolfskill To: Cy Schubert Cc: current@freebsd.org Subject: Re: cve-2017-13077 - WPA2 security vulni Message-ID: <20171017125829.GA35718@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Cy Schubert , current@freebsd.org References: <201710170627.v9H6R0XC078179@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <201710170627.v9H6R0XC078179@slippy.cwsent.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 12:58:38 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 16, 2017 at 11:27:00PM -0700, Cy Schubert wrote: > In message , Franco= =20 > Fichtne > r writes: > ... > > wpa_supplicant 2.6_2 > >=20 > > No apparent issues with the ports, preliminary connectivity > > checks work as expected. Started a public CFT over at OPNsense > > to gather more feedback. >=20 > Agreed. > .... First: Thank you for doing this, Cy. I am now (also) running wpa_supplicant-2.6_2 successfully on my laptop (when it's running stable/11). I did have one mild surprise: I had rebooted my laptop to verify that the ports version of wpa_supplicant would work, and as the screen went dark, I recalled that I had failed to copy /etc/wpa_supplicant.conf to /usr/local/etc -- but my concern proved to be unfounded: the wpa_supplicant.conf in /etc/ was used (successfully). Question: Should one expect a wpa_supplicant-2.6_2 executable built under FreeBSD stable/11 (amd64) to work on the same hardware, but running head? For reasons that are (at best) tangential to this topic, I track, build, and smoke-test both stable/11 and head daily, but only build the ports (daily) under (the just-built/booted) stable/11 -- depending on misc/compat11 to handle things as necessary for head. This works (well, IMO)... except that when I had configured my "head slice" to use the ports version of wpa_supplicant, the latter was apparently not happy: =2E.. Oct 17 11:06:13 localhost kernel: wlan0: Ethernet address: 00:24:d6:7a:03:ce Oct 17 11:06:13 localhost wpa_supplicant[1279]: Successfully initialized wp= a_supplicant Oct 17 11:06:14 localhost wpa_supplicant[1279]: ioctl[SIOCS80211, op=3D98, = arg_len=3D32]: Invalid argument Oct 17 11:06:14 localhost wpa_supplicant[1279]: failed to IEEE80211_IOC_DEV= CAPS: Invalid argument Oct 17 11:06:14 localhost wpa_supplicant[1279]: wlan0: Failed to initialize= driver interface Oct 17 11:06:14 localhost root: /etc/rc.d/wpa_supplicant: WARNING: failed t= o start wpa_supplicant =2E... The laptop spends the vast bulk of its time running stable/11, so the threat is somewhat mitigated.... Peace, david --=20 David H. Wolfskill david@catwhisker.org Unsubstantiated claims of "Fake News" are evidence that the claimant lies a= gain. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZ5f51XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XNRoH/AxKFiZVa4VjdZGxr5yoQMTb otM1rqAEw63zQDV/KVibjT5y5RtCFsR4EIjq4rVU/6Z9Vl4JwXiScfE4+plw5vOk RXhtfShUbCMzaRSkN3EyWWtg9CVR0ysjXFDGsfnRJSwwwWtiOpa8EJ68V4THRyw/ KrQDGjhkNla6WjVI0EczmNQ/UF1SKprQ2eBqgeQ7LbeFMGTMtrYggN15h7QU+EpD 36Rp6vqsbAzeo8UZoTVHgRwFyYYBIA8bb3mTdH//ob856LFwN7lCU66oIYgr1Fq5 nuq3Lk6wjt6FzekjHRQUThKYjOIGV32Avx4uQtVP0b2DcTMKgbYm/o3aXmPuVq8= =5ujC -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@freebsd.org Tue Oct 17 13:19:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 347D6E3A4B2 for ; Tue, 17 Oct 2017 13:19:15 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 173786CAB3 for ; Tue, 17 Oct 2017 13:19:15 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: by mailman.ysv.freebsd.org (Postfix) id 13595E3A4B1; Tue, 17 Oct 2017 13:19:15 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12FC7E3A4AF for ; Tue, 17 Oct 2017 13:19:15 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA5586CAB2 for ; Tue, 17 Oct 2017 13:19:14 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4RlyeZZRQM9gt4Rlzers81; Tue, 17 Oct 2017 07:19:08 -0600 X-Authority-Analysis: v=2.2 cv=a+JAzQaF c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=02M-m0pO-4AA:10 a=JAf30KXuAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=O0oC2_XnyK8vZQgHNRMA:9 a=CjuIK1q_8ugA:10 a=GEL62FyrTCmHtEug2d3R:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 26837150; Tue, 17 Oct 2017 06:19:06 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v9HDJ5QI004672; Tue, 17 Oct 2017 06:19:05 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201710171319.v9HDJ5QI004672@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: David Wolfskill , Cy Schubert , current@freebsd.org Subject: Re: cve-2017-13077 - WPA2 security vulni In-Reply-To: Message from David Wolfskill of "Tue, 17 Oct 2017 05:58:29 -0700." <20171017125829.GA35718@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Oct 2017 06:19:05 -0700 X-CMAE-Envelope: MS4wfMF3n041CWyUKXi4S68R1yw9VFIivN6dyC1x5q4t8dn2lqhPnvd/Tv7se6F/7Z+UNsk+TxmeBpsYy8l2pBj22TaQXYKTnm3WifgJvriYVKFf0pm855Lw QfLopnoItGZJUzUjHPAkIRVUjHw4sYJooDYz4ryRY/NaHGUHgD4M5M6up942qTmrbiBJrJROSgUPoYaoERGGjrmjhxYwo1DvCeA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 13:19:15 -0000 In message <20171017125829.GA35718@albert.catwhisker.org>, David Wolfskill writ es: > > > --azLHFNyN32YCQGCU > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Oct 16, 2017 at 11:27:00PM -0700, Cy Schubert wrote: > > In message , Franco= > =20 > > Fichtne > > r writes: > > ... > > > wpa_supplicant 2.6_2 > > >=20 > > > No apparent issues with the ports, preliminary connectivity > > > checks work as expected. Started a public CFT over at OPNsense > > > to gather more feedback. > >=20 > > Agreed. > > .... > > First: Thank you for doing this, Cy. No problem. I was aiming to put something together in base but an hour at noon wasn't enough so I switched gears and went after the port instead. It was a quick win. > > I am now (also) running wpa_supplicant-2.6_2 successfully on my laptop > (when it's running stable/11). > > I did have one mild surprise: I had rebooted my laptop to verify that > the ports version of wpa_supplicant would work, and as the screen went > dark, I recalled that I had failed to copy /etc/wpa_supplicant.conf to > /usr/local/etc -- but my concern proved to be unfounded: the > wpa_supplicant.conf in /etc/ was used (successfully). > > Question: Should one expect a wpa_supplicant-2.6_2 executable built > under FreeBSD stable/11 (amd64) to work on the same hardware, but > running head? Possibly. I run head here. The things that could impact you are shared libraries (ABI) and KBI. > > For reasons that are (at best) tangential to this topic, I track, > build, and smoke-test both stable/11 and head daily, but only build > the ports (daily) under (the just-built/booted) stable/11 -- depending > on misc/compat11 to handle things as necessary for head. This works > (well, IMO)... except that when I had configured my "head slice" > to use the ports version of wpa_supplicant, the latter was apparently > not happy: > > =2E.. > Oct 17 11:06:13 localhost kernel: wlan0: Ethernet address: 00:24:d6:7a:03:ce > Oct 17 11:06:13 localhost wpa_supplicant[1279]: Successfully initialized wp= > a_supplicant > Oct 17 11:06:14 localhost wpa_supplicant[1279]: ioctl[SIOCS80211, op=3D98, = > arg_len=3D32]: Invalid argument > Oct 17 11:06:14 localhost wpa_supplicant[1279]: failed to IEEE80211_IOC_DEV= > CAPS: Invalid argument > Oct 17 11:06:14 localhost wpa_supplicant[1279]: wlan0: Failed to initialize= > driver interface > Oct 17 11:06:14 localhost root: /etc/rc.d/wpa_supplicant: WARNING: failed t= > o start wpa_supplicant You have your answer. It's likely a KBI issue. > =2E... > > The laptop spends the vast bulk of its time running stable/11, so > the threat is somewhat mitigated.... It appears you may need to in some cases rebuild some ports on head. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Tue Oct 17 15:51:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33302E3DF03 for ; Tue, 17 Oct 2017 15:51:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C08CC71BA7 for ; Tue, 17 Oct 2017 15:51:37 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0c389527-b353-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 0c389527-b353-11e7-a893-25625093991c; Tue, 17 Oct 2017 15:51:34 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9HFpSds003738; Tue, 17 Oct 2017 09:51:28 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508255488.74236.29.camel@freebsd.org> Subject: Re: pfind_locked(pid) fails when in a jail? From: Ian Lepore To: Rick Macklem , Mateusz Guzik Cc: "freebsd-current@freebsd.org" , "fabian.freyer@physik.tu-berlin.de" Date: Tue, 17 Oct 2017 09:51:28 -0600 In-Reply-To: References: <1508195986.74236.6.camel@freebsd.org> , <20171016233912.7n6rosak5a5tzcbz@mguzik> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 15:51:38 -0000 On Tue, 2017-10-17 at 00:08 +0000, Rick Macklem wrote: > [stuff snipped] > > > > > > > > > > > > > > > > pfind* does not do any filtering. > > > > Hmm, well I have no idea why the jailed mounts get looping in here then. > > > > > > > > > The real question though is why are you calling it in the first place. The > > > calls > > > I grepped in nfscl_procdoesntexist are highly suspicious - there is no > > > guarantee > > > the process you found here is the same you had at the time you were saving > > > the pid. > > > > Long long ago (about 2002) this code was written for OpenBSD2.6. I added > a call from the kernel exit() code to do this. When I ported it to FreeBSD > around 2005, I didn't find any way for a process exit notification to be done, > so I created the first version of this code. (This way of doing it was first > coded for Mac OS X 10.3, if I recall correctly.) > > Since it does check that the time of process creation is the same, it doesn't > seem likely that it would find a different process (ie. two processes with the > same pid that were created at the same time within the clock resolution of > that creation time seems highly unlikely in practice?). > > > > > > > > > There is no usable process exit notification right now, but it can be added > > > if necessary. > > > > If there was a way for the NFS client to register to get a notification that a > given process is terminating (exit'ng), that could certainly be used instead > of this code. > > I wouldn't want a call for every exit(), but only the ones that have NFSv4 opens. > > > > > > > > > > > > Does that mean there is something wrong with the existing eventhandler > > > notifications related to proc fork/exec/exit? > > > > > I already noted in the other mail that the current mechanism has > > avoidable global locking, lists traversals etc. But even with these > > issues fixed it calls everything for everyone. > > All of that locking-and-lookup overhead in the event notification system is already happening on every process exit, whether anyone has registered an event handler or not.  If you want to actually avoid the avoidable overheads, the answer is to fix the existing code, not create another new mechanism that adds more overhead without addressing the existing problem.  I suspect the worst of the existing overhead can be eliminated with some fairly small changes, and I hope to find time to look at it later this week. On the issue of filtering the callbacks to just the exits you're interested in... it doesn't seem any better to me to do the filtering at the source unless there are multiple registered handlers at once that all need the same filtering.  How many different things in the kernel would want process-exit filtering based on "have NFSv4 opens"?  That seems like a single-consumer kind of filter. -- Ian > > What's needed is a mechanism to register per-process callbacks. Details > > can be flamed over (e.g. should it require allocating a buffer per > > process or perhaps just one and then point to it from a resizable > > per-proc table when registered), but calling something which has nothing > > to do in almost all cases and from in a super inefficient way at that is > > definitely something we need to start cleaning up. > Yes, I would agree, although it doesn't explain what this CPU hog case is > caused by. > > Thanks for the comments and if you create/commit the above, let me know > and I'll change the NFS client code to use it (if your patch doesn't do that). > > rick > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd > .org" From owner-freebsd-current@freebsd.org Tue Oct 17 15:57:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2512E3E60F for ; Tue, 17 Oct 2017 15:57:37 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from oleg.opentransfer.com (oleg.opentransfer.com [91.217.144.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oleg-10.opentransfer.com", Issuer "oleg-10.opentransfer.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 74586725CB for ; Tue, 17 Oct 2017 15:57:36 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from asus.theweb.org.ua ([10.0.8.4]) by oleg.opentransfer.com (8.15.2/8.15.2) with ESMTPS id v9HFjsLA040097 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 17 Oct 2017 18:45:57 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id v9HFdGa8038531 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 17 Oct 2017 18:39:16 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id v9HFdFvu038530 for freebsd-current@freebsd.org; Tue, 17 Oct 2017 18:39:15 +0300 (EEST) (envelope-from oleg@theweb.org.ua) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@theweb.org.ua using -f From: "Oleg V. Nauman" To: FreeBSD current Subject: r324684 amd64 buildworld failed if WITHOUT_ZFS is defined Date: Tue, 17 Oct 2017 18:39:15 +0300 Message-ID: <2171992.V117Jz80mZ@asus.theweb.org.ua> Organization: Private person User-Agent: KMail/4.14.10 (FreeBSD/12.0-CURRENT; KDE/4.14.30; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 15:57:38 -0000 ===> sys/boot/efi/boot1 (all) cc -target x86_64-unknown-freebsd12.0 -- sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -ffreestanding -Wformat -mno-mmx -mno-sse -mno-avx -msoft- float -fshort-wchar -mno-red-zone -mno-aes -march=nehalem - DLOADER_UFS_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT - DLOADER_MBR_SUPPORT -DLOADER_GELI_SUPPORT - I/usr/src/sys/boot/libsa -I/usr/src/sys/boot/common -I. - I/usr/src/sys/boot/efi/boot1/../include - I/usr/src/sys/boot/efi/boot1/../include/amd64 - I/usr/src/sys/boot/efi/boot1/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/efi/boot1/../../.. -DEFI_UFS_BOOT - I/usr/src/sys/boot/efi/boot1/../../common -fPIC -ffreestanding - Wformat -mno-mmx -mno-sse -mno-avx -msoft-float -fshort-wchar - mno-red-zone -mno-aes -g -MD -MF.depend.boot1.o -MTboot1.o - std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W - Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes - Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty- body -Wno-string-plus-int -Wno-unused-const-variable -Wno- tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local- typedef -Wno-address-of-packed-member -Wno-format -Qunused- arguments -c /usr/src/sys/boot/efi/boot1/boot1.c -o boot1.o /usr/src/sys/boot/efi/boot1/boot1.c:269:1: error: no previous prototype for function 'efi_zfs_is_preferred' [-Werror,-Wmissing-prototypes] efi_zfs_is_preferred(EFI_HANDLE *h) ^ /usr/src/sys/boot/efi/boot1/boot1.c:381:2: error: unknown type name 'zfsinfo_list_t'; did you mean 'pdinfo_list_t'? zfsinfo_list_t *zfsi_list; ^~~~~~~~~~~~~~ pdinfo_list_t /usr/src/sys/boot/efi/boot1/../include/efilib.h:49:42: note: 'pdinfo_list_t' declared here typedef STAILQ_HEAD(pdinfo_list, pdinfo) pdinfo_list_t; ^ /usr/src/sys/boot/efi/boot1/boot1.c:382:2: error: use of undeclared identifier 'zfsinfo_t' zfsinfo_t *zi; ^ /usr/src/sys/boot/efi/boot1/boot1.c:382:13: error: use of undeclared identifier 'zi' zfsinfo_t *zi; ^ 4 errors generated. *** Error code 1 Stop. make[6]: stopped in /usr/src/sys/boot/efi/boot1 *** Error code 1 From owner-freebsd-current@freebsd.org Tue Oct 17 15:57:52 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEB37E3E6B0 for ; Tue, 17 Oct 2017 15:57:51 +0000 (UTC) (envelope-from david.boyd49@twc.com) Received: from dnvrco-cmomta02.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 97D7072643 for ; Tue, 17 Oct 2017 15:57:51 +0000 (UTC) (envelope-from david.boyd49@twc.com) Received: from bashful.bsd1.net ([74.138.140.144]) by cmsmtp with ESMTPA id 4UFWe136okl5s4UFZe4nRE; Tue, 17 Oct 2017 15:57:49 +0000 Message-ID: <1508255864.5659.3.camel@twc.com> Subject: VM images for 12.0-CURRENT showing checksum failed messages From: David Boyd To: freebsd-current@freebsd.org Date: Tue, 17 Oct 2017 11:57:44 -0400 X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 X-CMAE-Envelope: MS4wfKt2vHj3h7/2tNPzPJTncbzdaJwNb06TRW9oviRlbiBlj+xRZZYpM0t7elqcRYeQ1BV7ZWCfoVFDqR//BLNywPskiDeklEA30jz5xZLm9KR2ENMdjrK4 QYQz8Id5odvnfPKnwTA5nm4K2oHndan8H/T/vNfwytw2XVOr50auONq56qnq9TfeE4Zs/H1gwiongQ== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 15:57:52 -0000 The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays many checksum failed messages when booted. (see attachment). I think this started about 20170925. I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- CURRENT. Only the 12.0-CURRENT image exhibits this behavior. This is easily fixed by "fsck -y /" in single-user mode during the boot process. I can test any updates at almost any time. Thanks. David Boyd. From owner-freebsd-current@freebsd.org Tue Oct 17 16:51:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42856E401C2 for ; Tue, 17 Oct 2017 16:51:29 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1746374E4C for ; Tue, 17 Oct 2017 16:51:28 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 36E691362D for ; Tue, 17 Oct 2017 16:51:27 +0000 (UTC) Subject: Re: cve-2017-13077 - WPA2 security vulni To: freebsd-current@freebsd.org References: <201710170627.v9H6R0XC078179@slippy.cwsent.com> <20171017125829.GA35718@albert.catwhisker.org> From: Allan Jude Message-ID: Date: Tue, 17 Oct 2017 12:51:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171017125829.GA35718@albert.catwhisker.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eK19BdBQ59M6ON7iOddLqHwhgGosurMKI" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:51:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eK19BdBQ59M6ON7iOddLqHwhgGosurMKI Content-Type: multipart/mixed; boundary="EtxxLtbolBMdxM0XkeGK7Rr3ip4p3nm34"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: Subject: Re: cve-2017-13077 - WPA2 security vulni References: <201710170627.v9H6R0XC078179@slippy.cwsent.com> <20171017125829.GA35718@albert.catwhisker.org> In-Reply-To: <20171017125829.GA35718@albert.catwhisker.org> --EtxxLtbolBMdxM0XkeGK7Rr3ip4p3nm34 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2017-10-17 08:58, David Wolfskill wrote: > On Mon, Oct 16, 2017 at 11:27:00PM -0700, Cy Schubert wrote: >> In message , Franc= o=20 >> Fichtne >> r writes: >> ... >>> wpa_supplicant 2.6_2 >>> >>> No apparent issues with the ports, preliminary connectivity >>> checks work as expected. Started a public CFT over at OPNsense >>> to gather more feedback. >> >> Agreed. >> .... >=20 > First: Thank you for doing this, Cy. >=20 > I am now (also) running wpa_supplicant-2.6_2 successfully on my laptop > (when it's running stable/11). >=20 > I did have one mild surprise: I had rebooted my laptop to verify that > the ports version of wpa_supplicant would work, and as the screen went > dark, I recalled that I had failed to copy /etc/wpa_supplicant.conf to > /usr/local/etc -- but my concern proved to be unfounded: the > wpa_supplicant.conf in /etc/ was used (successfully). >=20 > Question: Should one expect a wpa_supplicant-2.6_2 executable built > under FreeBSD stable/11 (amd64) to work on the same hardware, but > running head? Did you run the version from ports, or did you run the base /etc/rc.d script with your rc.conf set to point to the ports binary? This will run the command with -c /etc/wpa_supplicant.conf overriding the ports default= =2E So this is expected to work in this way. >=20 > For reasons that are (at best) tangential to this topic, I track, > build, and smoke-test both stable/11 and head daily, but only build > the ports (daily) under (the just-built/booted) stable/11 -- depending > on misc/compat11 to handle things as necessary for head. This works > (well, IMO)... except that when I had configured my "head slice" > to use the ports version of wpa_supplicant, the latter was apparently > not happy: >=20 > ... > Oct 17 11:06:13 localhost kernel: wlan0: Ethernet address: 00:24:d6:7a:= 03:ce > Oct 17 11:06:13 localhost wpa_supplicant[1279]: Successfully initialize= d wpa_supplicant > Oct 17 11:06:14 localhost wpa_supplicant[1279]: ioctl[SIOCS80211, op=3D= 98, arg_len=3D32]: Invalid argument > Oct 17 11:06:14 localhost wpa_supplicant[1279]: failed to IEEE80211_IOC= _DEVCAPS: Invalid argument > Oct 17 11:06:14 localhost wpa_supplicant[1279]: wlan0: Failed to initia= lize driver interface > Oct 17 11:06:14 localhost root: /etc/rc.d/wpa_supplicant: WARNING: fail= ed to start wpa_supplicant > .... >=20 > The laptop spends the vast bulk of its time running stable/11, so > the threat is somewhat mitigated.... >=20 > Peace, > david >=20 --=20 Allan Jude --EtxxLtbolBMdxM0XkeGK7Rr3ip4p3nm34-- --eK19BdBQ59M6ON7iOddLqHwhgGosurMKI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJZ5jUOAAoJEBmVNT4SmAt+q1gP/1utXEHU724BU4WhOvNVIxku 49hvI6tnlAlyAy+xh6Ik+bKkUK49MLCswu3yPrxnJHw3f/MWLzjyBJLoCZYI/c11 SFcK5aMT5+sYgVXTtuBvmV/uROdt4yUoFmOQCScg7FWKgrhO4uqs3t7ObmY3/jcq 4aivB1mDD+Yq0TZHsxuH+BtIW+pfOw6aF3iHEgM0EEviAeSqShkJAwqRB59bL3E0 GU7fs8KfXALrb5hILBcD3Z0VSuPaL+cMfhficB4qHwcEXfkhV0ZWGhvkjF6b3pfS bYtnx2uJLqjv/r+DH+7dvdRUi5RcnOe8oJW/RgNIh9DdWQabyYvrRM+YltudXpUv IuAfJp4xn0mGGCqR/8CKocRCuIj0fqFanKSsVL8VW3U3Vq3GRVYBgqHNqbeSDfLw ZVOemMFkfeImpMS063imAiJUIgvId9GT6q5GugnRGQKGHpZMAgk4l2G+MlSGUGps ggCykny5cSwUkcacWVRDJRsa3I+r7tDlD1Cm30102g5toXcgQShBvtPYQ21bTHHK ProfI0q5xd/2YptJNP0XAfUHSa9by0LJ30Nsvh4sFxQ/x6BOUWMRN6xFVdGNnbpp g2X9EQbLFqhCkh38JS3Hudk/iA3a+YOn+eUn2nJKEcKcl6dIS1xtqtSeqp4zD0Xk nQ8joWljq2SNqAqvUIlF =4xMP -----END PGP SIGNATURE----- --eK19BdBQ59M6ON7iOddLqHwhgGosurMKI-- From owner-freebsd-current@freebsd.org Tue Oct 17 16:57:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEE36E4030D for ; Tue, 17 Oct 2017 16:57:10 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61679750BB; Tue, 17 Oct 2017 16:57:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v9HGv8aG038280; Tue, 17 Oct 2017 16:57:08 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v9HGv8ie038279; Tue, 17 Oct 2017 09:57:08 -0700 (PDT) (envelope-from david) Date: Tue, 17 Oct 2017 09:57:08 -0700 From: David Wolfskill To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: cve-2017-13077 - WPA2 security vulni Message-ID: <20171017165708.GE1214@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Allan Jude , freebsd-current@freebsd.org References: <201710170627.v9H6R0XC078179@slippy.cwsent.com> <20171017125829.GA35718@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="35iEUiFini4fM4u+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:57:10 -0000 --35iEUiFini4fM4u+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 17, 2017 at 12:51:23PM -0400, Allan Jude wrote: > .... > > Question: Should one expect a wpa_supplicant-2.6_2 executable built > > under FreeBSD stable/11 (amd64) to work on the same hardware, but > > running head? >=20 > Did you run the version from ports, or did you run the base /etc/rc.d > script with your rc.conf set to point to the ports binary? This will run > the command with -c /etc/wpa_supplicant.conf overriding the ports default. >=20 > So this is expected to work in this way. Ah. When I installed the port, I was reminded: | ... | =3D=3D=3D> Registering installation for wpa_supplicant-2.6_2 | Installing wpa_supplicant-2.6_2... | To use the ports version of WPA Supplicant instead of the base, add: |=20 | wpa_supplicant_program=3D"/usr/local/sbin/wpa_supplicant" |=20 | to /etc/rc.conf |=20 | =3D=3D=3D> SECURITY REPORT: | .... So I did that. I did not do anything to the existing /etc/rc.d/wpa_supplicant, which had been installed as part of base FreeBSD. > .... Peace, david --=20 David H. Wolfskill david@catwhisker.org Unsubstantiated claims of "Fake News" are evidence that the claimant lies a= gain. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --35iEUiFini4fM4u+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZ5jZkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XQMMIAMjmrQKcCS5PeKI5CecWrePm vtfFu8l4T+5z31+qJv/7jPPmwNR14tWljgm0VoYI3/lIjP2R+6/dixRfDXA1ZLP8 uTHZIGDV1pGdViAa11Iq+VoY3bOYFdh5b4d6x5aqOes4NE/T7qz00wvYc0Ax71im 9Ix7A2eCIivz+aVARZfLCvaB9+0NfWOmpJCJ8YYRhihGbJrwsNliNuJHG/bXIncA Bgi81dOIhKwwo3HYyZHemyFqPJ8rnMseLbjEqUEIo/K/yJENi3XwosfFGSAgMn27 L6OnbLe/09YMyResOCv4/J48Awprl70/7XcIkKp2a02QzvDzV8XrC8ep0DjGJck= =59Ld -----END PGP SIGNATURE----- --35iEUiFini4fM4u+-- From owner-freebsd-current@freebsd.org Tue Oct 17 17:47:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50F07E41B01; Tue, 17 Oct 2017 17:47:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0592777485; Tue, 17 Oct 2017 17:47:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ua0-x22b.google.com with SMTP id n22so1754620uaj.13; Tue, 17 Oct 2017 10:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=/WSqo2HD5t05nfvW4QuQT+j3ZL6qkk85z0PvtXZTQsE=; b=L4EH3GtV2mOLGhW2FDEheYggGhAvk/mgGiyrE05Dtj0ni0pmjCIR3kEe8I2kQJ+vRX 64v+/zVAc+QI+GjQf9x6/IaX0E3IqN5sz+oLGtns6iWfldog5mIlTfzmwr2P/Nn34Y0n m+Bm/wYTp1JzTJlG9xTpOKFsuuSUIU9Ws0e+uS75OHJTXAWcSQV9/UIkIuAJlmjGNObk Cv+HXP8dvUjo26CfgzeyTeow7afoPeGNmwx/fNUv7+KD4A6f4mCjjR6054G7anUJ3/ti bMUQAPmVqzxe4UBd3p7ODJJe/EpNweFucbLgGG4J1t4Eo2ZHoMvJ/6NitXC2miLFHOrl GhEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=/WSqo2HD5t05nfvW4QuQT+j3ZL6qkk85z0PvtXZTQsE=; b=cekfhmele6kh1XaRiW7mA1XaBujMx+uSH1snzBvkSHQBaMbCP06p4JLEFoIzAZGC/C sItXNpaLfgmBVNAMKCbDqt4l9xXbvnOdFt7YPgjy8u5vcEX+iVFqugGSKClfyjp4yJ81 m975y31xu7PX4Kj6cyFH9g/i5+q4yGdTSAgTELSPMEu32Gu+XHlI1qnTHoCl0HsVXzxY 1Ntd+0/tPOGYcXSsiH3xxhJZosLHsdNqIUEZABEP3+MuxKp/JJgOardJJjIEQ0dHRDfi 2Sg/K5wDywRepi/I3PEBwiIz/fTtslckVwZeCrY+w98a7nIsjynhRPwUALgjVW+C0JaO YQyA== X-Gm-Message-State: AMCzsaU5b3BnR2zZVNh1BszpDk3umEX7VX1HdZEgULXEY6jxiQQlmNoY XwUZ5ik/WFWusTbhs/EBnUWrAJD8k/1BbOFPeYcQFUBL X-Google-Smtp-Source: AOwi7QDhNwin/aB/lzj4qE0a1DU4L8Pjtm+ooOavPtQfQMbafi8QkP228hvw0u+2rj3Li01xonsE7F8P2d0+agNZ5PQ= X-Received: by 10.176.27.108 with SMTP id n44mr10599633uai.47.1508262461830; Tue, 17 Oct 2017 10:47:41 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.85.8 with HTTP; Tue, 17 Oct 2017 10:47:41 -0700 (PDT) In-Reply-To: <20171017165708.GE1214@albert.catwhisker.org> References: <201710170627.v9H6R0XC078179@slippy.cwsent.com> <20171017125829.GA35718@albert.catwhisker.org> <20171017165708.GE1214@albert.catwhisker.org> From: Kevin Oberman Date: Tue, 17 Oct 2017 10:47:41 -0700 X-Google-Sender-Auth: P5N3C-5PjC9XRL5w7XzeCIThGSE Message-ID: Subject: Re: cve-2017-13077 - WPA2 security vulni To: "current@freebsd.org" , Allan Jude , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 17:47:43 -0000 On Tue, Oct 17, 2017 at 9:57 AM, David Wolfskill wrote: > On Tue, Oct 17, 2017 at 12:51:23PM -0400, Allan Jude wrote: > > .... > > > Question: Should one expect a wpa_supplicant-2.6_2 executable built > > > under FreeBSD stable/11 (amd64) to work on the same hardware, but > > > running head? > > > > Did you run the version from ports, or did you run the base /etc/rc.d > > script with your rc.conf set to point to the ports binary? This will run > > the command with -c /etc/wpa_supplicant.conf overriding the ports > default. > > > > So this is expected to work in this way. > > Ah. When I installed the port, I was reminded: > > | ... > | ===> Registering installation for wpa_supplicant-2.6_2 > | Installing wpa_supplicant-2.6_2... > | To use the ports version of WPA Supplicant instead of the base, add: > | > | wpa_supplicant_program="/usr/local/sbin/wpa_supplicant" > | > | to /etc/rc.conf > | > | ===> SECURITY REPORT: > | .... > > So I did that. I did not do anything to the existing > /etc/rc.d/wpa_supplicant, which had been installed as part of base > FreeBSD. > > > .... > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Unsubstantiated claims of "Fake News" are evidence that the claimant lies > again. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > Possibly silly question, but are any of the defaults for the port different from those on the base system? DEBUG_* seem most likely to differ, but I'd like to know if there are any others. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Tue Oct 17 18:30:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19E46E43934 for ; Tue, 17 Oct 2017 18:30:13 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id F224D7D899 for ; Tue, 17 Oct 2017 18:30:12 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: by mailman.ysv.freebsd.org (Postfix) id F1860E43932; Tue, 17 Oct 2017 18:30:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F10B1E43931; Tue, 17 Oct 2017 18:30:12 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A2A1D7D898; Tue, 17 Oct 2017 18:30:12 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 4WczehFCq8LPZ4Wd0ehbpj; Tue, 17 Oct 2017 12:30:11 -0600 X-Authority-Analysis: v=2.2 cv=e552ceh/ c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=02M-m0pO-4AA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=JAf30KXuAAAA:8 a=gsVTMZc-e18G9YXemzAA:9 a=0d3Gbymw0icyI_P7:21 a=FrYc7tShwVMm2ZT8:21 a=CjuIK1q_8ugA:10 a=B7oAcX1g-pxp_4Rd99MA:9 a=qyELxdWss1W8s_ag:21 a=Ahsjc18wbD99ZTXW:21 a=jTaVwnckFTYJj8V4:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=GEL62FyrTCmHtEug2d3R:22 Received: from [25.172.12.81] (S0106d4ca6d8943b0.gv.shawcable.net [24.68.134.59]) by spqr.komquats.com (Postfix) with ESMTPSA id 2099060F; Tue, 17 Oct 2017 11:30:09 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: cve-2017-13077 - WPA2 security vulni Date: Tue, 17 Oct 2017 11:30:13 -0700 To: "current@freebsd.org" , Allan Jude CC: "freebsd-current@freebsd.org" Message-Id: <20171017183009.2099060F@spqr.komquats.com> X-CMAE-Envelope: MS4wfAjFnug+Vr40F5IPNqUSO3rRnQpQaqWbYa8bK41XEtLCNaSTBv+PWgMbiEkjiC2BFMnqbSihk0k4YwgM4wWpG7X7TkC/LAqE623udi9fAnNvNSvPCZXD cK37dVhZrF8NLmPSTe27BOKVMKAWTVtObgMRmv+45g79rn87Ej26Edhprr1E5yVwn6fDGrHimAo44qrCH5PSrIPNBZDsxvjL0P9i4R3I4LNR3FDqJdW0tcZ4 nlMhlpHpMWWwakTdn5sF9g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 18:30:13 -0000 I had no problems last night. It associated with one of my netgear APs. I u= sed /etc/wpa_supplicant.conf. I am running head and all my ports are built on head (most poudeiere and a = few by hand). --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Cy Schubert or -----Original Message----- From: David Wolfskill Sent: 17/10/2017 09:57 To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: cve-2017-13077 - WPA2 security vulni On Tue, Oct 17, 2017 at 12:51:23PM -0400, Allan Jude wrote: > .... > > Question: Should one expect a wpa_supplicant-2.6_2 executable built > > under FreeBSD stable/11 (amd64) to work on the same hardware, but > > running head? >=20 > Did you run the version from ports, or did you run the base /etc/rc.d > script with your rc.conf set to point to the ports binary? This will run > the command with -c /etc/wpa_supplicant.conf overriding the ports default= . >=20 > So this is expected to work in this way. Ah. When I installed the port, I was reminded: | ... | =3D=3D=3D> Registering installation for wpa_supplicant-2.6_2 | Installing wpa_supplicant-2.6_2... | To use the ports version of WPA Supplicant instead of the base, add: |=20 | wpa_supplicant_program=3D"/usr/local/sbin/wpa_supplicant" |=20 | to /etc/rc.conf |=20 | =3D=3D=3D> SECURITY REPORT: | .... So I did that. I did not do anything to the existing /etc/rc.d/wpa_supplicant, which had been installed as part of base FreeBSD. > .... Peace, david --=20 David H. Wolfskill david@catwhisker.org Unsubstantiated claims of "Fake News" are evidence that the claimant lies a= gain. See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@freebsd.org Tue Oct 17 21:26:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF9F9E47E59 for ; Tue, 17 Oct 2017 21:26:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0081.outbound.protection.outlook.com [104.47.37.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86282843D5; Tue, 17 Oct 2017 21:26:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB0955.CANPRD01.PROD.OUTLOOK.COM (52.132.44.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 17 Oct 2017 21:26:49 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::50ab:b8bf:bbb9:81f4]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::50ab:b8bf:bbb9:81f4%13]) with mapi id 15.20.0077.022; Tue, 17 Oct 2017 21:26:48 +0000 From: Rick Macklem To: Mateusz Guzik , Ian Lepore CC: "freebsd-current@freebsd.org" , "fabian.freyer@physik.tu-berlin.de" , "mjoras@freebsd.org" Subject: Re: pfind_locked(pid) fails when in a jail? Thread-Topic: pfind_locked(pid) fails when in a jail? Thread-Index: AQHTRsy4PlPkoH+r1k6i+VZl2ipOV6LnEU+AgAALmQCAAAVwgIAABEedgAELXQCAABYcAIAARZy3 Date: Tue, 17 Oct 2017 21:26:48 +0000 Message-ID: References: <1508195986.74236.6.camel@freebsd.org> <20171016233912.7n6rosak5a5tzcbz@mguzik> <1508255488.74236.29.camel@freebsd.org>, <20171017171034.dyo74lrye6ds6ggp@mguzik> In-Reply-To: <20171017171034.dyo74lrye6ds6ggp@mguzik> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB0955; 6:cg7yc0NbX91KdyWfZpuYjo5x5ZKGf3ZeU2wWNO+zBFzsGmAleBaJuatzSMD9AlqcjPzZb6Zob8yoEzHr8GnF8zqiZmHjGzS7GzaHBmZZAOCL0Ob6ME8O8fy9C70fKmU0CmIyUs4qjsDb/l1g5H2k1frnsFXc5EeFHd/YAkvgzmyCu5SU8XM/qg1T8W901WNYTFGfgGCnfl/qzg36tkkGA+MumwNOjA/D7Kk7W7DCcp4lhG4qgC+dO5+QHloskEp8NsZqtfcthLFKfquM5x0GbVZlK7C2seknm6HBCLjtXG01aZA4XMNf8nPytVcrU4L0YBshSmdXENTtalc/FPO8EA==; 5:Xcy+g7FguV0p7WDD5dKZrFld34q700+wFUyR6yurZOFBC8MOuc+jWk5Hdl3u0w86U5iiMqRDIF+727jMqmiU+3GS6ztYHkLM+0P7m56MW1C5ILyG0Z8BXeMg8As62vgWc9MEAWqIxfryo0ORvz+7QIF2pZaHAaosKA1dOpebUAA=; 24:qK4yD9xD3hNvrwDFg+XCMaIrCi1qY8IkX7WISbgxMpAEsk9hoW/W2cR5nqeAGCwG3gVFsrh+l1UBghOWj7hyZt6SIHfCt+hv8EMqrW+T6PM=; 7:EyfREY7lxSvYITejqqS/qn6AfomPrBKHvfMkhfw3UlKc44Wi3wLgv1gK5ZfPsHabxItUqUjVAo31AkefwBVpdlxk9jHgW9/yE9mwT6SZGXYZ3F/Ukj4GEKk/ZCkyFddbpqgkoj81aCMzrhlJHA8VCiSu6emqRJzUcV4Sxfp//KRCfA7BpGqYHB8oQhxg5TXk4SXxoLsjkrtjvRLj3Ce3JQFp4Ahr0ZiXJj0V/Z5QjoY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7625e8bb-1638-4866-0ceb-08d515a5c69c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:YTOPR0101MB0955; x-ms-traffictypediagnostic: YTOPR0101MB0955: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTOPR0101MB0955; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTOPR0101MB0955; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(24454002)(199003)(189002)(7696004)(14454004)(189998001)(3660700001)(2950100002)(2906002)(74316002)(39060400002)(54356999)(8936002)(81156014)(305945005)(106356001)(81166006)(50986999)(74482002)(4326008)(97736004)(76176999)(6436002)(8676002)(101416001)(5250100002)(102836003)(53936002)(68736007)(6506006)(2900100001)(55016002)(86362001)(6246003)(478600001)(93886005)(3280700002)(105586002)(5660300001)(25786009)(110136005)(229853002)(54906003)(33656002)(786003)(9686003)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0955; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 21:26:48.7914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0955 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 21:26:51 -0000 Mateusz Guzik wrote: [lots of stuff snipped] > I proposed registration of per-process callbacks, not filtering. > The code would just walk the list/table/whatever and call everything on > it - they asked for it. Yep, this would work for the NFSv4 client. Way back when, all I did in OpenBSD was add a function pointer to "struct p= roc" that was normally NULL, but set to a function in the NFS client when an NFS= v4 Open was done for the process. I suspect you'd want something like a linked list, so that multiple "users"= could register callback functions upon exit or ... rick= From owner-freebsd-current@freebsd.org Tue Oct 17 22:42:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B97FAE49868 for ; Tue, 17 Oct 2017 22:42:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97CD51C35 for ; Tue, 17 Oct 2017 22:42:07 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6c8cb318-b38c-11e7-a938-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 6c8cb318-b38c-11e7-a938-4f970e858fdb; Tue, 17 Oct 2017 22:42:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9HMg03l004528; Tue, 17 Oct 2017 16:42:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508280119.57370.20.camel@freebsd.org> Subject: Re: pfind_locked(pid) fails when in a jail? From: Ian Lepore To: Rick Macklem , Mateusz Guzik Cc: "freebsd-current@freebsd.org" , "fabian.freyer@physik.tu-berlin.de" , "mjoras@freebsd.org" Date: Tue, 17 Oct 2017 16:41:59 -0600 In-Reply-To: References: <1508195986.74236.6.camel@freebsd.org> <20171016233912.7n6rosak5a5tzcbz@mguzik> <1508255488.74236.29.camel@freebsd.org> , <20171017171034.dyo74lrye6ds6ggp@mguzik> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 22:42:07 -0000 On Tue, 2017-10-17 at 21:26 +0000, Rick Macklem wrote: > Mateusz Guzik wrote: > [lots of stuff snipped] > > > > I proposed registration of per-process callbacks, not filtering. > > The code would just walk the list/table/whatever and call everything on > > it - they asked for it. > Yep, this would work for the NFSv4 client. > Way back when, all I did in OpenBSD was add a function pointer to "struct proc" > that was normally NULL, but set to a function in the NFS client when an NFSv4 > Open was done for the process. > > I suspect you'd want something like a linked list, so that multiple "users" could register callback functions upon exit or ... > > rick FYI, I'm dropping out of this conversation, not because I'm out of opinions, but for some reason I'm not getting the emails from Mateusz that you're replying to, and now so much context is snipped that I don't know what's being said by whom. -- Ian From owner-freebsd-current@freebsd.org Wed Oct 18 14:49:06 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 800A3E3AE9B for ; Wed, 18 Oct 2017 14:49:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F45E80579; Wed, 18 Oct 2017 14:49:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 03F2A10AB01; Wed, 18 Oct 2017 10:49:05 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: David Boyd , "mckusick@mckusick.com" , "gjb@freebsd.org" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Date: Wed, 18 Oct 2017 07:49 -0700 Message-ID: <2094438.bITRq4LixK@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <1508255864.5659.3.camel@twc.com> References: <1508255864.5659.3.camel@twc.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 18 Oct 2017 10:49:05 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:49:06 -0000 On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays > many checksum failed messages when booted. (see attachment). > > I think this started about 20170925. > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- > CURRENT. > > Only the 12.0-CURRENT image exhibits this behavior. > > This is easily fixed by "fsck -y /" in single-user mode during the boot > process. > > I can test any updates at almost any time. I wonder if the tool creating the snapshot images wasn't updated to generate cg checksums when creating the initial filesystem. Glen, do you know which tool (makefs or something else?) is used to generate the UFS filesystem in VM images for snapshots? (In this case it appears to be a .vmdk image) -- John Baldwin From owner-freebsd-current@freebsd.org Wed Oct 18 15:01:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49692E3B520 for ; Wed, 18 Oct 2017 15:01:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2405E811CF; Wed, 18 Oct 2017 15:01:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 184D91FB; Wed, 18 Oct 2017 15:01:57 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 18 Oct 2017 15:01:55 +0000 From: Glen Barber To: John Baldwin Cc: freebsd-current@freebsd.org, David Boyd , "mckusick@mckusick.com" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Message-ID: <20171018150155.GA28174@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <2094438.bITRq4LixK@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <2094438.bITRq4LixK@ralph.baldwin.cx> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 15:01:58 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays > > many checksum failed messages when booted. (see attachment). > >=20 > > I think this started about 20170925. > >=20 > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- > > CURRENT. > >=20 > > Only the 12.0-CURRENT image exhibits this behavior. > >=20 > > This is easily fixed by "fsck -y /" in single-user mode during the boot > > process. > >=20 > > I can test any updates at almost any time. >=20 > I wonder if the tool creating the snapshot images wasn't updated to gener= ate > cg checksums when creating the initial filesystem. Glen, do you know whi= ch > tool (makefs or something else?) is used to generate the UFS filesystem > in VM images for snapshots? (In this case it appears to be a .vmdk image) >=20 mkimg(1) is used. Glen --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEVVuz/A7vpH93hEhKuWzd6q+LXtAFAlnnbOMACgkQuWzd6q+L XtD9qRAAv9VBnhGZ5bTf7Xd6qKVz8gaUAmd2CN3OY0wuiJpwKJj7uWsYF2+neAzt 2EiTZK7aofOd8O7U24Rf/NgMbHgqWJZFtJsnh0xTg+RBC142bazUd7p00r3gpL2A 46RVvrdaw23zrTsfvSiI0i0PnvrQ2Rgb+U6/0r8gbmTlrQF1WyLDp5CRPYN3r+ST hgWn5oOqrDT1Bd1iv6oSdWPh7UxwtwuVb1wjcvWLad1LezyGzRC9KGzkblskLU8c BjO0vrtlNOH0JbuQMB8+kjUkwIqx8oEBI7UPpMhjIijmEcmN6uHzEkvO0Q6MGb4E N+FVXzFofWEGmdVV9qUZyGyci78Sj6c2Fbj5momknDc5U3bcCAsGdFv5BQIekIJY eWQusRzNUYwoEhuyV46S6pflu69J8qNNMRe2q7WMQ1NPrJ/5XPgw7Wf8G5xdDzIH ojMh8HIXvg0upS1phelr23WDTHWNw0Y/HwHJHM5/zFDE3Vcf4rXd2c9zhEPDHjxq T21+nrB6+ARyypdtvv2fh40DLBiy3IJAbKT1JoYi+pcZ2egsBiZcmtYu87LNlA2/ Gr0wPP1m1JQ1t1geDAJjnJges7zOCU/nfWDjQGesVWWjjTvGI2zSpsDm2GWmQd59 zqfd9gNLSpPw46rpzyUKSdto/y8CZtEPpAhd+RdPtCKx+FK1MK8= =0CDW -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-current@freebsd.org Wed Oct 18 16:29:06 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 492EBE3D70F for ; Wed, 18 Oct 2017 16:29:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C0768499A; Wed, 18 Oct 2017 16:29:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 8F70F10A8BA; Wed, 18 Oct 2017 12:29:04 -0400 (EDT) From: John Baldwin To: Glen Barber Cc: freebsd-current@freebsd.org, David Boyd , "mckusick@mckusick.com" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Date: Wed, 18 Oct 2017 09:28:40 -0700 Message-ID: <1740653.LGy8gQVNSR@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20171018150155.GA28174@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <2094438.bITRq4LixK@ralph.baldwin.cx> <20171018150155.GA28174@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 18 Oct 2017 12:29:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:29:06 -0000 On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote: > On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: > > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays > > > many checksum failed messages when booted. (see attachment). > > > > > > I think this started about 20170925. > > > > > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- > > > CURRENT. > > > > > > Only the 12.0-CURRENT image exhibits this behavior. > > > > > > This is easily fixed by "fsck -y /" in single-user mode during the boot > > > process. > > > > > > I can test any updates at almost any time. > > > > I wonder if the tool creating the snapshot images wasn't updated to generate > > cg checksums when creating the initial filesystem. Glen, do you know which > > tool (makefs or something else?) is used to generate the UFS filesystem > > in VM images for snapshots? (In this case it appears to be a .vmdk image) > > > > mkimg(1) is used. Does makefs generate the UFS image fed into mkimg or does mkimg generate the UFS partition itself? -- John Baldwin From owner-freebsd-current@freebsd.org Wed Oct 18 16:40:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68588E3DEA4 for ; Wed, 18 Oct 2017 16:40:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44ADA67D; Wed, 18 Oct 2017 16:40:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 56F792446; Wed, 18 Oct 2017 16:40:24 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 18 Oct 2017 16:40:22 +0000 From: Glen Barber To: John Baldwin Cc: freebsd-current@freebsd.org, David Boyd , "mckusick@mckusick.com" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Message-ID: <20171018164022.GT55623@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <2094438.bITRq4LixK@ralph.baldwin.cx> <20171018150155.GA28174@FreeBSD.org> <1740653.LGy8gQVNSR@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MI2pJyvBeFc4alSb" Content-Disposition: inline In-Reply-To: <1740653.LGy8gQVNSR@ralph.baldwin.cx> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:40:25 -0000 --MI2pJyvBeFc4alSb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 18, 2017 at 09:28:40AM -0700, John Baldwin wrote: > On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote: > > On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: > > > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > > > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays > > > > many checksum failed messages when booted. (see attachment). > > > >=20 > > > > I think this started about 20170925. > > > >=20 > > > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- > > > > CURRENT. > > > >=20 > > > > Only the 12.0-CURRENT image exhibits this behavior. > > > >=20 > > > > This is easily fixed by "fsck -y /" in single-user mode during the = boot > > > > process. > > > >=20 > > > > I can test any updates at almost any time. > > >=20 > > > I wonder if the tool creating the snapshot images wasn't updated to g= enerate > > > cg checksums when creating the initial filesystem. Glen, do you know= which > > > tool (makefs or something else?) is used to generate the UFS filesyst= em > > > in VM images for snapshots? (In this case it appears to be a .vmdk i= mage) > > >=20 > >=20 > > mkimg(1) is used. >=20 > Does makefs generate the UFS image fed into mkimg or does mkimg generate = the > UFS partition itself? >=20 Sorry, I may have understated a bit. First, mdconfig(8) is used to create a md(4)-backed disk, onto which newfs(8) is run, followed by the installworld/installkernel targets. Next, mkimg(1) is used to feed the resultant md(4)-based .img filesystem (after umount(8)) to create the final output image. Glen --MI2pJyvBeFc4alSb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEVVuz/A7vpH93hEhKuWzd6q+LXtAFAlnng/EACgkQuWzd6q+L XtCr6w/+N42fm6CoKraq7ZNN2M7jx5/zNLg8PxU097IPSu+9wTr3ZXdb1iroVBF6 qr5sag/c48jvJjv/t16Ffsr2jGDaDZhNMnEImq9TqkEXCE0wVhfpAWlRwqXItNpn pZpVS0dXFbSUaMnLb1t/0S3I+4mIE0LaEK1rZP4vgr7A71jmbx/usL3S3+BHwSHo 8vpjEzT+TcJ0fx8Uq/fBVUjXl03INmRysssrfWXH2aShf3DdzOrC5i1+uyRoOofd 2cppFHM9YEdq3QjNa4u9H08ZZcG20Gow3ezrueDSdvp6atvU8r+36zakfnQJ/PJ6 8LlkgIORKUk4LdxM4s29Dy1ScTXWs2EsYfg/wPXU3HvCqiOJAixn3EyCs5Exqr6M XUdF2ZCa1rgZ8qPjPrMtc4tjWkRJnG8cdEQwyH3UnWz4jR/YOsXDSi6+g+uHIt4N r8PYp+cFaagKjONMbTDhn85BMg/s/wleHYgNNr9Quq3WDWwoTVonVj5YrwBHkrkW JQHt3cu5CelV0mgl5sbPM8FYq6xrRDLVdORKX93UL1DcgrSUS1ofxuH5zyeqeBQH jt3QYA0HQuMs404NpHsy0kFzbwcW5kHnx00VMyVfLBDCcpyPO1GYok4hs0vy9cjM 2P0XjxO199LSpX6tu3/Fh9d4NH6we27rx4e/wR3KqQfiYQlysI8= =XV86 -----END PGP SIGNATURE----- --MI2pJyvBeFc4alSb-- From owner-freebsd-current@freebsd.org Wed Oct 18 16:58:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1146E3E8CA for ; Wed, 18 Oct 2017 16:58:35 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6AB21664; Wed, 18 Oct 2017 16:58:35 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 8FB3E2BC6; Wed, 18 Oct 2017 16:58:34 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 18 Oct 2017 16:58:32 +0000 From: Glen Barber To: John Baldwin Cc: freebsd-current@freebsd.org, David Boyd , "mckusick@mckusick.com" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Message-ID: <20171018165832.GU55623@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <2094438.bITRq4LixK@ralph.baldwin.cx> <20171018150155.GA28174@FreeBSD.org> <1740653.LGy8gQVNSR@ralph.baldwin.cx> <20171018164022.GT55623@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U7F658e60E1K4csu" Content-Disposition: inline In-Reply-To: <20171018164022.GT55623@FreeBSD.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:58:35 -0000 --U7F658e60E1K4csu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 18, 2017 at 04:40:22PM +0000, Glen Barber wrote: > On Wed, Oct 18, 2017 at 09:28:40AM -0700, John Baldwin wrote: > > On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote: > > > On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: > > > > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > > > > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displa= ys > > > > > many checksum failed messages when booted. (see attachment). > > > > >=20 > > > > > I think this started about 20170925. > > > > >=20 > > > > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- > > > > > CURRENT. > > > > >=20 > > > > > Only the 12.0-CURRENT image exhibits this behavior. > > > > >=20 > > > > > This is easily fixed by "fsck -y /" in single-user mode during th= e boot > > > > > process. > > > > >=20 > > > > > I can test any updates at almost any time. > > > >=20 > > > > I wonder if the tool creating the snapshot images wasn't updated to= generate > > > > cg checksums when creating the initial filesystem. Glen, do you kn= ow which > > > > tool (makefs or something else?) is used to generate the UFS filesy= stem > > > > in VM images for snapshots? (In this case it appears to be a .vmdk= image) > > > >=20 > > >=20 > > > mkimg(1) is used. > >=20 > > Does makefs generate the UFS image fed into mkimg or does mkimg generat= e the > > UFS partition itself? > >=20 >=20 > Sorry, I may have understated a bit. >=20 > First, mdconfig(8) is used to create a md(4)-backed disk, onto which > newfs(8) is run, followed by the installworld/installkernel targets. >=20 > Next, mkimg(1) is used to feed the resultant md(4)-based .img > filesystem (after umount(8)) to create the final output image. >=20 Following offline discussion, the issue appears to be the build machine kernel is older than the newly-built newfs(8). Glen --U7F658e60E1K4csu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEVVuz/A7vpH93hEhKuWzd6q+LXtAFAlnniDgACgkQuWzd6q+L XtCTkQ//Yi+QQdjtJlGyUqBQ2WYLFc4uTo+hPoiDizUaCZ1BBhM7ynP6+On6M3lm adJyncYAxg7LNBA9ip/i2nj5oBc5x6E9VwqSBo00VGvlpNWPZY4yJI0GWEFKcDo7 T6vFmzOJR5b+xRBIRhM4XPwtw8KhNerfuMO5pbD7pIuWH5OQVYQXpd6PItCrF8hC 3UXuNz+a9TK377luVY5ZwFyfwXcg+1HKEN0GOpndbToEmnEmfhYQKDsQsredi9XY K+1NfPBvvmHgFEUHH2Q3LFhvuVilYtR8p5wc4yjdnvGR97kUqj3cuLx/iuDJ4+hn 8fS+oGuOaQwBLxME5Lem+oKkB/cA7jbFkbyx/zEVXeIoladLNBHHcoG99Vd/3Iei hfeoSrMC7Sg4ha6a7qww2vOa7nHrKVbBAPnZ7zqqOnQPrrDCxPEibg33t/5ye87m X46oFalXaLSHyUXPK7sR6xOmJ88Kp0Fjmmq8kgnjZJZtJGrGdLGdf/TirZagKecY j+HskS/bYp8j2U9tupp/CnK2WOzxy+PhRF+ctkfkOyfBmmY18Yty/LxUi0x7/4tG pqXQjds+VjXLNPpKoh+zH18egeK264waDt9cxbwWNrW5FQlXMr8XeHDuUpXRjwmD CLml8avbvhPNcJQqGreNQVwKRiyIK+T+/hgMnv9dwj5fddT+dnA= =9ZRP -----END PGP SIGNATURE----- --U7F658e60E1K4csu-- From owner-freebsd-current@freebsd.org Wed Oct 18 18:07:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDABAE4078D for ; Wed, 18 Oct 2017 18:07:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F29E64297 for ; Wed, 18 Oct 2017 18:07:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id 72so6971437itk.3 for ; Wed, 18 Oct 2017 11:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AZi/NELw2DZSRrqVixXwmWK2W1rNnIu6R4NfvPwEGF0=; b=0aR5jStpZf41kR2N05M7zC71B9zJhSGa8tJZE0VNfAvdyz+sW4hvRRSfsIVpCE+x2Q 4IaH/esO8464nyhy57Mui1d+oiHsyazW7Z+LEep/Izm2YKd+8t1TLgklsIZIZ4w1JfWU ZhQ1THMbamW52zOQX8WJ6uhVWmywhqRZJaHikb648V2BKJjlKgNVUxnglv6pvYHC/Ejj bbf2nRH9m8BUjGQ8ykxpnenQsPiuPW11QkC2GlC/U8L/VVSFtvy8Yl5t1+1zg35/cjOk 7UybXCDbomKAhLurA/V3uTnT4qi+Wf0tOPwdzkMGuywoIofC4nmBXskdK0sbdZI20KbM g3PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AZi/NELw2DZSRrqVixXwmWK2W1rNnIu6R4NfvPwEGF0=; b=G5c+/4yMjdwdAZIDadO93x+Wx87YyFZaRUUI/mRALwrhJkWCqOs5qLvOp6Fhug2Mop qanfV/lGQeT23QXHCKZbFSc24vYkyh0IAGRdyYJ2twle77bwvR/uakGzs+heiZeEATSX aFVbYFDtdRF7bLxMPgV/3GJsecpy5zXVCMyMZ86I+OziW/PouLU+71C/xNrDzrFf6WpP RGLAdqDv4cNtEzlqEoqLo7ZHAxbts5ESFxZvDWvBRET3KkJTKL5FSiTLp2dW4MSdjUMD cyryB+RlpNgdEmlXr8o7oJoA9wY8QOT+qfeepKhy24VIcawMqvZu81I/+oIYP9uIsXfl O7UQ== X-Gm-Message-State: AMCzsaUniuu/dMhZHk8Ncw7tXKTHHVxzqVwY8qOyZ+C0OHKaZ9vHWf/K y1V79Q2pCHCNNNuBzLzSgN2XpIYIkcz5eBf1/buvEQ== X-Google-Smtp-Source: ABhQp+QPk5olMLyyHWZpxOevNhB0GEC7pG8DuSez5DJjlu3aR9AEy/wt38AHHP57mjB7FPI3UURxTCAVSeHeA+C4BSs= X-Received: by 10.36.184.5 with SMTP id m5mr11571922ite.69.1508350047749; Wed, 18 Oct 2017 11:07:27 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Wed, 18 Oct 2017 11:07:27 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:e17a:e8bd:b0d5:9334] In-Reply-To: <20171018164022.GT55623@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <2094438.bITRq4LixK@ralph.baldwin.cx> <20171018150155.GA28174@FreeBSD.org> <1740653.LGy8gQVNSR@ralph.baldwin.cx> <20171018164022.GT55623@FreeBSD.org> From: Warner Losh Date: Wed, 18 Oct 2017 12:07:27 -0600 X-Google-Sender-Auth: 5c_9dKS_hivfl0-Z_8SZxEN_0ro Message-ID: Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages To: Glen Barber Cc: John Baldwin , FreeBSD Current , David Boyd , "mckusick@mckusick.com" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 18:07:28 -0000 On Wed, Oct 18, 2017 at 10:40 AM, Glen Barber wrote: > On Wed, Oct 18, 2017 at 09:28:40AM -0700, John Baldwin wrote: > > On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote: > > > On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: > > > > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > > > > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image > displays > > > > > many checksum failed messages when booted. (see attachment). > > > > > > > > > > I think this started about 20170925. > > > > > > > > > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- > > > > > CURRENT. > > > > > > > > > > Only the 12.0-CURRENT image exhibits this behavior. > > > > > > > > > > This is easily fixed by "fsck -y /" in single-user mode during the > boot > > > > > process. > > > > > > > > > > I can test any updates at almost any time. > > > > > > > > I wonder if the tool creating the snapshot images wasn't updated to > generate > > > > cg checksums when creating the initial filesystem. Glen, do you > know which > > > > tool (makefs or something else?) is used to generate the UFS > filesystem > > > > in VM images for snapshots? (In this case it appears to be a .vmdk > image) > > > > > > > > > > mkimg(1) is used. > > > > Does makefs generate the UFS image fed into mkimg or does mkimg generate > the > > UFS partition itself? > > > > Sorry, I may have understated a bit. > > First, mdconfig(8) is used to create a md(4)-backed disk, onto which > newfs(8) is run, followed by the installworld/installkernel targets. > > Next, mkimg(1) is used to feed the resultant md(4)-based .img > filesystem (after umount(8)) to create the final output image. > NanoBSD has moved to using makefs from a tree in the host + metadata information. That avoids the whole mdconfig issue. Might not be a bad idea for the release build if pkg src isn't going to solve that. Warner From owner-freebsd-current@freebsd.org Wed Oct 18 17:02:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B9AEE3ECB6 for ; Wed, 18 Oct 2017 17:02:32 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06B261DCD; Wed, 18 Oct 2017 17:02:31 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id v9IGxkTF098041; Wed, 18 Oct 2017 09:59:46 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201710181659.v9IGxkTF098041@chez.mckusick.com> From: Kirk McKusick To: Glen Barber Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages cc: John Baldwin , freebsd-current@freebsd.org, David Boyd In-reply-to: <20171018164022.GT55623@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98039.1508345986.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Oct 2017 09:59:46 -0700 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com X-Mailman-Approved-At: Wed, 18 Oct 2017 18:26:50 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 17:02:32 -0000 > Date: Wed, 18 Oct 2017 16:40:22 +0000 > From: Glen Barber > To: John Baldwin > Cc: freebsd-current@freebsd.org, David Boyd , > "mckusick@mckusick.com" > Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages > = > On Wed, Oct 18, 2017 at 09:28:40AM -0700, John Baldwin wrote: >> On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote: >>> On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: >>>> On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: >>>>> The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays >>>>> many checksum failed messages when booted. (see attachment). >>>>> >>>>> I think this started about 20170925. >>>>> >>>>> I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- >>>>> CURRENT. >>>>> >>>>> Only the 12.0-CURRENT image exhibits this behavior. >>>>> >>>>> This is easily fixed by "fsck -y /" in single-user mode during the b= oot >>>>> process. >>>>> >>>>> I can test any updates at almost any time. >>>> >>>> I wonder if the tool creating the snapshot images wasn't updated to >>>> generate cg checksums when creating the initial filesystem. Glen, >>>> do you know which tool (makefs or something else?) is used to >>>> generate the UFS filesystem in VM images for snapshots? >>>> (In this case it appears to be a .vmdk image) >>>> >>> >>> mkimg(1) is used. >> >> Does makefs generate the UFS image fed into mkimg or does mkimg generat= e the >> UFS partition itself? > = > Sorry, I may have understated a bit. > = > First, mdconfig(8) is used to create a md(4)-backed disk, onto which > newfs(8) is run, followed by the installworld/installkernel targets. > = > Next, mkimg(1) is used to feed the resultant md(4)-based .img > filesystem (after umount(8)) to create the final output image. > = > Glen Glen, Can you try running fsck on the md(4) disk after you do the unmount to see if it finds any problems (`fsck /dev/md0')? If that comes up clean (as it should), then I can investigate what it is about mkimg that causes problems. If fsck finds problems, then there is an issue in the base UFS infrastructure. Kirk McKusick From owner-freebsd-current@freebsd.org Wed Oct 18 22:30:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FE5EE45755 for ; Wed, 18 Oct 2017 22:30:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C83256C7F0; Wed, 18 Oct 2017 22:30:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id EDB6410A8C0; Wed, 18 Oct 2017 18:30:29 -0400 (EDT) From: John Baldwin To: Glen Barber Cc: freebsd-current@freebsd.org, David Boyd , "mckusick@mckusick.com" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Date: Wed, 18 Oct 2017 09:49:16 -0700 Message-ID: <3514274.MTfVLsneXj@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20171018164022.GT55623@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <1740653.LGy8gQVNSR@ralph.baldwin.cx> <20171018164022.GT55623@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 18 Oct 2017 18:30:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 22:30:38 -0000 On Wednesday, October 18, 2017 04:40:22 PM Glen Barber wrote: > On Wed, Oct 18, 2017 at 09:28:40AM -0700, John Baldwin wrote: > > On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote: > > > On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: > > > > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > > > > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays > > > > > many checksum failed messages when booted. (see attachment). > > > > > > > > > > I think this started about 20170925. > > > > > > > > > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- > > > > > CURRENT. > > > > > > > > > > Only the 12.0-CURRENT image exhibits this behavior. > > > > > > > > > > This is easily fixed by "fsck -y /" in single-user mode during the boot > > > > > process. > > > > > > > > > > I can test any updates at almost any time. > > > > > > > > I wonder if the tool creating the snapshot images wasn't updated to generate > > > > cg checksums when creating the initial filesystem. Glen, do you know which > > > > tool (makefs or something else?) is used to generate the UFS filesystem > > > > in VM images for snapshots? (In this case it appears to be a .vmdk image) > > > > > > > > > > mkimg(1) is used. > > > > Does makefs generate the UFS image fed into mkimg or does mkimg generate the > > UFS partition itself? > > > > Sorry, I may have understated a bit. > > First, mdconfig(8) is used to create a md(4)-backed disk, onto which > newfs(8) is run, followed by the installworld/installkernel targets. > > Next, mkimg(1) is used to feed the resultant md(4)-based .img > filesystem (after umount(8)) to create the final output image. Hmm, so I suspect you are using an older kernel, but I wonder if you are also using an older newfs or a newer newfs? If the newfs is the same as as the running kernel, then this means that upgrading from a pre-cg-sum kernel to a cg-sum kernel will have similar issues. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Oct 19 13:39:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76F16E3BE02 for ; Thu, 19 Oct 2017 13:39:14 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9426A523; Thu, 19 Oct 2017 13:39:14 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 58F591334A; Thu, 19 Oct 2017 13:39:13 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 19 Oct 2017 13:39:11 +0000 From: Glen Barber To: John Baldwin Cc: freebsd-current@freebsd.org, David Boyd , "mckusick@mckusick.com" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Message-ID: <20171019133911.GX55623@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <1740653.LGy8gQVNSR@ralph.baldwin.cx> <20171018164022.GT55623@FreeBSD.org> <3514274.MTfVLsneXj@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JNs4m2JFMNhdiK2v" Content-Disposition: inline In-Reply-To: <3514274.MTfVLsneXj@ralph.baldwin.cx> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 13:39:14 -0000 --JNs4m2JFMNhdiK2v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 18, 2017 at 09:49:16AM -0700, John Baldwin wrote: > On Wednesday, October 18, 2017 04:40:22 PM Glen Barber wrote: > > On Wed, Oct 18, 2017 at 09:28:40AM -0700, John Baldwin wrote: > > > On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote: > > > > On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: > > > > > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > > > > > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image disp= lays > > > > > > many checksum failed messages when booted. (see attachment). > > > > > >=20 > > > > > > I think this started about 20170925. > > > > > >=20 > > > > > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.= 0- > > > > > > CURRENT. > > > > > >=20 > > > > > > Only the 12.0-CURRENT image exhibits this behavior. > > > > > >=20 > > > > > > This is easily fixed by "fsck -y /" in single-user mode during = the boot > > > > > > process. > > > > > >=20 > > > > > > I can test any updates at almost any time. > > > > >=20 > > > > > I wonder if the tool creating the snapshot images wasn't updated = to generate > > > > > cg checksums when creating the initial filesystem. Glen, do you = know which > > > > > tool (makefs or something else?) is used to generate the UFS file= system > > > > > in VM images for snapshots? (In this case it appears to be a .vm= dk image) > > > > >=20 > > > >=20 > > > > mkimg(1) is used. > > >=20 > > > Does makefs generate the UFS image fed into mkimg or does mkimg gener= ate the > > > UFS partition itself? > > >=20 > >=20 > > Sorry, I may have understated a bit. > >=20 > > First, mdconfig(8) is used to create a md(4)-backed disk, onto which > > newfs(8) is run, followed by the installworld/installkernel targets. > >=20 > > Next, mkimg(1) is used to feed the resultant md(4)-based .img > > filesystem (after umount(8)) to create the final output image. >=20 > Hmm, so I suspect you are using an older kernel, but I wonder if you are = also > using an older newfs or a newer newfs? If the newfs is the same as as the > running kernel, then this means that upgrading from a pre-cg-sum kernel t= o a > cg-sum kernel will have similar issues. >=20 I'm somewhat confused by the suggested timestamp this was composed/sent and our out-of-band conversation, but the images are created with the new newfs(8) creating the target filesystem. Glen --JNs4m2JFMNhdiK2v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEVVuz/A7vpH93hEhKuWzd6q+LXtAFAlnoqv8ACgkQuWzd6q+L XtA5wA//QPrIhZ62t0IIImK1XAbkndSlCB55jWLWGP+BwQIop75PK+us8hJhaY2+ 21lryUBVDQy/bPlDeqC8+XeUXEAOG+AOIeqMTZgQR5VTV3vbjg4OX414l8WH8eZG 6P7X2cpz5gioNGZvEvEB5dtbGQ7MzH2gEJbv5JRJzNSWBCbgMA2OYUo6L+6smDKW bYm0ioWckoiki4N4ZC+BVxrtEGpXLLUWLx8e0N9ek16stLax1rS2NzFtz2ErfKL7 SjB0BKDvpHoHHJamgRsVBWR9iGZD4vgym9C5X5zr9t/315yDLRZLr6dOc6nlrk6P 9B4hTFdSFJw/BsMPSs3qMMPKAN62yxoCADMM9kBfvDqF8VcnbuC1anNPiVSfRQp0 SQc/6rnza2WezzJMzwvTNKifZOcIpMuWMUW7vZL/GQfaz3xxZpEDVTYrQaZVenWV ZRcEjKgm5CpGJ//49mdAFm9rxzk1N9RRmU4yt8Ee4K3eCfCOJZ4UEbNHsXpIm8i2 VEWRAoQ+3Pt4MLwgNKYam9uLSkBUa/bhoIrtBNzn9oicrOrVAQ0CYg3pf1qOI3zP qQuTh/W2PzyOJeRU/7l1xRgBbYmz9OY+bF18QQ9zAwvjsK3wRIlHYjm+JVZODdep HrP0ui7ezaSrsnamy7yDvljfRQWc4OJgRl0JEu1A/JrO72HtIkc= =tRRd -----END PGP SIGNATURE----- --JNs4m2JFMNhdiK2v-- From owner-freebsd-current@freebsd.org Thu Oct 19 15:31:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01FD5E3E976 for ; Thu, 19 Oct 2017 15:31:15 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D35D16DEE6; Thu, 19 Oct 2017 15:31:14 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id F1BE614ABD; Thu, 19 Oct 2017 15:31:13 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 19 Oct 2017 15:31:12 +0000 From: Glen Barber To: John Baldwin Cc: freebsd-current@freebsd.org, David Boyd , "mckusick@mckusick.com" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Message-ID: <20171019153112.GA55623@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <1740653.LGy8gQVNSR@ralph.baldwin.cx> <20171018164022.GT55623@FreeBSD.org> <3514274.MTfVLsneXj@ralph.baldwin.cx> <20171019133911.GX55623@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CjAlqr6ZqJYkDGFX" Content-Disposition: inline In-Reply-To: <20171019133911.GX55623@FreeBSD.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 15:31:15 -0000 --CjAlqr6ZqJYkDGFX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 19, 2017 at 01:39:11PM +0000, Glen Barber wrote: > On Wed, Oct 18, 2017 at 09:49:16AM -0700, John Baldwin wrote: > > On Wednesday, October 18, 2017 04:40:22 PM Glen Barber wrote: > > > First, mdconfig(8) is used to create a md(4)-backed disk, onto which > > > newfs(8) is run, followed by the installworld/installkernel targets. > > >=20 > > > Next, mkimg(1) is used to feed the resultant md(4)-based .img > > > filesystem (after umount(8)) to create the final output image. > >=20 > > Hmm, so I suspect you are using an older kernel, but I wonder if you ar= e also > > using an older newfs or a newer newfs? If the newfs is the same as as = the > > running kernel, then this means that upgrading from a pre-cg-sum kernel= to a > > cg-sum kernel will have similar issues. > >=20 >=20 > I'm somewhat confused by the suggested timestamp this was composed/sent > and our out-of-band conversation, but the images are created with the > new newfs(8) creating the target filesystem. >=20 Ok, I've confirmed upgrading the builder now produces VM images that do not exhibit this behavior (though, I'm still puzzled why I did not notice the errors earlier). I've removed the broken VM images from the mirrors, which the removal may still be propagating. New VM images should be available tomorrow. Glen --CjAlqr6ZqJYkDGFX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEVVuz/A7vpH93hEhKuWzd6q+LXtAFAlnoxUAACgkQuWzd6q+L XtAseBAAuT2N2zRYIUoze2t3rn/d+dej1rmxW2kDbUXhTwP+565lzu8lFmL0nJm9 qjhj+JUUSbZiRVAeP+fd9HJ5hEODhSAgMCq1RDUSGzUAz25N5/aXtjmMdeAy8OAs pAJrfCVNTeZXFQFvj5u1GHZsEVdhkS4pmUrG96rra/yAN8Am2vA26CN5VfIAQxzt T8gLgQHiGv1gi36oyjo69mcBglfUSv0FZ2SyRCqr6tU2cV+q2+/2CC7YlQT+Z6aH G2rw9Yzj3TehQpd1jfc2LFuBIMby0GsE7XCf3v2CxKPzNMwh3kNh8kNd0CcivS49 8wJs8ZDV3V4iKYNfuDBn9b/2kckJWdZBBF4BlGj7kkvooy4pZahhod9RaeWRISi8 lDZrfEHb4Ar7/bqtwn+ScO47BjV4eVRsZ5ZzpR3LW3IPggKnbLDDaJNvHxaEw7XX GsqcY8uo4SF4flS44PJjHvc5q+irpJ22HGDbEWyE1Yk4+NV0Qd2Z0G57VnF2GE+L rjzUySCGBxCDWohX2BC2+swZZlfd0U4j0ThJXEFba39DK6IlPdxYz91PJEKjQbeb NVz1aW6gFUZaHiboYNSO4ldAcVlPHQSF+xlpbzvWbVlfki8m5PJ867AdbY9B4V30 lgnrwTw9roMedDqENyAjjmToPs65U2Ro/iENZrLZ8TvAov+PcA4= =ztYr -----END PGP SIGNATURE----- --CjAlqr6ZqJYkDGFX-- From owner-freebsd-current@freebsd.org Fri Oct 20 11:46:19 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40EEBE2FE9A for ; Fri, 20 Oct 2017 11:46:19 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward105o.mail.yandex.net (forward105o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D665A732CE for ; Fri, 20 Oct 2017 11:46:18 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback4g.mail.yandex.net (mxback4g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:165]) by forward105o.mail.yandex.net (Yandex) with ESMTP id 5502C4443477 for ; Fri, 20 Oct 2017 14:46:06 +0300 (MSK) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback4g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id vo1VevesDi-k6umCYYQ; Fri, 20 Oct 2017 14:46:06 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508499966; bh=vCifIZaMjszvcMoYh7RsQs4MG3pJ61Gyi7XjQhziRyQ=; h=To:From:Subject:Message-ID:Date; b=ZukXnW8+ddajeitAuZp4PQNtGF++aoktnx14CythsI5MIAJ+4+JG1es8CX7euC/AJ Jljutp6pDJC2Wg1JmsuoFnjQ1a9+1sSsfqUqQrZ0h6UoI7tog7ccav/zfnAHz7RuAw kQRSrKEicBK7JWWkIV3rDeBUtshE+bf7CzH0IAck= Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id PX8oEb279d-k5waNQMR; Fri, 20 Oct 2017 14:46:05 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508499965; bh=vCifIZaMjszvcMoYh7RsQs4MG3pJ61Gyi7XjQhziRyQ=; h=To:From:Subject:Message-ID:Date; b=qR2o7wC6dlUugORoOM0dBo4/0m6o8kduDjonxXdEyz0V5KD1hLkzU2i+O6nfSocma FmVGImKMd3ST6OJyWFt7yZmtQF1OoSBvR4nvQmiHiN68nHVO8GXYRVm85Jsy1ClUGW p7EbrT2u6QF3kfQcY56Id+OBm3K059d2qnnnC7ZI= Authentication-Results: smtp1j.mail.yandex.net; dkim=pass header.i=@passap.ru To: freebsd-current@FreeBSD.org From: Boris Samorodov Subject: host, bhyve vm and ntpd Message-ID: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> Date: Fri, 20 Oct 2017 14:46:05 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 11:46:19 -0000 Hi All, I have got a host: --- bhyve-host% uname -a FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug 25 05:25:26 MSK 2017 bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 --- And a bhyve vm: --- bhyve-vm: uname -a FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri Oct 20 05:12:17 MSK 2017 bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 --- The only difference at kernel configs is a colored console. :-) And here I get some weird (is it?) result at the VM (I expect ntpd to be more stable): --- bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done remote refid st t when poll reach delay offset jitter ============================================================================== XX.XX.XX.1 XX.XX.XX.245 4 u 9 64 3 0.605 -1.202 316.407 XX.XX.XX.1 XX.XX.XX.245 4 u 7 64 7 0.605 -1.202 358.395 *XX.XX.XX.1 XX.XX.XX.245 4 u 5 64 17 0.615 -328.42 181.405 *XX.XX.XX.1 XX.XX.XX.245 4 u 3 64 37 0.615 -328.42 214.868 *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 37 0.615 -328.42 214.868 *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 77 0.615 -328.42 268.618 *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 177 0.615 -328.42 333.175 XX.XX.XX.1 .STEP. 16 u 1910 64 0 0.000 0.000 0.000 XX.XX.XX.1 XX.XX.XX.245 4 u 27 64 1 0.703 -262.63 0.004 XX.XX.XX.1 XX.XX.XX.245 4 u 31 64 1 0.649 -331.43 68.800 --- At the same time host's results are very stable: --- bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done remote refid st t when poll reach delay offset jitter ============================================================================== *XX.XX.XX.1 XX.XX.XX.245 4 u 1 64 1 0.401 0.176 0.106 *XX.XX.XX.1 XX.XX.XX.245 4 u 6 64 3 0.401 0.176 0.459 *XX.XX.XX.1 XX.XX.XX.245 4 u 3 64 7 0.401 0.176 0.940 *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 7 0.401 0.176 0.940 *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 17 0.401 0.176 1.566 *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 37 0.448 1.275 1.739 *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 77 0.448 1.275 2.365 *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 177 0.448 1.275 3.110 *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 377 0.448 1.275 3.929 *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 377 0.443 8.750 4.722 --- The network is organized via bridge -- host igb and vm tap interfaces are members of one bridge. Are those results expected? Does it smell like a bug? Should I dig furter? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@freebsd.org Fri Oct 20 13:52:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DA9DE34E9B for ; Fri, 20 Oct 2017 13:52:20 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ED3376CD3; Fri, 20 Oct 2017 13:52:19 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1508507537; bh=T8V0ZIT7sqgHlA+P8V8xn8R36lZwIMNMar30OcG ddO4=; b=GwqDOtqlS102zFSqhvZxetZKeoFvTlTOoD3zyn89zgh/zS0J00HxL9E tWOr27i9TJAuNFaJ0kWom47aVAgLXbFW00di2tvTEZXUakRIq8N3WGRBDUbzrOv1 1iTqHvB6ykcViwVrxJaW1hixx0bQINyPJDpRKyxfMl04LnV0wH4o= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 8AE9A31C63; Fri, 20 Oct 2017 09:52:17 -0400 (EDT) To: FreeBSD Current , mjg@freebsd.org From: Michael Butler Subject: Build failure: non-SMP after SVN r324778 Message-ID: Date: Fri, 20 Oct 2017 09:52:16 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 13:52:20 -0000 If SMP is not defined, as it isn't on my last remaining i386 platform, the build fails with: Building /usr/obj/usr/src/sys/SARAH/kern_mutex.o --- kern_mutex.o --- /usr/src/sys/kern/kern_mutex.c:313:3: error: implicit declaration of function '_mtx_lock_spin' is invalid in C99 [-Werror,-Wimplicit-function-declaration] _mtx_lock_spin(m, v, opts, file, line); ^ /usr/src/sys/kern/kern_mutex.c:313:3: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] 2 errors generated. *** [kern_mutex.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/sys/SARAH imb From owner-freebsd-current@freebsd.org Fri Oct 20 14:04:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66217E3663F for ; Fri, 20 Oct 2017 14:04:35 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 171DF77927; Fri, 20 Oct 2017 14:04:35 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qk0-x229.google.com with SMTP id y23so14406225qkb.10; Fri, 20 Oct 2017 07:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oB0RdFsSD6Ts3egE/T3/z3gDMWsLhfOLnHQ+JCT1Aww=; b=FMYwF5eNKdURTMnc0QwDBJZM/EMresKRYemF+eVeOJQJWDkWg0dswTphic3POajgFl sSFN2iSwpvGhTp/yc2sO7NVN/EwtBrEBSjRrTwUbDBXg1E/7QrKNubZXVFIsTdzh6v9p /iB+h2HDvL7vhv1HF67ONHoO88AfKwp6G2Ccoo2W1iRR6R1O0wfUlOOa4Vsv4KsHrXiX F5G39f8h4WCrssuJj+KgBUWq5wQloTUbuCFfFi/3aQ4ma/P/MkTR41WFCjhafHmZmkYa YkCaVSkHMOoH90iEhofQYnDJvDq5xWw4CMveIRYrG+wefCNu8ta+zXhQpU/753zW+g9f 6DBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oB0RdFsSD6Ts3egE/T3/z3gDMWsLhfOLnHQ+JCT1Aww=; b=rRbDbBm2C8HK0rq5fCRDFeekH+W9Q7PZz/3FuZng5MxaO/NdndoEX1giSob+2t+ObI 2jXckXt8k2DBHsFCiwEHyz0nSuIIwVxih0hwYmidflQK6mQE93RNsuTR+g6VXsQVymz+ e++zNyVNaePLJnx45Qm1bI6bpF0LWJNRkK2XASGOGL4Py7q1t8ZgMLgGLS8SGL7dxpNh Tzqi/aNcHdQVEP9Yg6q8Y1NtwNN3ckC92AzFW7Y/iUhAhWewIcF5WdSQ8f7SMPi1kB+7 ZOmcexJWKekXZGRPKXTOQpgIfnE+40y2eRu8wrYhLEHxnUeB3PBbqpyOnmCYZMTzgMhE H5pg== X-Gm-Message-State: AMCzsaWeiu6ETM80bghEZnmDDEx+C2EfC/I1Wd60bngKfxWu6VeUH8Ud R8zJ6vGeTs+oYZvPNLnns3KiMpzb7ZrfSGF09PXUiw== X-Google-Smtp-Source: ABhQp+QL9CZ9MdSt58LjowanyVIT+fkrXe265qQst266CxXcugLEM1Q4FkkqpPfGMaryzrvHpCD72yjyG8rCKv/JKaw= X-Received: by 10.55.204.157 with SMTP id n29mr6498917qkl.243.1508508274196; Fri, 20 Oct 2017 07:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.51.167 with HTTP; Fri, 20 Oct 2017 07:04:33 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Fri, 20 Oct 2017 16:04:33 +0200 Message-ID: Subject: Re: Build failure: non-SMP after SVN r324778 To: Michael Butler Cc: FreeBSD Current , Mateusz Guzik Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 14:04:35 -0000 On Fri, Oct 20, 2017 at 3:52 PM, Michael Butler wrote: > If SMP is not defined, as it isn't on my last remaining i386 platform, the > build fails with: > > Building /usr/obj/usr/src/sys/SARAH/kern_mutex.o > --- kern_mutex.o --- > /usr/src/sys/kern/kern_mutex.c:313:3: error: implicit declaration of > function '_mtx_lock_spin' is invalid in C99 [-Werror,-Wimplicit-function-d > eclaration] > _mtx_lock_spin(m, v, opts, file, line); > ^ > /usr/src/sys/kern/kern_mutex.c:313:3: error: this function declaration is > not a prototype [-Werror,-Wstrict-prototypes] > 2 errors generated. > *** [kern_mutex.o] Error code 1 > > oops, fixed in r324803. -- Mateusz Guzik From owner-freebsd-current@freebsd.org Fri Oct 20 15:12:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88EB8E383B7 for ; Fri, 20 Oct 2017 15:12:15 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C8C47EAF2 for ; Fri, 20 Oct 2017 15:12:15 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 13fd320e-b5a9-11e7-a938-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 13fd320e-b5a9-11e7-a938-4f970e858fdb; Fri, 20 Oct 2017 15:12:25 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9KFC7bl011269; Fri, 20 Oct 2017 09:12:07 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508512327.1383.55.camel@freebsd.org> Subject: Re: host, bhyve vm and ntpd From: Ian Lepore To: Boris Samorodov , freebsd-current@FreeBSD.org Date: Fri, 20 Oct 2017 09:12:07 -0600 In-Reply-To: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:12:15 -0000 On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > Hi All, > > I have got a host: > --- > bhyve-host% uname -a > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug > 25 05:25:26 MSK 2017 > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64 > --- > > And a bhyve vm: > --- > bhyve-vm: uname -a > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri > Oct 20 05:12:17 MSK 2017 > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64 > --- > > The only difference at kernel configs is a colored console. :-) > > And here I get some weird (is it?) result at the VM (I expect ntpd to be > more stable): > --- > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done >      remote           refid      st t when poll reach   delay   offset > jitter > ============================================================================== >  XX.XX.XX.1      XX.XX.XX.245     4 u    9   64    3    0.605   -1.202 > 316.407 >  XX.XX.XX.1      XX.XX.XX.245     4 u    7   64    7    0.605   -1.202 > 358.395 > *XX.XX.XX.1      XX.XX.XX.245     4 u    5   64   17    0.615  -328.42 > 181.405 > *XX.XX.XX.1      XX.XX.XX.245     4 u    3   64   37    0.615  -328.42 > 214.868 > *XX.XX.XX.1      XX.XX.XX.245     4 u   67   64   37    0.615  -328.42 > 214.868 > *XX.XX.XX.1      XX.XX.XX.245     4 u   63   64   77    0.615  -328.42 > 268.618 > *XX.XX.XX.1      XX.XX.XX.245     4 u   60   64  177    0.615  -328.42 > 333.175 >  XX.XX.XX.1      .STEP.          16 u 1910   64    0    0.000    0.000 > 0.000 >  XX.XX.XX.1      XX.XX.XX.245     4 u   27   64    1    0.703  -262.63 > 0.004 >  XX.XX.XX.1      XX.XX.XX.245     4 u   31   64    1    0.649  -331.43 > 68.800 > --- > > At the same time host's results are very stable: > --- > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done >      remote           refid      st t when poll reach   delay   offset > jitter > ============================================================================== > > > > *XX.XX.XX.1      XX.XX.XX.245     4 u    1   64    1    0.401    0.176 > 0.106 > *XX.XX.XX.1      XX.XX.XX.245     4 u    6   64    3    0.401    0.176 > 0.459 > *XX.XX.XX.1      XX.XX.XX.245     4 u    3   64    7    0.401    0.176 > 0.940 > *XX.XX.XX.1      XX.XX.XX.245     4 u   67   64    7    0.401    0.176 > 0.940 > *XX.XX.XX.1      XX.XX.XX.245     4 u   64   64   17    0.401    0.176 > 1.566 > *XX.XX.XX.1      XX.XX.XX.245     4 u   60   64   37    0.448    1.275 > 1.739 > *XX.XX.XX.1      XX.XX.XX.245     4 u   55   64   77    0.448    1.275 > 2.365 > *XX.XX.XX.1      XX.XX.XX.245     4 u   53   64  177    0.448    1.275 > 3.110 > *XX.XX.XX.1      XX.XX.XX.245     4 u   50   64  377    0.448    1.275 > 3.929 > *XX.XX.XX.1      XX.XX.XX.245     4 u   45   64  377    0.443    8.750 > 4.722 > --- > > The network is organized via bridge -- host igb and vm tap interfaces > are members of one bridge. > > Are those results expected? Does it smell like a bug? Should I dig > furter? > So it is repeatedly stepping the clock in the VM? (Set kern.timecounter.stepwarnings=1 to log steps).  That is usually a sign that the chosen timecounter is running at a different frequency than it claimed to be when it registered itself -- the host may not be emulating the timer hardware properly in the guest.  What is the output of sysctl kern.timecounter in the vm? Also, what is the output of ntptime(8) in the vm? -- Ian From owner-freebsd-current@freebsd.org Fri Oct 20 15:31:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D854E38DCC for ; Fri, 20 Oct 2017 15:31:51 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward105o.mail.yandex.net (forward105o.mail.yandex.net [37.140.190.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D72917FB47; Fri, 20 Oct 2017 15:31:50 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback6g.mail.yandex.net (mxback6g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:167]) by forward105o.mail.yandex.net (Yandex) with ESMTP id EF66944439A6; Fri, 20 Oct 2017 18:31:46 +0300 (MSK) Received: from smtp1p.mail.yandex.net (smtp1p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:6]) by mxback6g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id XUs0kX7ZBG-VkiCrAOX; Fri, 20 Oct 2017 18:31:46 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508513506; bh=0852y1Nj/1GXoMp4zN0n3Z51z65QNxUwR79QWShXLIU=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=SvnlisipU2psINpYI9AGSF30X4/wzO8EXS3iq4U+PxUx3DMd0cyyt5i6+B0VLJiQ5 lmQxoMtjIDRnd2ANFIJy+IrS05prlKslYvPZ2i8UYpQ8khPXG1OXR4baSUFa//9OYV xTZ4iCfp5f3yoGDJWs5Qsy7vV5NlgWpp2lX+vJ1Y= Received: by smtp1p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id y9fTkzuwg7-VkdSmrpW; Fri, 20 Oct 2017 18:31:46 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508513506; bh=0852y1Nj/1GXoMp4zN0n3Z51z65QNxUwR79QWShXLIU=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=SvnlisipU2psINpYI9AGSF30X4/wzO8EXS3iq4U+PxUx3DMd0cyyt5i6+B0VLJiQ5 lmQxoMtjIDRnd2ANFIJy+IrS05prlKslYvPZ2i8UYpQ8khPXG1OXR4baSUFa//9OYV xTZ4iCfp5f3yoGDJWs5Qsy7vV5NlgWpp2lX+vJ1Y= Authentication-Results: smtp1p.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: host, bhyve vm and ntpd To: Ian Lepore , freebsd-current@FreeBSD.org References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> From: Boris Samorodov Message-ID: <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> Date: Fri, 20 Oct 2017 18:31:46 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1508512327.1383.55.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:31:51 -0000 20.10.2017 18:12, Ian Lepore ΠΏΠΈΡˆΠ΅Ρ‚: > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: >> Hi All, >> >> I have got a host: >> --- >> bhyve-host% uname -a >> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug >> 25 05:25:26 MSK 2017 >> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FASTΒ Β amd64 amd64 >> --- >> >> And a bhyve vm: >> --- >> bhyve-vm: uname -a >> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri >> Oct 20 05:12:17 MSK 2017 >> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64XΒ Β amd64 amd64 >> --- >> >> The only difference at kernel configs is a colored console. :-) >> >> And here I get some weird (is it?) result at the VM (I expect ntpd to be >> more stable): >> --- >> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done >> Β Β Β Β Β remoteΒ Β Β Β Β Β Β Β Β Β Β refidΒ Β Β Β Β Β st t when poll reachΒ Β Β delayΒ Β Β offset >> jitter >> ============================================================================== >> Β XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 9Β Β Β 64Β Β Β Β 3Β Β Β Β 0.605Β Β Β -1.202 >> 316.407 >> Β XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 7Β Β Β 64Β Β Β Β 7Β Β Β Β 0.605Β Β Β -1.202 >> 358.395 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 5Β Β Β 64Β Β Β 17Β Β Β Β 0.615Β Β -328.42 >> 181.405 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 3Β Β Β 64Β Β Β 37Β Β Β Β 0.615Β Β -328.42 >> 214.868 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 67Β Β Β 64Β Β Β 37Β Β Β Β 0.615Β Β -328.42 >> 214.868 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 63Β Β Β 64Β Β Β 77Β Β Β Β 0.615Β Β -328.42 >> 268.618 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 60Β Β Β 64Β Β 177Β Β Β Β 0.615Β Β -328.42 >> 333.175 >> Β XX.XX.XX.1Β Β Β Β Β Β .STEP.Β Β Β Β Β Β Β Β Β Β 16 u 1910Β Β Β 64Β Β Β Β 0Β Β Β Β 0.000Β Β Β Β 0.000 >> 0.000 >> Β XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 27Β Β Β 64Β Β Β Β 1Β Β Β Β 0.703Β Β -262.63 >> 0.004 >> Β XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 31Β Β Β 64Β Β Β Β 1Β Β Β Β 0.649Β Β -331.43 >> 68.800 >> --- >> >> At the same time host's results are very stable: >> --- >> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done >> Β Β Β Β Β remoteΒ Β Β Β Β Β Β Β Β Β Β refidΒ Β Β Β Β Β st t when poll reachΒ Β Β delayΒ Β Β offset >> jitter >> ============================================================================== >> >> >> >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 1Β Β Β 64Β Β Β Β 1Β Β Β Β 0.401Β Β Β Β 0.176 >> 0.106 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 6Β Β Β 64Β Β Β Β 3Β Β Β Β 0.401Β Β Β Β 0.176 >> 0.459 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 3Β Β Β 64Β Β Β Β 7Β Β Β Β 0.401Β Β Β Β 0.176 >> 0.940 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 67Β Β Β 64Β Β Β Β 7Β Β Β Β 0.401Β Β Β Β 0.176 >> 0.940 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 64Β Β Β 64Β Β Β 17Β Β Β Β 0.401Β Β Β Β 0.176 >> 1.566 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 60Β Β Β 64Β Β Β 37Β Β Β Β 0.448Β Β Β Β 1.275 >> 1.739 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 55Β Β Β 64Β Β Β 77Β Β Β Β 0.448Β Β Β Β 1.275 >> 2.365 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 53Β Β Β 64Β Β 177Β Β Β Β 0.448Β Β Β Β 1.275 >> 3.110 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 50Β Β Β 64Β Β 377Β Β Β Β 0.448Β Β Β Β 1.275 >> 3.929 >> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 45Β Β Β 64Β Β 377Β Β Β Β 0.443Β Β Β Β 8.750 >> 4.722 >> --- >> >> The network is organized via bridge -- host igb and vm tap interfaces >> are members of one bridge. >> >> Are those results expected? Does it smell like a bug? Should I dig >> furter? >> > > So it is repeatedly stepping the clock in the VM? (Set > kern.timecounter.stepwarnings=1 to log steps). No kernel/ntpd messages for 20 minutes after setting this sysctl. > Β That is usually a sign > that the chosen timecounter is running at a different frequency than it > claimed to be when it registered itself -- the host may not be > emulating the timer hardware properly in the guest. Β What is the output > of sysctl kern.timecounter in the vm? --- bhyve-vm% sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) dummy(-1000000) kern.timecounter.hardware: HPET kern.timecounter.alloweddeviation: 5 kern.timecounter.stepwarnings: 1 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 4161213491 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 10000000 kern.timecounter.tc.HPET.counter: 3518036865 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 47597 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: -100 kern.timecounter.tc.TSC-low.frequency: 1199886114 kern.timecounter.tc.TSC-low.counter: 1274338278 kern.timecounter.tc.TSC-low.mask: 4294967295 --- > Also, what is the output of ntptime(8) in the vm? --- bhyve-vm% ntptime ntp_gettime() returns code 0 (OK) time dd94930f.20ea2900 Fri, Oct 20 2017 18:21:51.128, (.128573699), maximum error 1309110 us, estimated error 3 us, TAI offset 37 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency 0.000 ppm, interval 1 s, maximum error 1309110 us, estimated error 3 us, status 0x2001 (PLL,NANO), time constant 6, precision 0.001 us, tolerance 496 ppm, --- Ian, thank you for your help! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@freebsd.org Fri Oct 20 15:36:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07013E3900E for ; Fri, 20 Oct 2017 15:36:46 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward101p.mail.yandex.net (forward101p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D0D58003E; Fri, 20 Oct 2017 15:36:45 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback8o.mail.yandex.net (mxback8o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::22]) by forward101p.mail.yandex.net (Yandex) with ESMTP id B642E6A8205C; Fri, 20 Oct 2017 18:36:25 +0300 (MSK) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [2a02:6b8:0:1a2d::28]) by mxback8o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 3nHy3BRavv-aPJKipDh; Fri, 20 Oct 2017 18:36:25 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508513785; bh=K5EY+2I1k+oI5mnQD+yGlgFhIMFkCn4vNIuxzS8e4Wk=; h=Subject:From:To:References:Message-ID:Date:In-Reply-To; b=kRJqmML0DIBxOgVKX1im+1vNklncpG5R6LhhpnvPrvhXgTBi//psChpwL6S6xiinD dpwYh3a4OG6nJDLDugNcrUG2+xQz1sjJSe1fiQ5R7RWLEAAp3hYqDwH/cQKTpIprH6 oQa8VWngMdToxVMLep/XF5h84SsJvyUNXp69a9gc= Received: by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id kdFbwMjPD4-aP98dnAP; Fri, 20 Oct 2017 18:36:25 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508513785; bh=K5EY+2I1k+oI5mnQD+yGlgFhIMFkCn4vNIuxzS8e4Wk=; h=Subject:From:To:References:Message-ID:Date:In-Reply-To; b=kRJqmML0DIBxOgVKX1im+1vNklncpG5R6LhhpnvPrvhXgTBi//psChpwL6S6xiinD dpwYh3a4OG6nJDLDugNcrUG2+xQz1sjJSe1fiQ5R7RWLEAAp3hYqDwH/cQKTpIprH6 oQa8VWngMdToxVMLep/XF5h84SsJvyUNXp69a9gc= Authentication-Results: smtp4o.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: host, bhyve vm and ntpd From: Boris Samorodov To: Ian Lepore , freebsd-current@FreeBSD.org References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> Message-ID: Date: Fri, 20 Oct 2017 18:36:24 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:36:46 -0000 20.10.2017 18:31, Boris Samorodov ΠΏΠΈΡˆΠ΅Ρ‚: > 20.10.2017 18:12, Ian Lepore ΠΏΠΈΡˆΠ΅Ρ‚: >> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: >>> Hi All, >>> >>> I have got a host: >>> --- >>> bhyve-host% uname -a >>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug >>> 25 05:25:26 MSK 2017 >>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FASTΒ Β amd64 amd64 >>> --- >>> >>> And a bhyve vm: >>> --- >>> bhyve-vm: uname -a >>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri >>> Oct 20 05:12:17 MSK 2017 >>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64XΒ Β amd64 amd64 >>> --- >>> >>> The only difference at kernel configs is a colored console. :-) >>> >>> And here I get some weird (is it?) result at the VM (I expect ntpd to be >>> more stable): >>> --- >>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done >>> Β Β Β Β Β remoteΒ Β Β Β Β Β Β Β Β Β Β refidΒ Β Β Β Β Β st t when poll reachΒ Β Β delayΒ Β Β offset >>> jitter >>> ============================================================================== >>> Β XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 9Β Β Β 64Β Β Β Β 3Β Β Β Β 0.605Β Β Β -1.202 >>> 316.407 >>> Β XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 7Β Β Β 64Β Β Β Β 7Β Β Β Β 0.605Β Β Β -1.202 >>> 358.395 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 5Β Β Β 64Β Β Β 17Β Β Β Β 0.615Β Β -328.42 >>> 181.405 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 3Β Β Β 64Β Β Β 37Β Β Β Β 0.615Β Β -328.42 >>> 214.868 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 67Β Β Β 64Β Β Β 37Β Β Β Β 0.615Β Β -328.42 >>> 214.868 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 63Β Β Β 64Β Β Β 77Β Β Β Β 0.615Β Β -328.42 >>> 268.618 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 60Β Β Β 64Β Β 177Β Β Β Β 0.615Β Β -328.42 >>> 333.175 >>> Β XX.XX.XX.1Β Β Β Β Β Β .STEP.Β Β Β Β Β Β Β Β Β Β 16 u 1910Β Β Β 64Β Β Β Β 0Β Β Β Β 0.000Β Β Β Β 0.000 >>> 0.000 >>> Β XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 27Β Β Β 64Β Β Β Β 1Β Β Β Β 0.703Β Β -262.63 >>> 0.004 >>> Β XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 31Β Β Β 64Β Β Β Β 1Β Β Β Β 0.649Β Β -331.43 >>> 68.800 >>> --- >>> >>> At the same time host's results are very stable: >>> --- >>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done >>> Β Β Β Β Β remoteΒ Β Β Β Β Β Β Β Β Β Β refidΒ Β Β Β Β Β st t when poll reachΒ Β Β delayΒ Β Β offset >>> jitter >>> ============================================================================== >>> >>> >>> >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 1Β Β Β 64Β Β Β Β 1Β Β Β Β 0.401Β Β Β Β 0.176 >>> 0.106 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 6Β Β Β 64Β Β Β Β 3Β Β Β Β 0.401Β Β Β Β 0.176 >>> 0.459 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β Β 3Β Β Β 64Β Β Β Β 7Β Β Β Β 0.401Β Β Β Β 0.176 >>> 0.940 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 67Β Β Β 64Β Β Β Β 7Β Β Β Β 0.401Β Β Β Β 0.176 >>> 0.940 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 64Β Β Β 64Β Β Β 17Β Β Β Β 0.401Β Β Β Β 0.176 >>> 1.566 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 60Β Β Β 64Β Β Β 37Β Β Β Β 0.448Β Β Β Β 1.275 >>> 1.739 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 55Β Β Β 64Β Β Β 77Β Β Β Β 0.448Β Β Β Β 1.275 >>> 2.365 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 53Β Β Β 64Β Β 177Β Β Β Β 0.448Β Β Β Β 1.275 >>> 3.110 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 50Β Β Β 64Β Β 377Β Β Β Β 0.448Β Β Β Β 1.275 >>> 3.929 >>> *XX.XX.XX.1Β Β Β Β Β Β XX.XX.XX.245Β Β Β Β Β 4 uΒ Β Β 45Β Β Β 64Β Β 377Β Β Β Β 0.443Β Β Β Β 8.750 >>> 4.722 >>> --- >>> >>> The network is organized via bridge -- host igb and vm tap interfaces >>> are members of one bridge. >>> >>> Are those results expected? Does it smell like a bug? Should I dig >>> furter? >>> >> >> So it is repeatedly stepping the clock in the VM? (Set >> kern.timecounter.stepwarnings=1 to log steps). > > No kernel/ntpd messages for 20 minutes after setting this sysctl. > >> Β That is usually a sign >> that the chosen timecounter is running at a different frequency than it >> claimed to be when it registered itself -- the host may not be >> emulating the timer hardware properly in the guest. Β What is the output >> of sysctl kern.timecounter in the vm? > > --- > bhyve-vm% sysctl kern.timecounter > > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) > dummy(-1000000) > kern.timecounter.hardware: HPET > kern.timecounter.alloweddeviation: 5 > kern.timecounter.stepwarnings: 1 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 4161213491 > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 10000000 > kern.timecounter.tc.HPET.counter: 3518036865 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 47597 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.TSC-low.quality: -100 > kern.timecounter.tc.TSC-low.frequency: 1199886114 > kern.timecounter.tc.TSC-low.counter: 1274338278 > kern.timecounter.tc.TSC-low.mask: 4294967295 > --- BTW, here is the host kern.timecounter: --- kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) dummy(-1000000) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 9047194 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 2232552795 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 43410 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1200067168 kern.timecounter.tc.TSC-low.counter: 2463146362 kern.timecounter.tc.TSC-low.mask: 4294967295 --- >> Also, what is the output of ntptime(8) in the vm? > > --- > bhyve-vm% ntptime > > ntp_gettime() returns code 0 (OK) > time dd94930f.20ea2900 Fri, Oct 20 2017 18:21:51.128, (.128573699), > maximum error 1309110 us, estimated error 3 us, TAI offset 37 > ntp_adjtime() returns code 0 (OK) > modes 0x0 (), > offset 0.000 us, frequency 0.000 ppm, interval 1 s, > maximum error 1309110 us, estimated error 3 us, > status 0x2001 (PLL,NANO), > time constant 6, precision 0.001 us, tolerance 496 ppm, > --- > > Ian, thank you for your help! > -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@freebsd.org Fri Oct 20 15:41:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CE8FE39386 for ; Fri, 20 Oct 2017 15:41:36 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward101p.mail.yandex.net (forward101p.mail.yandex.net [77.88.28.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01316803EC; Fri, 20 Oct 2017 15:41:35 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback3o.mail.yandex.net (mxback3o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1d]) by forward101p.mail.yandex.net (Yandex) with ESMTP id ED8B16A81FE3; Fri, 20 Oct 2017 18:41:30 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback3o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id xw2eOpLyc2-fUoqE2nA; Fri, 20 Oct 2017 18:41:30 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508514090; bh=+w4sKeTCvglmWwmnKRleJ0EJUFiROCIQVY2VpGrbBe0=; h=Subject:From:To:References:Message-ID:Date:In-Reply-To; b=D7YImw1c/ys6iav9a/hhF8Uyhj/RrANOep9scwR++ug68yRh4s+IJSUl4/+DWStW0 RbACMDjnucJx9nVS0pLtcBvAHaukjeTwsDb6HlLa9w+1n1BuUnKHPvwCbgE/veHWKt vkcPXXBrsfuwCGeqZq38CiKW+i3LZs3CDBncVXdE= Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id xbelRvYljr-fUPWeS2n; Fri, 20 Oct 2017 18:41:30 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508514090; bh=+w4sKeTCvglmWwmnKRleJ0EJUFiROCIQVY2VpGrbBe0=; h=Subject:From:To:References:Message-ID:Date:In-Reply-To; b=D7YImw1c/ys6iav9a/hhF8Uyhj/RrANOep9scwR++ug68yRh4s+IJSUl4/+DWStW0 RbACMDjnucJx9nVS0pLtcBvAHaukjeTwsDb6HlLa9w+1n1BuUnKHPvwCbgE/veHWKt vkcPXXBrsfuwCGeqZq38CiKW+i3LZs3CDBncVXdE= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: host, bhyve vm and ntpd From: Boris Samorodov To: Ian Lepore , freebsd-current@FreeBSD.org References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> Message-ID: <4527e5e0-d30e-504c-e08e-a06d966e9372@passap.ru> Date: Fri, 20 Oct 2017 18:41:30 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:41:36 -0000 20.10.2017 18:31, Boris Samorodov ΠΏΠΈΡˆΠ΅Ρ‚: > 20.10.2017 18:12, Ian Lepore ΠΏΠΈΡˆΠ΅Ρ‚: >> So it is repeatedly stepping the clock in the VM? (Set >> kern.timecounter.stepwarnings=1 to log steps). > No kernel/ntpd messages for 20 minutes after setting this sysctl. Sorry for multiply answers. The kernel message has just arrived: --- Oct 20 18:31:25 builder kernel: Time stepped from 1508513486.200998799 to 1508513485.317299999 (1508513485.316858000) --- So, you are right, the time is stepped. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@freebsd.org Fri Oct 20 16:32:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63D5FE3A3CA for ; Fri, 20 Oct 2017 16:32:44 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4572781ECD for ; Fri, 20 Oct 2017 16:32:43 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 3091dd6a-b5b4-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 3091dd6a-b5b4-11e7-b50b-53dc5ecda239; Fri, 20 Oct 2017 16:31:57 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9KGWeDq011455; Fri, 20 Oct 2017 10:32:41 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508517160.1383.63.camel@freebsd.org> Subject: Re: host, bhyve vm and ntpd From: Ian Lepore To: Boris Samorodov , freebsd-current@FreeBSD.org Date: Fri, 20 Oct 2017 10:32:40 -0600 In-Reply-To: References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> Content-Type: text/plain; charset="koi8-r" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:32:44 -0000 On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: > 20.10.2017 18:31, Boris Samorodov ΠΙΫΕΤ: > > > > 20.10.2017 18:12, Ian Lepore ΠΙΫΕΤ: > > > > > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > > > > > > > > Hi All, > > > > > > > > I have got a host: > > > > --- > > > > bhyve-host% uname -a > > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug > > > > 25 05:25:26 MSK 2017 > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FASTššamd64 amd64 > > > > --- > > > > > > > > And a bhyve vm: > > > > --- > > > > bhyve-vm: uname -a > > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri > > > > Oct 20 05:12:17 MSK 2017 > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64Xššamd64 amd64 > > > > --- > > > > > > > > The only difference at kernel configs is a colored console. :-) > > > > > > > > And here I get some weird (is it?) result at the VM (I expect ntpd to be > > > > more stable): > > > > --- > > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset > > > > jitter > > > > ============================================================================== > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš9ššš64šššš3šššš0.605ššš-1.202 > > > > 316.407 > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš7ššš64šššš7šššš0.605ššš-1.202 > > > > 358.395 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš5ššš64ššš17šššš0.615šš-328.42 > > > > 181.405 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64ššš37šššš0.615šš-328.42 > > > > 214.868 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64ššš37šššš0.615šš-328.42 > > > > 214.868 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš63ššš64ššš77šššš0.615šš-328.42 > > > > 268.618 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64šš177šššš0.615šš-328.42 > > > > 333.175 > > > > šXX.XX.XX.1šššššš.STEP.šššššššššš16 u 1910ššš64šššš0šššš0.000šššš0.000 > > > > 0.000 > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš27ššš64šššš1šššš0.703šš-262.63 > > > > 0.004 > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš31ššš64šššš1šššš0.649šš-331.43 > > > > 68.800 > > > > --- > > > > > > > > At the same time host's results are very stable: > > > > --- > > > > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset > > > > jitter > > > > ============================================================================== > > > > > > > > > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš1ššš64šššš1šššš0.401šššš0.176 > > > > 0.106 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš6ššš64šššš3šššš0.401šššš0.176 > > > > 0.459 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64šššš7šššš0.401šššš0.176 > > > > 0.940 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64šššš7šššš0.401šššš0.176 > > > > 0.940 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš64ššš64ššš17šššš0.401šššš0.176 > > > > 1.566 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64ššš37šššš0.448šššš1.275 > > > > 1.739 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš55ššš64ššš77šššš0.448šššš1.275 > > > > 2.365 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš53ššš64šš177šššš0.448šššš1.275 > > > > 3.110 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš50ššš64šš377šššš0.448šššš1.275 > > > > 3.929 > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš45ššš64šš377šššš0.443šššš8.750 > > > > 4.722 > > > > --- > > > > > > > > The network is organized via bridge -- host igb and vm tap interfaces > > > > are members of one bridge. > > > > > > > > Are those results expected? Does it smell like a bug? Should I dig > > > > furter? > > > > > > > So it is repeatedly stepping the clock in the VM? (Set > > > kern.timecounter.stepwarnings=1 to log steps). > > No kernel/ntpd messages for 20 minutes after setting this sysctl. > > > > > > > > šThat is usually a sign > > > that the chosen timecounter is running at a different frequency than it > > > claimed to be when it registered itself -- the host may not be > > > emulating the timer hardware properly in the guest. šWhat is the output > > > of sysctl kern.timecounter in the vm? > > --- > > bhyve-vm% sysctl kern.timecounter > > > > kern.timecounter.tsc_shift: 1 > > kern.timecounter.smp_tsc_adjust: 0 > > kern.timecounter.smp_tsc: 0 > > kern.timecounter.invariant_tsc: 1 > > kern.timecounter.fast_gettime: 1 > > kern.timecounter.tick: 1 > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) > > dummy(-1000000) > > kern.timecounter.hardware: HPET > > kern.timecounter.alloweddeviation: 5 > > kern.timecounter.stepwarnings: 1 > > kern.timecounter.tc.ACPI-fast.quality: 900 > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > kern.timecounter.tc.ACPI-fast.counter: 4161213491 > > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > > kern.timecounter.tc.HPET.quality: 950 > > kern.timecounter.tc.HPET.frequency: 10000000 > > kern.timecounter.tc.HPET.counter: 3518036865 > > kern.timecounter.tc.HPET.mask: 4294967295 > > kern.timecounter.tc.i8254.quality: 0 > > kern.timecounter.tc.i8254.frequency: 1193182 > > kern.timecounter.tc.i8254.counter: 47597 > > kern.timecounter.tc.i8254.mask: 65535 > > kern.timecounter.tc.TSC-low.quality: -100 > > kern.timecounter.tc.TSC-low.frequency: 1199886114 > > kern.timecounter.tc.TSC-low.counter: 1274338278 > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > --- > BTW, here is the host kern.timecounter: > --- > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > dummy(-1000000) > kern.timecounter.hardware: TSC-low > kern.timecounter.alloweddeviation: 5 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 9047194 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.counter: 2232552795 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 43410 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.tc.TSC-low.frequency: 1200067168 > kern.timecounter.tc.TSC-low.counter: 2463146362 > kern.timecounter.tc.TSC-low.mask: 4294967295 > --- > > > > > > > > > Also, what is the output of ntptime(8) in the vm? > > --- > > bhyve-vm% ntptime > > > > ntp_gettime() returns code 0 (OK) > > š time dd94930f.20ea2900ššFri, Oct 20 2017 18:21:51.128, (.128573699), > > š maximum error 1309110 us, estimated error 3 us, TAI offset 37 > > ntp_adjtime() returns code 0 (OK) > > š modes 0x0 (), > > š offset 0.000 us, frequency 0.000 ppm, interval 1 s, > > š maximum error 1309110 us, estimated error 3 us, > > š status 0x2001 (PLL,NANO), > > š time constant 6, precision 0.001 us, tolerance 496 ppm, > > --- > > > > Ian, thank you for your help! > > > It seems odd to me that the frequency of the host HPET is 14.3mhz and that of the guest is 10.0mhz, but maybe that's a normal condition for bhyve. šI did find some google hits[1] for bhyve guest timekeeping trouble with the HPET timer which was solved by switching to a different timecounter. šTimecounter choices can't be controlled from loader.conf, so I guess a sysctl.conf entry of kern.timecounter.hardware="ACPI-fast" is the only way to fix that. šYou can also just do that command interactively first and see if it stops the time steps and ntp settles down. This would be a workaround, not a fix per se. šIf the time steps go away, then something in bhyve's emulation of HPET (maybe only on some hardware?) must be buggy. [1] https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-April/003492.html -- Ian From owner-freebsd-current@freebsd.org Fri Oct 20 17:20:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA459E3B472; Fri, 20 Oct 2017 17:20:14 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward102j.mail.yandex.net (forward102j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BDDD837C4; Fri, 20 Oct 2017 17:20:11 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback13j.mail.yandex.net (mxback13j.mail.yandex.net [IPv6:2a02:6b8:0:1619::88]) by forward102j.mail.yandex.net (Yandex) with ESMTP id C1179560560C; Fri, 20 Oct 2017 20:20:07 +0300 (MSK) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback13j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id CTJIjMd24C-K7faKnAg; Fri, 20 Oct 2017 20:20:07 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508520007; bh=gP3qVzWMC8Hr5UFe9Rdetfpko3h0tO5kTA5xixVF2bU=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=dhPIuXJD99ty+usMvKJ7yJ9TMzcr++ppeHJlRuZW3AlBfFAyo0wKcBXlqmCIItiOw 6L2RoAlsnUB8UTX5nwe/At0e/Du2KyefTsscSvnwmWX4185kqMuX2Vo0+q/NHANxpu fzJxx2auTe+2ocFrLccxeNgFy77U1Pyb3plChoVc= Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id vNW5MEB0Yn-K7w0FMN1; Fri, 20 Oct 2017 20:20:07 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508520007; bh=gP3qVzWMC8Hr5UFe9Rdetfpko3h0tO5kTA5xixVF2bU=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=dhPIuXJD99ty+usMvKJ7yJ9TMzcr++ppeHJlRuZW3AlBfFAyo0wKcBXlqmCIItiOw 6L2RoAlsnUB8UTX5nwe/At0e/Du2KyefTsscSvnwmWX4185kqMuX2Vo0+q/NHANxpu fzJxx2auTe+2ocFrLccxeNgFy77U1Pyb3plChoVc= Authentication-Results: smtp1j.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: host, bhyve vm and ntpd To: Ian Lepore , freebsd-current@FreeBSD.org, freebsd-virtualization@FreeBSD.org References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> <1508517160.1383.63.camel@freebsd.org> From: Boris Samorodov Message-ID: <76ff7afb-3d3a-96f6-1275-89472ff5683d@passap.ru> Date: Fri, 20 Oct 2017 20:20:06 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1508517160.1383.63.camel@freebsd.org> Content-Type: text/plain; charset=koi8-r Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 17:20:15 -0000 (CC to freebsd-virtualization@) 20.10.2017 19:32, Ian Lepore ΠΙΫΕΤ: > On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: >> 20.10.2017 18:31, Boris Samorodov ΠΙΫΕΤ: >>> >>> 20.10.2017 18:12, Ian Lepore ΠΙΫΕΤ: >>>> >>>> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I have got a host: >>>>> --- >>>>> bhyve-host% uname -a >>>>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug >>>>> 25 05:25:26 MSK 2017 >>>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FASTššamd64 amd64 >>>>> --- >>>>> >>>>> And a bhyve vm: >>>>> --- >>>>> bhyve-vm: uname -a >>>>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri >>>>> Oct 20 05:12:17 MSK 2017 >>>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64Xššamd64 amd64 >>>>> --- >>>>> >>>>> The only difference at kernel configs is a colored console. :-) >>>>> >>>>> And here I get some weird (is it?) result at the VM (I expect ntpd to be >>>>> more stable): >>>>> --- >>>>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done >>>>> šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset >>>>> jitter >>>>> ============================================================================== >>>>> šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš9ššš64šššš3šššš0.605ššš-1.202 >>>>> 316.407 >>>>> šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš7ššš64šššš7šššš0.605ššš-1.202 >>>>> 358.395 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš5ššš64ššš17šššš0.615šš-328.42 >>>>> 181.405 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64ššš37šššš0.615šš-328.42 >>>>> 214.868 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64ššš37šššš0.615šš-328.42 >>>>> 214.868 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš63ššš64ššš77šššš0.615šš-328.42 >>>>> 268.618 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64šš177šššš0.615šš-328.42 >>>>> 333.175 >>>>> šXX.XX.XX.1šššššš.STEP.šššššššššš16 u 1910ššš64šššš0šššš0.000šššš0.000 >>>>> 0.000 >>>>> šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš27ššš64šššš1šššš0.703šš-262.63 >>>>> 0.004 >>>>> šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš31ššš64šššš1šššš0.649šš-331.43 >>>>> 68.800 >>>>> --- >>>>> >>>>> At the same time host's results are very stable: >>>>> --- >>>>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done >>>>> šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset >>>>> jitter >>>>> ============================================================================== >>>>> >>>>> >>>>> >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš1ššš64šššš1šššš0.401šššš0.176 >>>>> 0.106 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš6ššš64šššš3šššš0.401šššš0.176 >>>>> 0.459 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64šššš7šššš0.401šššš0.176 >>>>> 0.940 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64šššš7šššš0.401šššš0.176 >>>>> 0.940 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš64ššš64ššš17šššš0.401šššš0.176 >>>>> 1.566 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64ššš37šššš0.448šššš1.275 >>>>> 1.739 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš55ššš64ššš77šššš0.448šššš1.275 >>>>> 2.365 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš53ššš64šš177šššš0.448šššš1.275 >>>>> 3.110 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš50ššš64šš377šššš0.448šššš1.275 >>>>> 3.929 >>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš45ššš64šš377šššš0.443šššš8.750 >>>>> 4.722 >>>>> --- >>>>> >>>>> The network is organized via bridge -- host igb and vm tap interfaces >>>>> are members of one bridge. >>>>> >>>>> Are those results expected? Does it smell like a bug? Should I dig >>>>> furter? >>>>> >>>> So it is repeatedly stepping the clock in the VM? (Set >>>> kern.timecounter.stepwarnings=1 to log steps). >>> No kernel/ntpd messages for 20 minutes after setting this sysctl. >>> >>>> >>>> šThat is usually a sign >>>> that the chosen timecounter is running at a different frequency than it >>>> claimed to be when it registered itself -- the host may not be >>>> emulating the timer hardware properly in the guest. šWhat is the output >>>> of sysctl kern.timecounter in the vm? >>> --- >>> bhyve-vm% sysctl kern.timecounter >>> >>> kern.timecounter.tsc_shift: 1 >>> kern.timecounter.smp_tsc_adjust: 0 >>> kern.timecounter.smp_tsc: 0 >>> kern.timecounter.invariant_tsc: 1 >>> kern.timecounter.fast_gettime: 1 >>> kern.timecounter.tick: 1 >>> kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) >>> dummy(-1000000) >>> kern.timecounter.hardware: HPET >>> kern.timecounter.alloweddeviation: 5 >>> kern.timecounter.stepwarnings: 1 >>> kern.timecounter.tc.ACPI-fast.quality: 900 >>> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >>> kern.timecounter.tc.ACPI-fast.counter: 4161213491 >>> kern.timecounter.tc.ACPI-fast.mask: 4294967295 >>> kern.timecounter.tc.HPET.quality: 950 >>> kern.timecounter.tc.HPET.frequency: 10000000 >>> kern.timecounter.tc.HPET.counter: 3518036865 >>> kern.timecounter.tc.HPET.mask: 4294967295 >>> kern.timecounter.tc.i8254.quality: 0 >>> kern.timecounter.tc.i8254.frequency: 1193182 >>> kern.timecounter.tc.i8254.counter: 47597 >>> kern.timecounter.tc.i8254.mask: 65535 >>> kern.timecounter.tc.TSC-low.quality: -100 >>> kern.timecounter.tc.TSC-low.frequency: 1199886114 >>> kern.timecounter.tc.TSC-low.counter: 1274338278 >>> kern.timecounter.tc.TSC-low.mask: 4294967295 >>> --- >> BTW, here is the host kern.timecounter: >> --- >> kern.timecounter.tsc_shift: 1 >> kern.timecounter.smp_tsc_adjust: 0 >> kern.timecounter.smp_tsc: 1 >> kern.timecounter.invariant_tsc: 1 >> kern.timecounter.fast_gettime: 1 >> kern.timecounter.tick: 1 >> kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) >> dummy(-1000000) >> kern.timecounter.hardware: TSC-low >> kern.timecounter.alloweddeviation: 5 >> kern.timecounter.stepwarnings: 0 >> kern.timecounter.tc.ACPI-fast.quality: 900 >> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >> kern.timecounter.tc.ACPI-fast.counter: 9047194 >> kern.timecounter.tc.ACPI-fast.mask: 16777215 >> kern.timecounter.tc.HPET.quality: 950 >> kern.timecounter.tc.HPET.frequency: 14318180 >> kern.timecounter.tc.HPET.counter: 2232552795 >> kern.timecounter.tc.HPET.mask: 4294967295 >> kern.timecounter.tc.i8254.quality: 0 >> kern.timecounter.tc.i8254.frequency: 1193182 >> kern.timecounter.tc.i8254.counter: 43410 >> kern.timecounter.tc.i8254.mask: 65535 >> kern.timecounter.tc.TSC-low.quality: 1000 >> kern.timecounter.tc.TSC-low.frequency: 1200067168 >> kern.timecounter.tc.TSC-low.counter: 2463146362 >> kern.timecounter.tc.TSC-low.mask: 4294967295 >> --- >> >>> >>>> >>>> Also, what is the output of ntptime(8) in the vm? >>> --- >>> bhyve-vm% ntptime >>> >>> ntp_gettime() returns code 0 (OK) >>> š time dd94930f.20ea2900ššFri, Oct 20 2017 18:21:51.128, (.128573699), >>> š maximum error 1309110 us, estimated error 3 us, TAI offset 37 >>> ntp_adjtime() returns code 0 (OK) >>> š modes 0x0 (), >>> š offset 0.000 us, frequency 0.000 ppm, interval 1 s, >>> š maximum error 1309110 us, estimated error 3 us, >>> š status 0x2001 (PLL,NANO), >>> š time constant 6, precision 0.001 us, tolerance 496 ppm, >>> --- >>> >>> Ian, thank you for your help! >>> >> > > It seems odd to me that the frequency of the host HPET is 14.3mhz and > that of the guest is 10.0mhz, but maybe that's a normal condition for > bhyve. šI did find some google hits[1] for bhyve guest timekeeping > trouble with the HPET timer which was solved by switching to a > different timecounter. šTimecounter choices can't be controlled from > loader.conf, so I guess a sysctl.conf entry of > kern.timecounter.hardware="ACPI-fast" is the only way to fix that. šYou > can also just do that command interactively first and see if it stops > the time steps and ntp settles down. The process seems to become more monotonic. But steps nevertheless: --- *XX.1 XX.245 4 u 20 64 1 0.717 -12.771 4.193 *XX.1 XX.245 4 u 28 64 3 0.751 -41.970 32.342 *XX.1 XX.245 4 u 23 64 7 0.748 -59.505 46.624 *XX.1 XX.245 4 u 18 64 17 0.699 -75.164 56.482 *XX.1 XX.245 4 u 14 64 37 0.669 -90.112 63.767 *XX.1 XX.245 4 u 11 64 77 0.605 -10.567 60.914 *XX.1 XX.245 4 u 7 64 177 0.591 -169.54 116.762 *XX.1 XX.245 4 u 3 64 377 0.591 -169.54 102.107 *XX.1 XX.245 4 u 68 64 377 0.591 -169.54 102.107 *XX.1 XX.245 4 u 63 64 377 0.591 -169.54 88.424 *XX.1 XX.245 4 u 58 64 377 0.591 -169.54 92.949 *XX.1 XX.245 4 u 55 64 377 0.591 -169.54 111.512 *XX.1 XX.245 4 u 50 64 377 0.591 -169.54 140.827 *XX.1 XX.245 4 u 45 64 377 0.591 -169.54 177.360 *XX.1 XX.245 4 u 43 64 377 0.591 -169.54 219.057 XX.1 .STEP. 16 u 588 64 0 0.000 0.000 0.000 --- > This would be a workaround, not a fix per se. šIf the time steps go > away, then something in bhyve's emulation of HPET (maybe only on some > hardware?) must be buggy. > > > [1] https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-April/003492.html Also thanks for the link. Unfortunately the problem seems to persist. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@freebsd.org Fri Oct 20 18:04:33 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DB25E3C3DC for ; Fri, 20 Oct 2017 18:04:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F2A0E91 for ; Fri, 20 Oct 2017 18:04:32 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 040a06dc-b5c1-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 040a06dc-b5c1-11e7-b50b-53dc5ecda239; Fri, 20 Oct 2017 18:03:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9KI4TbW011615; Fri, 20 Oct 2017 12:04:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508522667.1383.69.camel@freebsd.org> Subject: Re: host, bhyve vm and ntpd From: Ian Lepore To: Boris Samorodov , freebsd-current@FreeBSD.org, freebsd-virtualization@FreeBSD.org Date: Fri, 20 Oct 2017 12:04:27 -0600 In-Reply-To: <76ff7afb-3d3a-96f6-1275-89472ff5683d@passap.ru> References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> <1508517160.1383.63.camel@freebsd.org> <76ff7afb-3d3a-96f6-1275-89472ff5683d@passap.ru> Content-Type: text/plain; charset="koi8-r" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:04:33 -0000 On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote: > (CC to freebsd-virtualization@) > > 20.10.2017 19:32, Ian Lepore ΠΙΫΕΤ: > > > > On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: > > > > > > 20.10.2017 18:31, Boris Samorodov ΠΙΫΕΤ: > > > > > > > > > > > > 20.10.2017 18:12, Ian Lepore ΠΙΫΕΤ: > > > > > > > > > > > > > > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > I have got a host: > > > > > > --- > > > > > > bhyve-host% uname -a > > > > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug > > > > > > 25 05:25:26 MSK 2017 > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FASTššamd64 amd64 > > > > > > --- > > > > > > > > > > > > And a bhyve vm: > > > > > > --- > > > > > > bhyve-vm: uname -a > > > > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri > > > > > > Oct 20 05:12:17 MSK 2017 > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64Xššamd64 amd64 > > > > > > --- > > > > > > > > > > > > The only difference at kernel configs is a colored console. :-) > > > > > > > > > > > > And here I get some weird (is it?) result at the VM (I expect ntpd to be > > > > > > more stable): > > > > > > --- > > > > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > > > šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset > > > > > > jitter > > > > > > ============================================================================== > > > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš9ššš64šššš3šššš0.605ššš-1.202 > > > > > > 316.407 > > > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš7ššš64šššš7šššš0.605ššš-1.202 > > > > > > 358.395 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš5ššš64ššš17šššš0.615šš-328.42 > > > > > > 181.405 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64ššš37šššš0.615šš-328.42 > > > > > > 214.868 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64ššš37šššš0.615šš-328.42 > > > > > > 214.868 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš63ššš64ššš77šššš0.615šš-328.42 > > > > > > 268.618 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64šš177šššš0.615šš-328.42 > > > > > > 333.175 > > > > > > šXX.XX.XX.1šššššš.STEP.šššššššššš16 u 1910ššš64šššš0šššš0.000šššš0.000 > > > > > > 0.000 > > > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš27ššš64šššš1šššš0.703šš-262.63 > > > > > > 0.004 > > > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš31ššš64šššš1šššš0.649šš-331.43 > > > > > > 68.800 > > > > > > --- > > > > > > > > > > > > At the same time host's results are very stable: > > > > > > --- > > > > > > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > > > šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset > > > > > > jitter > > > > > > ============================================================================== > > > > > > > > > > > > > > > > > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš1ššš64šššš1šššš0.401šššš0.176 > > > > > > 0.106 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš6ššš64šššš3šššš0.401šššš0.176 > > > > > > 0.459 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64šššš7šššš0.401šššš0.176 > > > > > > 0.940 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64šššš7šššš0.401šššš0.176 > > > > > > 0.940 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš64ššš64ššš17šššš0.401šššš0.176 > > > > > > 1.566 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64ššš37šššš0.448šššš1.275 > > > > > > 1.739 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš55ššš64ššš77šššš0.448šššš1.275 > > > > > > 2.365 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš53ššš64šš177šššš0.448šššš1.275 > > > > > > 3.110 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš50ššš64šš377šššš0.448šššš1.275 > > > > > > 3.929 > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš45ššš64šš377šššš0.443šššš8.750 > > > > > > 4.722 > > > > > > --- > > > > > > > > > > > > The network is organized via bridge -- host igb and vm tap interfaces > > > > > > are members of one bridge. > > > > > > > > > > > > Are those results expected? Does it smell like a bug? Should I dig > > > > > > furter? > > > > > > > > > > > So it is repeatedly stepping the clock in the VM? (Set > > > > > kern.timecounter.stepwarnings=1 to log steps). > > > > No kernel/ntpd messages for 20 minutes after setting this sysctl. > > > > > > > > > > > > > > > > > > > šThat is usually a sign > > > > > that the chosen timecounter is running at a different frequency than it > > > > > claimed to be when it registered itself -- the host may not be > > > > > emulating the timer hardware properly in the guest. šWhat is the output > > > > > of sysctl kern.timecounter in the vm? > > > > --- > > > > bhyve-vm% sysctl kern.timecounter > > > > > > > > kern.timecounter.tsc_shift: 1 > > > > kern.timecounter.smp_tsc_adjust: 0 > > > > kern.timecounter.smp_tsc: 0 > > > > kern.timecounter.invariant_tsc: 1 > > > > kern.timecounter.fast_gettime: 1 > > > > kern.timecounter.tick: 1 > > > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) > > > > dummy(-1000000) > > > > kern.timecounter.hardware: HPET > > > > kern.timecounter.alloweddeviation: 5 > > > > kern.timecounter.stepwarnings: 1 > > > > kern.timecounter.tc.ACPI-fast.quality: 900 > > > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > > > kern.timecounter.tc.ACPI-fast.counter: 4161213491 > > > > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > > > > kern.timecounter.tc.HPET.quality: 950 > > > > kern.timecounter.tc.HPET.frequency: 10000000 > > > > kern.timecounter.tc.HPET.counter: 3518036865 > > > > kern.timecounter.tc.HPET.mask: 4294967295 > > > > kern.timecounter.tc.i8254.quality: 0 > > > > kern.timecounter.tc.i8254.frequency: 1193182 > > > > kern.timecounter.tc.i8254.counter: 47597 > > > > kern.timecounter.tc.i8254.mask: 65535 > > > > kern.timecounter.tc.TSC-low.quality: -100 > > > > kern.timecounter.tc.TSC-low.frequency: 1199886114 > > > > kern.timecounter.tc.TSC-low.counter: 1274338278 > > > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > > > --- > > > BTW, here is the host kern.timecounter: > > > --- > > > kern.timecounter.tsc_shift: 1 > > > kern.timecounter.smp_tsc_adjust: 0 > > > kern.timecounter.smp_tsc: 1 > > > kern.timecounter.invariant_tsc: 1 > > > kern.timecounter.fast_gettime: 1 > > > kern.timecounter.tick: 1 > > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > > > dummy(-1000000) > > > kern.timecounter.hardware: TSC-low > > > kern.timecounter.alloweddeviation: 5 > > > kern.timecounter.stepwarnings: 0 > > > kern.timecounter.tc.ACPI-fast.quality: 900 > > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > > kern.timecounter.tc.ACPI-fast.counter: 9047194 > > > kern.timecounter.tc.ACPI-fast.mask: 16777215 > > > kern.timecounter.tc.HPET.quality: 950 > > > kern.timecounter.tc.HPET.frequency: 14318180 > > > kern.timecounter.tc.HPET.counter: 2232552795 > > > kern.timecounter.tc.HPET.mask: 4294967295 > > > kern.timecounter.tc.i8254.quality: 0 > > > kern.timecounter.tc.i8254.frequency: 1193182 > > > kern.timecounter.tc.i8254.counter: 43410 > > > kern.timecounter.tc.i8254.mask: 65535 > > > kern.timecounter.tc.TSC-low.quality: 1000 > > > kern.timecounter.tc.TSC-low.frequency: 1200067168 > > > kern.timecounter.tc.TSC-low.counter: 2463146362 > > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > > --- > > > > > > > > > > > > > > > > > > > > > > > > > > Also, what is the output of ntptime(8) in the vm? > > > > --- > > > > bhyve-vm% ntptime > > > > > > > > ntp_gettime() returns code 0 (OK) > > > > š time dd94930f.20ea2900ššFri, Oct 20 2017 18:21:51.128, (.128573699), > > > > š maximum error 1309110 us, estimated error 3 us, TAI offset 37 > > > > ntp_adjtime() returns code 0 (OK) > > > > š modes 0x0 (), > > > > š offset 0.000 us, frequency 0.000 ppm, interval 1 s, > > > > š maximum error 1309110 us, estimated error 3 us, > > > > š status 0x2001 (PLL,NANO), > > > > š time constant 6, precision 0.001 us, tolerance 496 ppm, > > > > --- > > > > > > > > Ian, thank you for your help! > > > > > > It seems odd to me that the frequency of the host HPET is 14.3mhz and > > that of the guest is 10.0mhz, but maybe that's a normal condition for > > bhyve. šI did find some google hits[1] for bhyve guest timekeeping > > trouble with the HPET timer which was solved by switching to a > > different timecounter. šTimecounter choices can't be controlled from > > loader.conf, so I guess a sysctl.conf entry of > > kern.timecounter.hardware="ACPI-fast" is the only way to fix that. šYou > > can also just do that command interactively first and see if it stops > > the time steps and ntp settles down. > The process seems to become more monotonic. But steps nevertheless: > --- > *XX.1ššššššXX.245ššššš4 uššš20ššš64šššš1šššš0.717šš-12.771ššš4.193 > *XX.1ššššššXX.245ššššš4 uššš28ššš64šššš3šššš0.751šš-41.970šš32.342 > *XX.1ššššššXX.245ššššš4 uššš23ššš64šššš7šššš0.748šš-59.505šš46.624 > *XX.1ššššššXX.245ššššš4 uššš18ššš64ššš17šššš0.699šš-75.164šš56.482 > *XX.1ššššššXX.245ššššš4 uššš14ššš64ššš37šššš0.669šš-90.112šš63.767 > *XX.1ššššššXX.245ššššš4 uššš11ššš64ššš77šššš0.605šš-10.567šš60.914 > *XX.1ššššššXX.245ššššš4 ušššš7ššš64šš177šššš0.591šš-169.54 116.762 > *XX.1ššššššXX.245ššššš4 ušššš3ššš64šš377šššš0.591šš-169.54 102.107 > *XX.1ššššššXX.245ššššš4 uššš68ššš64šš377šššš0.591šš-169.54 102.107 > *XX.1ššššššXX.245ššššš4 uššš63ššš64šš377šššš0.591šš-169.54šš88.424 > *XX.1ššššššXX.245ššššš4 uššš58ššš64šš377šššš0.591šš-169.54šš92.949 > *XX.1ššššššXX.245ššššš4 uššš55ššš64šš377šššš0.591šš-169.54 111.512 > *XX.1ššššššXX.245ššššš4 uššš50ššš64šš377šššš0.591šš-169.54 140.827 > *XX.1ššššššXX.245ššššš4 uššš45ššš64šš377šššš0.591šš-169.54 177.360 > *XX.1ššššššXX.245ššššš4 uššš43ššš64šš377šššš0.591šš-169.54 219.057 > šXX.1šššššš.STEP.šššš16 ušš588ššš64šššš0šššš0.000šššš0.000ššš0.000 > --- > > > > > This would be a workaround, not a fix per se. šIf the time steps go > > away, then something in bhyve's emulation of HPET (maybe only on some > > hardware?) must be buggy. > > > > > > [1] https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-April/003492.html > Also thanks for the link. Unfortunately the problem seems to persist. > Hmm, that almost looks normal... it noticed the clock was drifting fast, so it went into a frequency-training cycle (at the point where the offset stopped changing at -169.54) and then once it had figured out the frequency it did a step to get realigned, and (presumably) adjusted the frequency of the kernel clock. šThe output of ntptime before and after the step would show that... before the step the frequency would show as zero (which was the case in your ntptime output earlier), and after the step it would be non-zero. šNo more steps would occur after the first one, if that's what is happening here. -- Ian From owner-freebsd-current@freebsd.org Fri Oct 20 18:15:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AF34E3C7AE; Fri, 20 Oct 2017 18:15:49 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward105j.mail.yandex.net (forward105j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 946A3157C; Fri, 20 Oct 2017 18:15:48 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback9g.mail.yandex.net (mxback9g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:170]) by forward105j.mail.yandex.net (Yandex) with ESMTP id DA1A2183DC6; Fri, 20 Oct 2017 21:15:45 +0300 (MSK) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback9g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id sWvRtAedPA-FjDKSv2v; Fri, 20 Oct 2017 21:15:45 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508523345; bh=EkROp2IuGx5O7R+XmYyYVamjxLmExSwjYxyW6PRYLpM=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=MLOpgLEsIFucNhXK7/tx+8Z7ncNiCKAYtxtNLoq3xXclnGP+OlXKyIIIb5Fu8Y0Q8 TC2pFUenw7gacb9DPpRfIlV0AjTyGRHw8pRfDnQnmG3rVeUj9hvRQhZEaGSM9gZ+EP 4kSm8D7svRc3Wgko3BZyoRQimDV3XHdXkTvEe2xQ= Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 8WICKTfZc9-FiwmYCAN; Fri, 20 Oct 2017 21:15:44 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1508523344; bh=EkROp2IuGx5O7R+XmYyYVamjxLmExSwjYxyW6PRYLpM=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=Ss/KBtWVkBMaCITjfZmP2FoGH4na4+PtzvpfW2mkpOnMv/V2PYDZ8E4SzEIGVO33u Q7k9IIkxbaqHCI9Nru5PZ4eS7AqEslGRSzZHQ/7468oFTeJj5ysh+vzpacqHaj9Ujp VLwCjy2qA1H10nU8JC5YsoBO3fo3nMHTYSIlyHbg= Authentication-Results: smtp1j.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: host, bhyve vm and ntpd To: Ian Lepore , freebsd-current@FreeBSD.org, freebsd-virtualization@FreeBSD.org References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> <1508517160.1383.63.camel@freebsd.org> <76ff7afb-3d3a-96f6-1275-89472ff5683d@passap.ru> <1508522667.1383.69.camel@freebsd.org> From: Boris Samorodov Message-ID: <30992c14-7b78-ab9f-5693-931e6ca41f1b@passap.ru> Date: Fri, 20 Oct 2017 21:15:44 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1508522667.1383.69.camel@freebsd.org> Content-Type: text/plain; charset=koi8-r Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:15:49 -0000 20.10.2017 21:04, Ian Lepore ΠΙΫΕΤ: > On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote: >> (CC to freebsd-virtualization@) >> >> 20.10.2017 19:32, Ian Lepore ΠΙΫΕΤ: >>> >>> On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: >>>> >>>> 20.10.2017 18:31, Boris Samorodov ΠΙΫΕΤ: >>>>> >>>>> >>>>> 20.10.2017 18:12, Ian Lepore ΠΙΫΕΤ: >>>>>> >>>>>> >>>>>> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: >>>>>>> >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I have got a host: >>>>>>> --- >>>>>>> bhyve-host% uname -a >>>>>>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug >>>>>>> 25 05:25:26 MSK 2017 >>>>>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FASTššamd64 amd64 >>>>>>> --- >>>>>>> >>>>>>> And a bhyve vm: >>>>>>> --- >>>>>>> bhyve-vm: uname -a >>>>>>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri >>>>>>> Oct 20 05:12:17 MSK 2017 >>>>>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64Xššamd64 amd64 >>>>>>> --- >>>>>>> >>>>>>> The only difference at kernel configs is a colored console. :-) >>>>>>> >>>>>>> And here I get some weird (is it?) result at the VM (I expect ntpd to be >>>>>>> more stable): >>>>>>> --- >>>>>>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done >>>>>>> šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset >>>>>>> jitter >>>>>>> ============================================================================== >>>>>>> šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš9ššš64šššš3šššš0.605ššš-1.202 >>>>>>> 316.407 >>>>>>> šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš7ššš64šššš7šššš0.605ššš-1.202 >>>>>>> 358.395 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš5ššš64ššš17šššš0.615šš-328.42 >>>>>>> 181.405 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64ššš37šššš0.615šš-328.42 >>>>>>> 214.868 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64ššš37šššš0.615šš-328.42 >>>>>>> 214.868 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš63ššš64ššš77šššš0.615šš-328.42 >>>>>>> 268.618 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64šš177šššš0.615šš-328.42 >>>>>>> 333.175 >>>>>>> šXX.XX.XX.1šššššš.STEP.šššššššššš16 u 1910ššš64šššš0šššš0.000šššš0.000 >>>>>>> 0.000 >>>>>>> šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš27ššš64šššš1šššš0.703šš-262.63 >>>>>>> 0.004 >>>>>>> šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš31ššš64šššš1šššš0.649šš-331.43 >>>>>>> 68.800 >>>>>>> --- >>>>>>> >>>>>>> At the same time host's results are very stable: >>>>>>> --- >>>>>>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done >>>>>>> šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset >>>>>>> jitter >>>>>>> ============================================================================== >>>>>>> >>>>>>> >>>>>>> >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš1ššš64šššš1šššš0.401šššš0.176 >>>>>>> 0.106 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš6ššš64šššš3šššš0.401šššš0.176 >>>>>>> 0.459 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64šššš7šššš0.401šššš0.176 >>>>>>> 0.940 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64šššš7šššš0.401šššš0.176 >>>>>>> 0.940 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš64ššš64ššš17šššš0.401šššš0.176 >>>>>>> 1.566 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64ššš37šššš0.448šššš1.275 >>>>>>> 1.739 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš55ššš64ššš77šššš0.448šššš1.275 >>>>>>> 2.365 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš53ššš64šš177šššš0.448šššš1.275 >>>>>>> 3.110 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš50ššš64šš377šššš0.448šššš1.275 >>>>>>> 3.929 >>>>>>> *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš45ššš64šš377šššš0.443šššš8.750 >>>>>>> 4.722 >>>>>>> --- >>>>>>> >>>>>>> The network is organized via bridge -- host igb and vm tap interfaces >>>>>>> are members of one bridge. >>>>>>> >>>>>>> Are those results expected? Does it smell like a bug? Should I dig >>>>>>> furter? >>>>>>> >>>>>> So it is repeatedly stepping the clock in the VM? (Set >>>>>> kern.timecounter.stepwarnings=1 to log steps). >>>>> No kernel/ntpd messages for 20 minutes after setting this sysctl. >>>>> >>>>>> >>>>>> >>>>>> šThat is usually a sign >>>>>> that the chosen timecounter is running at a different frequency than it >>>>>> claimed to be when it registered itself -- the host may not be >>>>>> emulating the timer hardware properly in the guest. šWhat is the output >>>>>> of sysctl kern.timecounter in the vm? >>>>> --- >>>>> bhyve-vm% sysctl kern.timecounter >>>>> >>>>> kern.timecounter.tsc_shift: 1 >>>>> kern.timecounter.smp_tsc_adjust: 0 >>>>> kern.timecounter.smp_tsc: 0 >>>>> kern.timecounter.invariant_tsc: 1 >>>>> kern.timecounter.fast_gettime: 1 >>>>> kern.timecounter.tick: 1 >>>>> kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) >>>>> dummy(-1000000) >>>>> kern.timecounter.hardware: HPET >>>>> kern.timecounter.alloweddeviation: 5 >>>>> kern.timecounter.stepwarnings: 1 >>>>> kern.timecounter.tc.ACPI-fast.quality: 900 >>>>> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >>>>> kern.timecounter.tc.ACPI-fast.counter: 4161213491 >>>>> kern.timecounter.tc.ACPI-fast.mask: 4294967295 >>>>> kern.timecounter.tc.HPET.quality: 950 >>>>> kern.timecounter.tc.HPET.frequency: 10000000 >>>>> kern.timecounter.tc.HPET.counter: 3518036865 >>>>> kern.timecounter.tc.HPET.mask: 4294967295 >>>>> kern.timecounter.tc.i8254.quality: 0 >>>>> kern.timecounter.tc.i8254.frequency: 1193182 >>>>> kern.timecounter.tc.i8254.counter: 47597 >>>>> kern.timecounter.tc.i8254.mask: 65535 >>>>> kern.timecounter.tc.TSC-low.quality: -100 >>>>> kern.timecounter.tc.TSC-low.frequency: 1199886114 >>>>> kern.timecounter.tc.TSC-low.counter: 1274338278 >>>>> kern.timecounter.tc.TSC-low.mask: 4294967295 >>>>> --- >>>> BTW, here is the host kern.timecounter: >>>> --- >>>> kern.timecounter.tsc_shift: 1 >>>> kern.timecounter.smp_tsc_adjust: 0 >>>> kern.timecounter.smp_tsc: 1 >>>> kern.timecounter.invariant_tsc: 1 >>>> kern.timecounter.fast_gettime: 1 >>>> kern.timecounter.tick: 1 >>>> kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) >>>> dummy(-1000000) >>>> kern.timecounter.hardware: TSC-low >>>> kern.timecounter.alloweddeviation: 5 >>>> kern.timecounter.stepwarnings: 0 >>>> kern.timecounter.tc.ACPI-fast.quality: 900 >>>> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >>>> kern.timecounter.tc.ACPI-fast.counter: 9047194 >>>> kern.timecounter.tc.ACPI-fast.mask: 16777215 >>>> kern.timecounter.tc.HPET.quality: 950 >>>> kern.timecounter.tc.HPET.frequency: 14318180 >>>> kern.timecounter.tc.HPET.counter: 2232552795 >>>> kern.timecounter.tc.HPET.mask: 4294967295 >>>> kern.timecounter.tc.i8254.quality: 0 >>>> kern.timecounter.tc.i8254.frequency: 1193182 >>>> kern.timecounter.tc.i8254.counter: 43410 >>>> kern.timecounter.tc.i8254.mask: 65535 >>>> kern.timecounter.tc.TSC-low.quality: 1000 >>>> kern.timecounter.tc.TSC-low.frequency: 1200067168 >>>> kern.timecounter.tc.TSC-low.counter: 2463146362 >>>> kern.timecounter.tc.TSC-low.mask: 4294967295 >>>> --- >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Also, what is the output of ntptime(8) in the vm? >>>>> --- >>>>> bhyve-vm% ntptime >>>>> >>>>> ntp_gettime() returns code 0 (OK) >>>>> š time dd94930f.20ea2900ššFri, Oct 20 2017 18:21:51.128, (.128573699), >>>>> š maximum error 1309110 us, estimated error 3 us, TAI offset 37 >>>>> ntp_adjtime() returns code 0 (OK) >>>>> š modes 0x0 (), >>>>> š offset 0.000 us, frequency 0.000 ppm, interval 1 s, >>>>> š maximum error 1309110 us, estimated error 3 us, >>>>> š status 0x2001 (PLL,NANO), >>>>> š time constant 6, precision 0.001 us, tolerance 496 ppm, >>>>> --- >>>>> >>>>> Ian, thank you for your help! >>>>> >>> It seems odd to me that the frequency of the host HPET is 14.3mhz and >>> that of the guest is 10.0mhz, but maybe that's a normal condition for >>> bhyve. šI did find some google hits[1] for bhyve guest timekeeping >>> trouble with the HPET timer which was solved by switching to a >>> different timecounter. šTimecounter choices can't be controlled from >>> loader.conf, so I guess a sysctl.conf entry of >>> kern.timecounter.hardware="ACPI-fast" is the only way to fix that. šYou >>> can also just do that command interactively first and see if it stops >>> the time steps and ntp settles down. >> The process seems to become more monotonic. But steps nevertheless: >> --- >> *XX.1ššššššXX.245ššššš4 uššš20ššš64šššš1šššš0.717šš-12.771ššš4.193 >> *XX.1ššššššXX.245ššššš4 uššš28ššš64šššš3šššš0.751šš-41.970šš32.342 >> *XX.1ššššššXX.245ššššš4 uššš23ššš64šššš7šššš0.748šš-59.505šš46.624 >> *XX.1ššššššXX.245ššššš4 uššš18ššš64ššš17šššš0.699šš-75.164šš56.482 >> *XX.1ššššššXX.245ššššš4 uššš14ššš64ššš37šššš0.669šš-90.112šš63.767 >> *XX.1ššššššXX.245ššššš4 uššš11ššš64ššš77šššš0.605šš-10.567šš60.914 >> *XX.1ššššššXX.245ššššš4 ušššš7ššš64šš177šššš0.591šš-169.54 116.762 >> *XX.1ššššššXX.245ššššš4 ušššš3ššš64šš377šššš0.591šš-169.54 102.107 >> *XX.1ššššššXX.245ššššš4 uššš68ššš64šš377šššš0.591šš-169.54 102.107 >> *XX.1ššššššXX.245ššššš4 uššš63ššš64šš377šššš0.591šš-169.54šš88.424 >> *XX.1ššššššXX.245ššššš4 uššš58ššš64šš377šššš0.591šš-169.54šš92.949 >> *XX.1ššššššXX.245ššššš4 uššš55ššš64šš377šššš0.591šš-169.54 111.512 >> *XX.1ššššššXX.245ššššš4 uššš50ššš64šš377šššš0.591šš-169.54 140.827 >> *XX.1ššššššXX.245ššššš4 uššš45ššš64šš377šššš0.591šš-169.54 177.360 >> *XX.1ššššššXX.245ššššš4 uššš43ššš64šš377šššš0.591šš-169.54 219.057 >> šXX.1šššššš.STEP.šššš16 ušš588ššš64šššš0šššš0.000šššš0.000ššš0.000 >> --- >> >>> >>> This would be a workaround, not a fix per se. šIf the time steps go >>> away, then something in bhyve's emulation of HPET (maybe only on some >>> hardware?) must be buggy. >>> >>> >>> [1] https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-April/003492.html >> Also thanks for the link. Unfortunately the problem seems to persist. >> > > Hmm, that almost looks normal... it noticed the clock was drifting > fast, so it went into a frequency-training cycle (at the point where > the offset stopped changing at -169.54) and then once it had figured > out the frequency it did a step to get realigned, and (presumably) > adjusted the frequency of the kernel clock. šThe output of ntptime > before and after the step would show that... before the step the > frequency would show as zero (which was the case in your ntptime output > earlier), and after the step it would be non-zero. šNo more steps would > occur after the first one, if that's what is happening here. Those were following steps: --- XX.1 XX.245 4 u 15 64 1 0.597 -51.802 7.547 XX.1 XX.245 4 u 17 64 1 0.597 -51.802 29.526 XX.1 XX.245 4 u 19 64 1 0.597 -51.802 52.760 XX.1 XX.245 4 u 19 64 3 0.597 -51.802 77.354 XX.1 XX.245 4 u 16 64 7 0.597 -51.802 103.182 XX.1 XX.245 4 u 12 64 17 0.597 -51.802 138.976 *XX.1 XX.245 4 u 9 64 37 0.700 -200.07 109.275 XX.1 .STEP. 16 u 1100 64 0 0.000 0.000 0.002 XX.1 XX.245 4 u 63 64 1 0.645 -3.620 0.002 XX.1 XX.245 4 u 34 64 1 0.645 -3.620 66.907 XX.1 XX.245 4 u 36 64 1 0.643 -115.30 85.082--- No stability. :-) But I see your point. I'll leave it till morning with hope it may stabilize. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@freebsd.org Fri Oct 20 18:21:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66BE7E3CA9B for ; Fri, 20 Oct 2017 18:21:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 413841BCE for ; Fri, 20 Oct 2017 18:21:39 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8c86b86c-b5c3-11e7-a938-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 8c86b86c-b5c3-11e7-a938-4f970e858fdb; Fri, 20 Oct 2017 18:21:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9KILaK3011644; Fri, 20 Oct 2017 12:21:36 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508523696.1383.75.camel@freebsd.org> Subject: Re: host, bhyve vm and ntpd From: Ian Lepore To: Boris Samorodov , freebsd-current@FreeBSD.org, freebsd-virtualization@FreeBSD.org Date: Fri, 20 Oct 2017 12:21:36 -0600 In-Reply-To: <30992c14-7b78-ab9f-5693-931e6ca41f1b@passap.ru> References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> <1508517160.1383.63.camel@freebsd.org> <76ff7afb-3d3a-96f6-1275-89472ff5683d@passap.ru> <1508522667.1383.69.camel@freebsd.org> <30992c14-7b78-ab9f-5693-931e6ca41f1b@passap.ru> Content-Type: text/plain; charset="koi8-r" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:21:39 -0000 On Fri, 2017-10-20 at 21:15 +0300, Boris Samorodov wrote: > 20.10.2017 21:04, Ian Lepore ΠΙΫΕΤ: > > > > On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote: > > > > > > (CC to freebsd-virtualization@) > > > > > > 20.10.2017 19:32, Ian Lepore ΠΙΫΕΤ: > > > > > > > > > > > > On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: > > > > > > > > > > > > > > > 20.10.2017 18:31, Boris Samorodov ΠΙΫΕΤ: > > > > > > > > > > > > > > > > > > > > > > > > 20.10.2017 18:12, Ian Lepore ΠΙΫΕΤ: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > I have got a host: > > > > > > > > --- > > > > > > > > bhyve-host% uname -a > > > > > > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug > > > > > > > > 25 05:25:26 MSK 2017 > > > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FASTššamd64 amd64 > > > > > > > > --- > > > > > > > > > > > > > > > > And a bhyve vm: > > > > > > > > --- > > > > > > > > bhyve-vm: uname -a > > > > > > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri > > > > > > > > Oct 20 05:12:17 MSK 2017 > > > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64Xššamd64 amd64 > > > > > > > > --- > > > > > > > > > > > > > > > > The only difference at kernel configs is a colored console. :-) > > > > > > > > > > > > > > > > And here I get some weird (is it?) result at the VM (I expect ntpd to be > > > > > > > > more stable): > > > > > > > > --- > > > > > > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > > > > > šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset > > > > > > > > jitter > > > > > > > > ============================================================================== > > > > > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš9ššš64šššš3šššš0.605ššš-1.202 > > > > > > > > 316.407 > > > > > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš7ššš64šššš7šššš0.605ššš-1.202 > > > > > > > > 358.395 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš5ššš64ššš17šššš0.615šš-328.42 > > > > > > > > 181.405 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64ššš37šššš0.615šš-328.42 > > > > > > > > 214.868 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64ššš37šššš0.615šš-328.42 > > > > > > > > 214.868 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš63ššš64ššš77šššš0.615šš-328.42 > > > > > > > > 268.618 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64šš177šššš0.615šš-328.42 > > > > > > > > 333.175 > > > > > > > > šXX.XX.XX.1šššššš.STEP.šššššššššš16 u 1910ššš64šššš0šššš0.000šššš0.000 > > > > > > > > 0.000 > > > > > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš27ššš64šššš1šššš0.703šš-262.63 > > > > > > > > 0.004 > > > > > > > > šXX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš31ššš64šššš1šššš0.649šš-331.43 > > > > > > > > 68.800 > > > > > > > > --- > > > > > > > > > > > > > > > > At the same time host's results are very stable: > > > > > > > > --- > > > > > > > > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > > > > > šššššremotešššššššššššrefidššššššst t when poll reachšššdelayšššoffset > > > > > > > > jitter > > > > > > > > ============================================================================== > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš1ššš64šššš1šššš0.401šššš0.176 > > > > > > > > 0.106 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš6ššš64šššš3šššš0.401šššš0.176 > > > > > > > > 0.459 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 ušššš3ššš64šššš7šššš0.401šššš0.176 > > > > > > > > 0.940 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš67ššš64šššš7šššš0.401šššš0.176 > > > > > > > > 0.940 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš64ššš64ššš17šššš0.401šššš0.176 > > > > > > > > 1.566 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš60ššš64ššš37šššš0.448šššš1.275 > > > > > > > > 1.739 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš55ššš64ššš77šššš0.448šššš1.275 > > > > > > > > 2.365 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš53ššš64šš177šššš0.448šššš1.275 > > > > > > > > 3.110 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš50ššš64šš377šššš0.448šššš1.275 > > > > > > > > 3.929 > > > > > > > > *XX.XX.XX.1ššššššXX.XX.XX.245ššššš4 uššš45ššš64šš377šššš0.443šššš8.750 > > > > > > > > 4.722 > > > > > > > > --- > > > > > > > > > > > > > > > > The network is organized via bridge -- host igb and vm tap interfaces > > > > > > > > are members of one bridge. > > > > > > > > > > > > > > > > Are those results expected? Does it smell like a bug? Should I dig > > > > > > > > furter? > > > > > > > > > > > > > > > So it is repeatedly stepping the clock in the VM? (Set > > > > > > > kern.timecounter.stepwarnings=1 to log steps). > > > > > > No kernel/ntpd messages for 20 minutes after setting this sysctl. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > šThat is usually a sign > > > > > > > that the chosen timecounter is running at a different frequency than it > > > > > > > claimed to be when it registered itself -- the host may not be > > > > > > > emulating the timer hardware properly in the guest. šWhat is the output > > > > > > > of sysctl kern.timecounter in the vm? > > > > > > --- > > > > > > bhyve-vm% sysctl kern.timecounter > > > > > > > > > > > > kern.timecounter.tsc_shift: 1 > > > > > > kern.timecounter.smp_tsc_adjust: 0 > > > > > > kern.timecounter.smp_tsc: 0 > > > > > > kern.timecounter.invariant_tsc: 1 > > > > > > kern.timecounter.fast_gettime: 1 > > > > > > kern.timecounter.tick: 1 > > > > > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) > > > > > > dummy(-1000000) > > > > > > kern.timecounter.hardware: HPET > > > > > > kern.timecounter.alloweddeviation: 5 > > > > > > kern.timecounter.stepwarnings: 1 > > > > > > kern.timecounter.tc.ACPI-fast.quality: 900 > > > > > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > > > > > kern.timecounter.tc.ACPI-fast.counter: 4161213491 > > > > > > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > > > > > > kern.timecounter.tc.HPET.quality: 950 > > > > > > kern.timecounter.tc.HPET.frequency: 10000000 > > > > > > kern.timecounter.tc.HPET.counter: 3518036865 > > > > > > kern.timecounter.tc.HPET.mask: 4294967295 > > > > > > kern.timecounter.tc.i8254.quality: 0 > > > > > > kern.timecounter.tc.i8254.frequency: 1193182 > > > > > > kern.timecounter.tc.i8254.counter: 47597 > > > > > > kern.timecounter.tc.i8254.mask: 65535 > > > > > > kern.timecounter.tc.TSC-low.quality: -100 > > > > > > kern.timecounter.tc.TSC-low.frequency: 1199886114 > > > > > > kern.timecounter.tc.TSC-low.counter: 1274338278 > > > > > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > > > > > --- > > > > > BTW, here is the host kern.timecounter: > > > > > --- > > > > > kern.timecounter.tsc_shift: 1 > > > > > kern.timecounter.smp_tsc_adjust: 0 > > > > > kern.timecounter.smp_tsc: 1 > > > > > kern.timecounter.invariant_tsc: 1 > > > > > kern.timecounter.fast_gettime: 1 > > > > > kern.timecounter.tick: 1 > > > > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > > > > > dummy(-1000000) > > > > > kern.timecounter.hardware: TSC-low > > > > > kern.timecounter.alloweddeviation: 5 > > > > > kern.timecounter.stepwarnings: 0 > > > > > kern.timecounter.tc.ACPI-fast.quality: 900 > > > > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > > > > kern.timecounter.tc.ACPI-fast.counter: 9047194 > > > > > kern.timecounter.tc.ACPI-fast.mask: 16777215 > > > > > kern.timecounter.tc.HPET.quality: 950 > > > > > kern.timecounter.tc.HPET.frequency: 14318180 > > > > > kern.timecounter.tc.HPET.counter: 2232552795 > > > > > kern.timecounter.tc.HPET.mask: 4294967295 > > > > > kern.timecounter.tc.i8254.quality: 0 > > > > > kern.timecounter.tc.i8254.frequency: 1193182 > > > > > kern.timecounter.tc.i8254.counter: 43410 > > > > > kern.timecounter.tc.i8254.mask: 65535 > > > > > kern.timecounter.tc.TSC-low.quality: 1000 > > > > > kern.timecounter.tc.TSC-low.frequency: 1200067168 > > > > > kern.timecounter.tc.TSC-low.counter: 2463146362 > > > > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > > > > --- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, what is the output of ntptime(8) in the vm? > > > > > > --- > > > > > > bhyve-vm% ntptime > > > > > > > > > > > > ntp_gettime() returns code 0 (OK) > > > > > > š time dd94930f.20ea2900ššFri, Oct 20 2017 18:21:51.128, (.128573699), > > > > > > š maximum error 1309110 us, estimated error 3 us, TAI offset 37 > > > > > > ntp_adjtime() returns code 0 (OK) > > > > > > š modes 0x0 (), > > > > > > š offset 0.000 us, frequency 0.000 ppm, interval 1 s, > > > > > > š maximum error 1309110 us, estimated error 3 us, > > > > > > š status 0x2001 (PLL,NANO), > > > > > > š time constant 6, precision 0.001 us, tolerance 496 ppm, > > > > > > --- > > > > > > > > > > > > Ian, thank you for your help! > > > > > > > > > > It seems odd to me that the frequency of the host HPET is 14.3mhz and > > > > that of the guest is 10.0mhz, but maybe that's a normal condition for > > > > bhyve. šI did find some google hits[1] for bhyve guest timekeeping > > > > trouble with the HPET timer which was solved by switching to a > > > > different timecounter. šTimecounter choices can't be controlled from > > > > loader.conf, so I guess a sysctl.conf entry of > > > > kern.timecounter.hardware="ACPI-fast" is the only way to fix that. šYou > > > > can also just do that command interactively first and see if it stops > > > > the time steps and ntp settles down. > > > The process seems to become more monotonic. But steps nevertheless: > > > --- > > > *XX.1ššššššXX.245ššššš4 uššš20ššš64šššš1šššš0.717šš-12.771ššš4.193 > > > *XX.1ššššššXX.245ššššš4 uššš28ššš64šššš3šššš0.751šš-41.970šš32.342 > > > *XX.1ššššššXX.245ššššš4 uššš23ššš64šššš7šššš0.748šš-59.505šš46.624 > > > *XX.1ššššššXX.245ššššš4 uššš18ššš64ššš17šššš0.699šš-75.164šš56.482 > > > *XX.1ššššššXX.245ššššš4 uššš14ššš64ššš37šššš0.669šš-90.112šš63.767 > > > *XX.1ššššššXX.245ššššš4 uššš11ššš64ššš77šššš0.605šš-10.567šš60.914 > > > *XX.1ššššššXX.245ššššš4 ušššš7ššš64šš177šššš0.591šš-169.54 116.762 > > > *XX.1ššššššXX.245ššššš4 ušššš3ššš64šš377šššš0.591šš-169.54 102.107 > > > *XX.1ššššššXX.245ššššš4 uššš68ššš64šš377šššš0.591šš-169.54 102.107 > > > *XX.1ššššššXX.245ššššš4 uššš63ššš64šš377šššš0.591šš-169.54šš88.424 > > > *XX.1ššššššXX.245ššššš4 uššš58ššš64šš377šššš0.591šš-169.54šš92.949 > > > *XX.1ššššššXX.245ššššš4 uššš55ššš64šš377šššš0.591šš-169.54 111.512 > > > *XX.1ššššššXX.245ššššš4 uššš50ššš64šš377šššš0.591šš-169.54 140.827 > > > *XX.1ššššššXX.245ššššš4 uššš45ššš64šš377šššš0.591šš-169.54 177.360 > > > *XX.1ššššššXX.245ššššš4 uššš43ššš64šš377šššš0.591šš-169.54 219.057 > > > šXX.1šššššš.STEP.šššš16 ušš588ššš64šššš0šššš0.000šššš0.000ššš0.000 > > > --- > > > > > > > > > > > > > > > This would be a workaround, not a fix per se. šIf the time steps go > > > > away, then something in bhyve's emulation of HPET (maybe only on some > > > > hardware?) must be buggy. > > > > > > > > > > > > [1] https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-April/003492.html > > > Also thanks for the link. Unfortunately the problem seems to persist. > > > > > Hmm, that almost looks normal... it noticed the clock was drifting > > fast, so it went into a frequency-training cycle (at the point where > > the offset stopped changing at -169.54) and then once it had figured > > out the frequency it did a step to get realigned, and (presumably) > > adjusted the frequency of the kernel clock. šThe output of ntptime > > before and after the step would show that... before the step the > > frequency would show as zero (which was the case in your ntptime output > > earlier), and after the step it would be non-zero. šNo more steps would > > occur after the first one, if that's what is happening here. > Those were following steps: > --- > šXX.1ššššššXX.245ššššš4 uššš15ššš64šššš1šššš0.597šš-51.802ššš7.547 > šXX.1ššššššXX.245ššššš4 uššš17ššš64šššš1šššš0.597šš-51.802šš29.526 > šXX.1ššššššXX.245ššššš4 uššš19ššš64šššš1šššš0.597šš-51.802šš52.760 > šXX.1ššššššXX.245ššššš4 uššš19ššš64šššš3šššš0.597šš-51.802šš77.354 > šXX.1ššššššXX.245ššššš4 uššš16ššš64šššš7šššš0.597šš-51.802 103.182 > šXX.1ššššššXX.245ššššš4 uššš12ššš64ššš17šššš0.597šš-51.802 138.976 > *XX.1ššššššXX.245ššššš4 ušššš9ššš64ššš37šššš0.700šš-200.07 109.275 > šXX.1šššššš.STEP.šššš16 u 1100ššš64šššš0šššš0.000šššš0.000ššš0.002 > šXX.1ššššššXX.245ššššš4 uššš63ššš64šššš1šššš0.645ššš-3.620ššš0.002 > šXX.1ššššššXX.245ššššš4 uššš34ššš64šššš1šššš0.645ššš-3.620šš66.907 > šXX.1ššššššXX.245ššššš4 uššš36ššš64šššš1šššš0.643šš-115.30šš85.082--- > > No stability. :-) But I see your point. I'll leave it till morning > with hope it may stabilize. > I don't think it will. šntpd doesn't need more than one cycle to figure out the frequency of a clock and adjust it (and record the amount in ntpd.drift for future use). šEither the clock is drifting at more than the max 500ppm rate, or it isn't really drifting steadily, it's still jumping around in an uneven manner. It might be interesting to try one of the lower-quality clocks such asš i8254, or try TSC-low, although there was a comment in that mail thread about how TSC might be a bad choice. Beyond that, I'm not sure what else to try. šIt might be necessary to get some bhyve developers involved (I know almost nothing about it). -- Ian From owner-freebsd-current@freebsd.org Sat Oct 21 06:41:18 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1806FE4EFBA for ; Sat, 21 Oct 2017 06:41:18 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C233757A7 for ; Sat, 21 Oct 2017 06:41:17 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x22a.google.com with SMTP id j15so825996wre.8 for ; Fri, 20 Oct 2017 23:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mime-version :content-transfer-encoding; bh=O00KKsRRycATcOQLeyFnNYaW8JaoC4ca65BB8C7DvLo=; b=fAzwZx0myuZGAKhj9uzaTlFRA5XbyIQZsgK4g4ylnjjaeTrDodVKtb2UKa57syiZSC mIflXgSY/W/jdBrzi0Bot0cqoTXhZxRKinTlc0UhKodgO5JX7szR0QY6XP5OpT9eO+tC hzVhc+Og58tQrFkpRwqSaVbij8MnGODwNnE2AB5QFkcssnVQnkSNJ8+OpeNfL77k+h8b Teg93zY0QB//riVH27Mljs+nVaQfXhUetRSepi5UXvQonFZBgrZjCRsz2EePUeBwtOWO XcyGtuDQFbSBoG+jSz8PS0t+cM4GttJpDJmrbPOUV8WqDf9F77Hk17d/q7c+HHGDdrji AaFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-transfer-encoding; bh=O00KKsRRycATcOQLeyFnNYaW8JaoC4ca65BB8C7DvLo=; b=HNRvajMg7FnVrNGAQp/D1MUloZMkuLA/XAV3QEKjZ2brBVeE+D0AOz73znPkyiUfLX tFXVwzNB0c9jPTUrpeVMpXxzlnKruQB2KI/rE0ndImXDeS2K4mvnPjWbAkqtvNxiDVE3 mj8QJUbG9J4QUJXSxUYcnXTNX4pDwGwdV8jByoM75aMjVD484vT3gv+kwAhEZkuwBGcZ QSUF1eXdGh8dntAkls0OCfbnx3Sfx0DlDRag7kqjhicZs1oDfB9RffR5wOhCudvA9Zq0 2E8IzNT620CaY4r0+EltrMLiID37m5K/U8/Y+XU/deeb2jVDlI6Sxhe6pwc4Dz9MxsMp qU9g== X-Gm-Message-State: AMCzsaVNUqKJJmlhKxBsvlaQiyEtQlHjnrv90GJYWtz2XeJAOOaZEY6q /JM8S7W3XaTvqvPUcUe68uyj7Q== X-Google-Smtp-Source: ABhQp+TvEQ5MRxCP7DH04m3ajQmXIePQIZyPI3GshF0zPByY0QUwFNgVc9c9k5socyWr3jcM/GUF/Q== X-Received: by 10.223.186.202 with SMTP id w10mr6685732wrg.132.1508568074796; Fri, 20 Oct 2017 23:41:14 -0700 (PDT) Received: from ernst.home (p578E321D.dip0.t-ipconnect.de. [87.142.50.29]) by smtp.gmail.com with ESMTPSA id 4sm678991wmm.1.2017.10.20.23.41.13 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Oct 2017 23:41:13 -0700 (PDT) Date: Sat, 21 Oct 2017 08:41:04 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: /sys/boot compile broken Message-ID: <20171021084104.517ba6b7@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 06:41:18 -0000 SVN for HEAD source at 324810. Compiling /sys/boot is totally screwed up. The failure is that geliboot.c cannot be found. This prevents a successful ``make buildworld''. This error occurs despite the fact that I have LOADER_NO_GELI_SUPPORT set to yes in src.conf. Looking at the various Makefiles this option is supposed to prevent using GELI. Even if the user wanted to use GELI the compile of the boot code would probably fail. imp@ has had his fingers in the boot code lately. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Sat Oct 21 12:03:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85CCFE54AF3 for ; Sat, 21 Oct 2017 12:03:13 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 391A381DE5 for ; Sat, 21 Oct 2017 12:03:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v9LC3BCa002239; Sat, 21 Oct 2017 12:03:11 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v9LC3BQ6002238; Sat, 21 Oct 2017 05:03:11 -0700 (PDT) (envelope-from david) Date: Sat, 21 Oct 2017 05:03:11 -0700 From: David Wolfskill To: Gary Jennejohn Cc: freebsd-current@freebsd.org Subject: Re: /sys/boot compile broken Message-ID: <20171021120311.GS1214@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Gary Jennejohn , freebsd-current@freebsd.org References: <20171021084104.517ba6b7@ernst.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9cp4xQL35R9EDekE" Content-Disposition: inline In-Reply-To: <20171021084104.517ba6b7@ernst.home> User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 12:03:13 -0000 --9cp4xQL35R9EDekE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 21, 2017 at 08:41:04AM +0200, Gary Jennejohn wrote: > SVN for HEAD source at 324810. >=20 > Compiling /sys/boot is totally screwed up. The failure is that > geliboot.c cannot be found. >=20 > This prevents a successful ``make buildworld''. I did not encounter this issue in my upgrade from: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #437 r3247= 95M/324801:1200051: Fri Oct 20 04:36:06 PDT 2017 root@g1-252.catwhisker= =2Eorg:/common/S4/obj/usr/src/sys/CANARY amd64 to: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #438 r3248= 11M/324812:1200051: Sat Oct 21 04:44:50 PDT 2017 root@g1-252.catwhisker= =2Eorg:/common/S4/obj/usr/src/sys/CANARY amd64 Granted, that was to r324811, not r3248110, but r324811 was for sys/dev/pms. >...=20 > imp@ has had his fingers in the boot code lately. He has, yes -- mostly (IIRC, from discussions at work) in support of UEFI booting. > ... Peace, david --=20 David H. Wolfskill david@catwhisker.org Unsubstantiated claims of "Fake News" are evidence that the claimant lies a= gain. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --9cp4xQL35R9EDekE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZ6zd/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XZbYH/R94RITMRGDO43LDk/gB5e+K 6ZuWMA+eTZiL3onxrRSwqvpT+6Dl61kBb6b/QHDmLZCOFjFuhRW7AD3SOIdKCqvq vndR7xMJT/qf5w63ZixQglRANd+NdFgEbYmG/Wa1UnYtiKnvuJz8HTdPPRSvrBNS go32SYrq0j/LfCixuSHBsyByAQeB/RXOYehM2PAfiHX1iF/LZS+ECgJOKbQ6TwJ9 xc2bJjEJEPEOgWa/fZwiDSw+9guQvI/XXQNwHRYnOO78bWt61NwEn/jy0KQ5RhRh zk7A9f+0aq5zMyHJ59YY73z38VE0Ta4s4ZA37jbZg5OWu3hhXrlhTtBDuWROtoE= =zFCU -----END PGP SIGNATURE----- --9cp4xQL35R9EDekE-- From owner-freebsd-current@freebsd.org Sat Oct 21 15:02:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4AF2E2FACC for ; Sat, 21 Oct 2017 15:02:34 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1FAA16FE for ; Sat, 21 Oct 2017 15:02:34 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 82D0D14A6E for ; Sat, 21 Oct 2017 15:02:26 +0000 (UTC) Subject: Re: /sys/boot compile broken To: freebsd-current@freebsd.org References: <20171021084104.517ba6b7@ernst.home> From: Allan Jude Message-ID: <948b8477-8ef2-9a6f-b9f8-83f515e44b9f@freebsd.org> Date: Sat, 21 Oct 2017 11:02:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171021084104.517ba6b7@ernst.home> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lGUeGaQm34b5qgEOhWBo3Ws0IhXvqdsBp" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 15:02:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lGUeGaQm34b5qgEOhWBo3Ws0IhXvqdsBp Content-Type: multipart/mixed; boundary="VIKpEwQkR3MqjFunTfCSPCx3QvlOd2Veb"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <948b8477-8ef2-9a6f-b9f8-83f515e44b9f@freebsd.org> Subject: Re: /sys/boot compile broken References: <20171021084104.517ba6b7@ernst.home> In-Reply-To: <20171021084104.517ba6b7@ernst.home> --VIKpEwQkR3MqjFunTfCSPCx3QvlOd2Veb Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2017-10-21 02:41, Gary Jennejohn wrote: > SVN for HEAD source at 324810. >=20 > Compiling /sys/boot is totally screwed up. The failure is that > geliboot.c cannot be found. >=20 > This prevents a successful ``make buildworld''. >=20 > This error occurs despite the fact that I have LOADER_NO_GELI_SUPPORT > set to yes in src.conf. >=20 > Looking at the various Makefiles this option is supposed to prevent > using GELI. >=20 > Even if the user wanted to use GELI the compile of the boot code > would probably fail. >=20 > imp@ has had his fingers in the boot code lately. >=20 Some of the boot code has been changed over to LOADER_GELI_SUPPORT=3Dno And so you ended up with some code not guarded. Add the additional src.conf knob for now, and Warner will get it fixed up shortly. --=20 Allan Jude --VIKpEwQkR3MqjFunTfCSPCx3QvlOd2Veb-- --lGUeGaQm34b5qgEOhWBo3Ws0IhXvqdsBp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJZ62GBAAoJEBmVNT4SmAt+OsAQAOgAVryT1fekSd/CPjZh+MVZ xsdsSKQEu4zjvgPEVq3kzLrIE6CVb8Zq/K0ib/NltjWNHv4Tw9yf6dFt3Y6f3fH0 Jn1/ukVaWgPp6W4R+4BsvknoTvrO3ztwkEYZ532o2NE0kfFXRRJe0ISp/OA5HDhB lH8ScQI0R8IVNF7UYS04JqalHEl5b4a9Qvigmrq5C8e7DxwFAD60CATcmPb0YiJg 0sIdnWB8ZyYqaS3Z6JC3DuuHjkOHenLvrA7/HQfssrN6R90WJaUn8HkbebAL6R88 ltHH0WP5ALomvQQ5qrjADRmnAocNyviQh+5dGkI9sWc0O3SyTdeZ3oBtrRM2aJM+ Od2LrNZSe3NKLZ1Y0BESLMqhDKrtxB8baCSvKtYmYjRrShhxjLQ2OlStJsBKfYap 2ODY0T793K82kK3kVKimK26HaZ/ESz9Y3eKIaZwrbI+PBKm/2SUlfE45gbwnfJlA 7s/Qvk+d0MdXr2AVp657oW5Ba0ox9KD5brlRCXh5Svmorj2DrMi3kU6ZAlsxcERM J5EGoYQ7It/3UyDJ7+NSPXfsF5V4GTxl0SrhyL8k6iZbcx8c6GAeOfOV7ZSAb3L5 xSBj4jwPkL5bw0/AxWMON0Y/jgpbcScMQsAbIKiCDwGsdCHjBurxM3CtJy4GWpi+ K2gTm9a1jy8Bj1mdDVFK =tDTB -----END PGP SIGNATURE----- --lGUeGaQm34b5qgEOhWBo3Ws0IhXvqdsBp-- From owner-freebsd-current@freebsd.org Sat Oct 21 15:33:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 217FAE312FA for ; Sat, 21 Oct 2017 15:33:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E388525EC for ; Sat, 21 Oct 2017 15:33:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id n195so1684720itg.0 for ; Sat, 21 Oct 2017 08:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GSXQOWaro0ctDjR2LHE/9NaIsyayddb/YzkheKSJu1E=; b=vXonrD/YB8fuNXRqY7fXNzDwQhJHnc8uUjaW9ielZ+/eOEe2huog/nuDK2peYipUPZ 9/7e/GAYaT4uoci8HOKxN2gYTAqsYj6Smo6Jdn+KPU21NxX64hltF+QTiSrH8lAS19pM TviYOUdrn9vGBSDM+29eYxKUIIUBdzt6atE32aM/46sds4Dbv4hPhSnfny1yLgVI1+eZ 1RGOBqFnZ/XyZcJv2RPu+nzM3/PgpMnpe9kJKLkjyq1bJH1g4F6Hv9rEZulILJC/J7/n UF3F3u6wmkbUiYbLsIOwXyYoqQzFac29KoitkgK5fPQ4klCLoUmYm/xXxgJZ+fVAzuaz mvqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GSXQOWaro0ctDjR2LHE/9NaIsyayddb/YzkheKSJu1E=; b=t3b/VLQiLkC2a3/uaAeimu93D9LD6q/V0ZBdr204GiV3tztygdwY32YeZ3NoSzbDgR 6SFUccYYAJF7OTzJ6meZ7Tu9u3AqJw3Tn6SFVYvbml679nVh1dlrma8jZsvRW3LvGAzs zZaW4J+PJpqeiviUgidiv4mdoo9dbkeQjsYR1YqmrQm/Ulj+9tQD7q/n4kLJ0t6NZL2b MfdO72QFRCZX88pA8Q9dVRWc5LpQVZKcRgGe1e5GS/RhUr4l2PHe7MxXL1HhImE95tWR Y5oscE4K8ZwklrLGVBMA2ZNHSamdRdWXE2h98kiNrcP2iRCb1KaDkK6jUUtPst8pyE5Z /2LA== X-Gm-Message-State: AMCzsaV9gWipJVelu+UgScaPevxSBUMCWUUX9mwtl4XwAymaggQndBHk zbJz2Qyr0k1bOks21iQ2xj6WmsfUgCST+I6zWHXJow== X-Google-Smtp-Source: ABhQp+Tz+B1KAaicwB3z6y9Yv3k3KA1qEK77UaoebiSJuKPwKkw+qVPIhnEBnOAq5RylVarDf0PLb5cgdKM7fSxmajo= X-Received: by 10.36.94.129 with SMTP id h123mr2596981itb.64.1508600022866; Sat, 21 Oct 2017 08:33:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Sat, 21 Oct 2017 08:33:41 -0700 (PDT) X-Originating-IP: [63.145.217.227] Received: by 10.79.57.22 with HTTP; Sat, 21 Oct 2017 08:33:41 -0700 (PDT) In-Reply-To: <948b8477-8ef2-9a6f-b9f8-83f515e44b9f@freebsd.org> References: <20171021084104.517ba6b7@ernst.home> <948b8477-8ef2-9a6f-b9f8-83f515e44b9f@freebsd.org> From: Warner Losh Date: Sat, 21 Oct 2017 09:33:41 -0600 X-Google-Sender-Auth: HEpviONBo066EFi3I5tL5nWMTms Message-ID: Subject: Re: /sys/boot compile broken To: Allan Jude Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 15:33:44 -0000 On Oct 21, 2017 8:02 AM, "Allan Jude" wrote: On 2017-10-21 02:41, Gary Jennejohn wrote: > SVN for HEAD source at 324810. > > Compiling /sys/boot is totally screwed up. The failure is that > geliboot.c cannot be found. > > This prevents a successful ``make buildworld''. > > This error occurs despite the fact that I have LOADER_NO_GELI_SUPPORT > set to yes in src.conf. > > Looking at the various Makefiles this option is supposed to prevent > using GELI. > > Even if the user wanted to use GELI the compile of the boot code > would probably fail. > > imp@ has had his fingers in the boot code lately. > Some of the boot code has been changed over to LOADER_GELI_SUPPORT=no And so you ended up with some code not guarded. Add the additional src.conf knob for now, and Warner will get it fixed up I fly back from legoland today and will touch this up. I'm in the process of changing them into real config knobs from the weird things that have leaked out... sys/boot is likely moving my up to boot as well in the near future. Warner From owner-freebsd-current@freebsd.org Sat Oct 21 20:02:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46431E38B08 for ; Sat, 21 Oct 2017 20:02:50 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.imp.ch (smtp.imp.ch [IPv6:2001:4060:1:1001::13:196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09DCC6983F; Sat, 21 Oct 2017 20:02:50 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from [192.168.225.14] (dhclient-91-190-10-49.flashcable.ch [91.190.10.49]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPSA id D0938C0B75; Sat, 21 Oct 2017 22:02:38 +0200 (CEST) Subject: Re: Segfault in _Unwind_* code called from pthread_exit To: Konstantin Belousov , Tijl Coosemans Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> <20170825173851.09116ddc@kalimero.tijl.coosemans.org> <20170825234442.GO1700@kib.kiev.ua> <20170826202813.1240a1ef@kalimero.tijl.coosemans.org> <20170826184034.GR1700@kib.kiev.ua> From: Andreas Tobler Message-ID: Date: Sat, 21 Oct 2017 22:02:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170826184034.GR1700@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-CH Content-Transfer-Encoding: 7bit X-Scanned-By: Obelix Submit on 127.0.1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 20:02:50 -0000 On 26.08.17 20:40, Konstantin Belousov wrote: > On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: >> On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov wrote: >>> How does llvm unwinder detects that the return address is a garbage ? >> >> It just stops unwinding when it can't find frame information (stored in >> .eh_frame sections). GCC unwinder doesn't give up yet and checks if the >> return address points to the signal trampoline (which means the current >> frame is that of a signal handler). It has built-in knowledge of how to >> unwind to the signal trampoline frame. > So llvm just gives up on signal frames ? > >> A noreturn attribute isn't enough. You can still unwind such functions. >> They are allowed to throw exceptions for example. > Ok. > >> I did consider using >> a CFI directive (see patch below) and it works, but it's architecture >> specific and it's inserted after the function prologue so there's still >> a window of a few instructions where a stack unwinder will try to use >> the return address. >> >> Index: lib/libthr/thread/thr_create.c >> =================================================================== >> --- lib/libthr/thread/thr_create.c (revision 322802) >> +++ lib/libthr/thread/thr_create.c (working copy) >> @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr) >> static void >> thread_start(struct pthread *curthread) >> { >> + __asm(".cfi_undefined %rip"); >> sigset_t set; >> >> if (curthread->attr.suspend == THR_CREATE_SUSPENDED) > > I like this approach much more than the previous patch. What can be > done is to provide asm trampoline which calls thread_start(). There you > can add the .cfi_undefined right at the entry. > > It is somewhat more work than just setting the return address on the > kernel-constructed pseudo stack frame, but I believe this is ultimately > correct way. You still can do it only on some arches, if you do not > have incentive to code asm for all of them. > > Also crt1 probably should get the same treatment, despite we already set > %rbp to zero AFAIR. Did some commit result out of this discussion or is this subject still under investigation? Curious because I got this gcc PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 Tia, Andreas From owner-freebsd-current@freebsd.org Sat Oct 21 20:39:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CBCDE39ACF for ; Sat, 21 Oct 2017 20:39:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE3166B132; Sat, 21 Oct 2017 20:39:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v9LKdLXG008023 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Oct 2017 23:39:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v9LKdLXG008023 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v9LKdLKp008022; Sat, 21 Oct 2017 23:39:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Oct 2017 23:39:21 +0300 From: Konstantin Belousov To: Andreas Tobler Cc: Tijl Coosemans , freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20171021203921.GD2473@kib.kiev.ua> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> <20170825173851.09116ddc@kalimero.tijl.coosemans.org> <20170825234442.GO1700@kib.kiev.ua> <20170826202813.1240a1ef@kalimero.tijl.coosemans.org> <20170826184034.GR1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 20:39:31 -0000 On Sat, Oct 21, 2017 at 10:02:38PM +0200, Andreas Tobler wrote: > On 26.08.17 20:40, Konstantin Belousov wrote: > > On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: > >> On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov wrote: > >>> How does llvm unwinder detects that the return address is a garbage ? > >> > >> It just stops unwinding when it can't find frame information (stored in > >> .eh_frame sections). GCC unwinder doesn't give up yet and checks if the > >> return address points to the signal trampoline (which means the current > >> frame is that of a signal handler). It has built-in knowledge of how to > >> unwind to the signal trampoline frame. > > So llvm just gives up on signal frames ? > > > >> A noreturn attribute isn't enough. You can still unwind such functions. > >> They are allowed to throw exceptions for example. > > Ok. > > > >> I did consider using > >> a CFI directive (see patch below) and it works, but it's architecture > >> specific and it's inserted after the function prologue so there's still > >> a window of a few instructions where a stack unwinder will try to use > >> the return address. > >> > >> Index: lib/libthr/thread/thr_create.c > >> =================================================================== > >> --- lib/libthr/thread/thr_create.c (revision 322802) > >> +++ lib/libthr/thread/thr_create.c (working copy) > >> @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr) > >> static void > >> thread_start(struct pthread *curthread) > >> { > >> + __asm(".cfi_undefined %rip"); > >> sigset_t set; > >> > >> if (curthread->attr.suspend == THR_CREATE_SUSPENDED) > > > > I like this approach much more than the previous patch. What can be > > done is to provide asm trampoline which calls thread_start(). There you > > can add the .cfi_undefined right at the entry. > > > > It is somewhat more work than just setting the return address on the > > kernel-constructed pseudo stack frame, but I believe this is ultimately > > correct way. You still can do it only on some arches, if you do not > > have incentive to code asm for all of them. > > > > Also crt1 probably should get the same treatment, despite we already set > > %rbp to zero AFAIR. > > Did some commit result out of this discussion or is this subject still > under investigation? Nothing was done AFAIK. > > Curious because I got this gcc PR: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 > > Tia, > Andreas From owner-freebsd-current@freebsd.org Sat Oct 21 21:07:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06F0BE3A482; Sat, 21 Oct 2017 21:07:49 +0000 (UTC) (envelope-from mvoorhis@atom.mcvau.net) Received: from atom.mcvau.net (unknown [IPv6:2602:100:615f:bdb7:5054:ff:fe0a:d781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "atomvm.mcvau.net", Issuer "atomvm.mcvau.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B053B6BDF0; Sat, 21 Oct 2017 21:07:48 +0000 (UTC) (envelope-from mvoorhis@atom.mcvau.net) Received: from atom.mcvau.net (localhost [127.0.0.1]) by atom.mcvau.net (8.15.2/8.15.2) with ESMTPS id v9LL7f4i027709 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Oct 2017 17:07:41 -0400 (EDT) (envelope-from mvoorhis@atom.mcvau.net) Received: (from mvoorhis@localhost) by atom.mcvau.net (8.15.2/8.15.2/Submit) id v9LL7ejq021852; Sat, 21 Oct 2017 17:07:40 -0400 (EDT) (envelope-from mvoorhis) From: Michael Voorhis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23019.46875.929719.481108@atom.mcvau.net> Date: Sat, 21 Oct 2017 17:07:39 -0400 To: Ian Lepore Cc: Boris Samorodov , freebsd-current@FreeBSD.org, freebsd-virtualization@FreeBSD.org Subject: Re: host, bhyve vm and ntpd In-Reply-To: <1508523696.1383.75.camel@freebsd.org> References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> <1508517160.1383.63.camel@freebsd.org> <76ff7afb-3d3a-96f6-1275-89472ff5683d@passap.ru> <1508522667.1383.69.camel@freebsd.org> <30992c14-7b78-ab9f-5693-931e6ca41f1b@passap.ru> <1508523696.1383.75.camel@freebsd.org> X-Mailer: VM 8.2.0b under 25.3.1 (amd64-portbld-freebsd11.1) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on atom.mcvau.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 21:07:49 -0000 Ian Lepore writes: > Beyond that, I'm not sure what else to try. =A0It might be necessary = to > get some bhyve developers involved (I know almost nothing about it). NTPD behaves more normally on uniprocessor VMs. A FreeBSD bhyve-guest running on a freebsd host will select a different timecounter depending on whether it is a multiprocessor or a uniprocessor. My uniprocessor bhyve-vm selected TSC-low as the best timecounter in a uniprocessor. NTP functions there as expected. kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0= ) dummy(-1000000) kern.timecounter.hardware: TSC-low The very same VM, when given two total CPUs, selected HPET (if I recall) and the timekeeping with NTPD was unreliable, with many step-resets to the clock. From owner-freebsd-current@freebsd.org Sat Oct 21 22:16:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 733C3E3B652 for ; Sat, 21 Oct 2017 22:16:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06B136D699 for ; Sat, 21 Oct 2017 22:16:07 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 695d617b-b6ad-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 695d617b-b6ad-11e7-a893-25625093991c; Sat, 21 Oct 2017 22:15:58 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9LMFrKh014285; Sat, 21 Oct 2017 16:15:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508624153.1383.107.camel@freebsd.org> Subject: Re: host, bhyve vm and ntpd From: Ian Lepore To: Michael Voorhis Cc: Boris Samorodov , freebsd-current@FreeBSD.org, freebsd-virtualization@FreeBSD.org Date: Sat, 21 Oct 2017 16:15:53 -0600 In-Reply-To: <23019.46875.929719.481108@atom.mcvau.net> References: <2931f1cc-6574-b58d-4b94-5f77fa5cdb85@passap.ru> <1508512327.1383.55.camel@freebsd.org> <39bf2426-2edf-d485-7c81-519e931154be@passap.ru> <1508517160.1383.63.camel@freebsd.org> <76ff7afb-3d3a-96f6-1275-89472ff5683d@passap.ru> <1508522667.1383.69.camel@freebsd.org> <30992c14-7b78-ab9f-5693-931e6ca41f1b@passap.ru> <1508523696.1383.75.camel@freebsd.org> <23019.46875.929719.481108@atom.mcvau.net> Content-Type: multipart/mixed; boundary="=-85jbhbwt4hlyeaS0wt1C" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 22:16:08 -0000 --=-85jbhbwt4hlyeaS0wt1C Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote: > Ian Lepore writes: > > > > Beyond that, I'm not sure what else to try.  It might be necessary to > > get some bhyve developers involved (I know almost nothing about it). > NTPD behaves more normally on uniprocessor VMs. > > A FreeBSD bhyve-guest running on a freebsd host will select a > different timecounter depending on whether it is a multiprocessor or a > uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best > timecounter in a uniprocessor.  NTP functions there as expected. > > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000) > kern.timecounter.hardware: TSC-low > > The very same VM, when given two total CPUs, selected HPET (if I > recall) and the timekeeping with NTPD was unreliable, with many > step-resets to the clock. > Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it looks right.  I wonder if this is just a simple roundoff error in converting between 10.0MHz and SBT units?  If so, that could be wished away easily by using a power-of-2 frequency for the virtual HPET.  I wonder if the attached patch is all that's needed? -- Ian --=-85jbhbwt4hlyeaS0wt1C Content-Disposition: inline; filename="temp.diff" Content-Type: text/x-patch; name="temp.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/amd64/vmm/io/vhpet.c =================================================================== --- sys/amd64/vmm/io/vhpet.c (revision 324176) +++ sys/amd64/vmm/io/vhpet.c (working copy) @@ -51,7 +51,7 @@ __FBSDID("$FreeBSD$"); static MALLOC_DEFINE(M_VHPET, "vhpet", "bhyve virtual hpet"); -#define HPET_FREQ 10000000 /* 10.0 Mhz */ +#define HPET_FREQ 16777216 /* 16.7 (2^24) Mhz */ #define FS_PER_S 1000000000000000ul /* Timer N Configuration and Capabilities Register */ --=-85jbhbwt4hlyeaS0wt1C--