From owner-freebsd-stable@freebsd.org Sun Aug 25 12:03:50 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 97214DDE40 for ; Sun, 25 Aug 2019 12:03:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46GYh56PcVz3NbG; Sun, 25 Aug 2019 12:03:49 +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 x7PC3gpB009569 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 25 Aug 2019 15:03:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7PC3gpB009569 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7PC3gUX009568; Sun, 25 Aug 2019 15:03:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Aug 2019 15:03:42 +0300 From: Konstantin Belousov To: Trond =?utf-8?Q?Endrest=C3=B8l?= Cc: freebsd-stable@freebsd.org, emaste@freebsd.org Subject: Re: ntpd doesn't like ASLR on stable/12 post-r350672 Message-ID: <20190825120342.GN71821@kib.kiev.ua> References: <20190824204114.GG71821@kib.kiev.ua> <20190824222817.GJ71821@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46GYh56PcVz3NbG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.95 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.954,0]; IP_SCORE(0.00)[ip: (-2.52), ipnet: 2001:470::/32(-4.43), asn: 6939(-3.06), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 12:03:50 -0000 On Sun, Aug 25, 2019 at 12:40:22AM +0200, Trond Endrestøl wrote: > On Sun, 25 Aug 2019 01:28+0300, Konstantin Belousov wrote: > > > On Sun, Aug 25, 2019 at 12:19:43AM +0200, Trond Endrestøl wrote: > > > On Sat, 24 Aug 2019 23:41+0300, Konstantin Belousov wrote: > > > > > I tried changing command="/usr/sbin/${name}" to > > > > > command="/usr/bin/proccontrol -m aslr -s disable /usr/sbin/${name}" in > > > > > /etc/rc.d/ntpd, but that didn't go well. > > > > > > > > If you set kern.elf64.aslr.stack_gap to zero, does it help ? > > > > > > That helped. Thank you again. > > > > Can you verify is ntpd sets new rlimit(RLIMIT_STACK) for the main thread, > > and if yes, what this new limit is ? > > (gdb) > 5265 if (-1 == setrlimit(RLIMIT_STACK, &rl)) { > (gdb) print rl > $1 = {rlim_cur = 204800, rlim_max = 536870912} So they set the stack limit to 200K, am I right ? I suspect they do that because ntpd wires entire process address space, so 512M blows off all limits on wiring. I do not have a good idea how to make this behaviour compatible with the gap. Might be we can change the gap sizing parameter to KBs instead of percentage, and set the defaults in 64KB range. > > > aslr.stack_gap is the percentage for the gap on that stack, and since > > default size of the main stack limit is quite large 512M, even 3% > > (default gap upper limit) are whole 15M. If the new limit is less than > > 15M, there is a likely probability that only the gap is left after the > > rlimit(2) call, leaving no space for the program frames. > > > > At least this looks like a nice theory. > > -- > Trond. From owner-freebsd-stable@freebsd.org Sun Aug 25 12:24:03 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E15FADE693 for ; Sun, 25 Aug 2019 12:24:03 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46GZ7R36mKz3PZP for ; Sun, 25 Aug 2019 12:24:03 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 632DBDE692; Sun, 25 Aug 2019 12:24:03 +0000 (UTC) Delivered-To: stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6219ADE68F; Sun, 25 Aug 2019 12:24:03 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46GZ7Q1Vqyz3PZJ; Sun, 25 Aug 2019 12:24:01 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm1-x343.google.com with SMTP id l2so13277908wmg.0; Sun, 25 Aug 2019 05:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=zZ6WKY3O8X4I+U6oBekimjTf5ka+TAXgayDSFu6iQRs=; b=bmpGMbUAl4cR+QwEAtPTiOjp1JQ55gECaQWvoOlj40YBZ06057yT7tRCVQ9zf0HB5w rxzvO7ARPq/jsIg3JluiI9ePmQ7CAvqhHe55tHa9JWVv/px1uNmeQIttlHZv37hO8HW5 U889TQc41GJRQs3874RZiFYtcilj/7WHrEwt7er09CFMc0ajzN92ys133bwWz+EfJCMS dVXsjU+pCuJ+brioe9LFDsl8E0o5RCCmSN0g1vYQqVjnFRj77bxhQP48xYCv5No8L4B5 UCAptOSAcbnEj7eJKf9FLGozhfGRvSyTd9RT7lKRTQU/4oMyI3GkaK+f9gqtHUKJNpnb oKuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:mime-version:content-disposition:user-agent; bh=zZ6WKY3O8X4I+U6oBekimjTf5ka+TAXgayDSFu6iQRs=; b=OhNTW4fhovrITziqj44ToQmAnevWMXgZKGILObAsNV1uEnWmsztQVetlcGyjP5jIG7 9Ldfz+kKDYjcsHzGw4XTAReOj0GM8Gq50rdiJcxN6Q/VzC3mJLabn95msMCHh8yyY7d1 EZaUGgDbuzRJbkX/OIxoiEoicCTzAsoT6d/huc9OCP1fRvs/82P3YPgUHXZiaUt+XbZO f1AC+aGdbsWNATa5yMRqqCfuaxJauosQuiN6MV+AS+y+9COLoYnE61xe3QNIJW68pLoj YbPHYzsr/SgG42SE7+JKtism8deKpS1xH0NLsdhBSv9S5ZbbjBn+JO+ccfORzjJANNdH /ByQ== X-Gm-Message-State: APjAAAVm+qU3VBvB/gQJtVuuJBv4CnG4iFI3HVt5Ub2O6vHl6mFgCFDG Ezt9apEGWQZ0F38qi6MqWaGjLSiL X-Google-Smtp-Source: APXvYqx3fCVfqyhjoJXcSTXKcRM5xVmq/MUBcXfK3sh1OCAo5tmPwnFMYlMlABs/uEMtcUvtYLevew== X-Received: by 2002:a1c:9950:: with SMTP id b77mr16298780wme.46.1566735838523; Sun, 25 Aug 2019 05:23:58 -0700 (PDT) Received: from v2 (79.184.195.241.ipv4.supernova.orange.pl. [79.184.195.241]) by smtp.gmail.com with ESMTPSA id f6sm22755553wrh.30.2019.08.25.05.23.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Aug 2019 05:23:57 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 25 Aug 2019 13:23:32 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: hackers@freebsd.org Cc: current@freebsd.org, stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2019 Message-ID: <20190825122332.GA16293@v2> Mail-Followup-To: hackers@freebsd.org, current@freebsd.org, stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 46GZ7Q1Vqyz3PZJ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=bmpGMbUA; dmarc=none; spf=pass (mx1.freebsd.org: domain of etnapierala@gmail.com designates 2a00:1450:4864:20::343 as permitted sender) smtp.mailfrom=etnapierala@gmail.com X-Spamd-Result: default: False [-5.15 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.92)[-0.922,0]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[trasz@freebsd.org,etnapierala@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.43)[ip: (3.27), ipnet: 2a00:1450::/32(-3.01), asn: 15169(-2.34), country: US(-0.05)]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[trasz@freebsd.org,etnapierala@gmail.com]; FORGED_RECIPIENTS(0.00)[hackers@freebsd.org ..,hackers@freebsd.org ...]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[3.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 12:24:03 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - 2nd Quarter 2019 This quarter our report includes some interesting topics easily accessible to anyone, even if you are not a programmer: we report the link to a presentation of the 2019 FreeBSD survey results at BSDCan 2019 and describe an interesting experience of a 3-person hackaton, which might encourage you to host one yourself, possibly with more participants. We also provide some up to date information about the status of our IRC channels. For those who have some more technical skills, we give some news about the role of git in the FreeBSD project, describe the status of some tools to hunt bugs or enhance security and announce a clone of sysctl. Finally, those who are more experienced with programming will probably be interested in the great work that has been done with drivers: in particular, an aknowledgement is due to Alan Somers for having started to bring up to date our FUSE implementation, which was about 11 years behind. Other important improvements include a more user-friendly experience with trackpoints and touchpads enabled by default, much low level work on graphics, many new bhyve features, updates to the linux compatibility layer, various kernel improvements. Have a nice read! -- Lorenzo Salvadore __________________________________________________________________ FreeBSD Team Reports * Continuous Integration * FreeBSD Core Team * FreeBSD Graphics Team status report * IRC Admin * Ports Collection * Release Engineering Team Projects * bhyve - Live Migration * bhyve - Save/Restore * BIO_DELETE support for the swap pager * ENA FreeBSD Driver Update * FreeBSD SDIO and Broadcom FullMAC WiFi Support * FUSE * Fuzzing FreeBSD with syzkaller * Kernel ZLIB Update * Linux compatibility layer update * Lock-less delayed invalidation for amd64 pmap * Locking changes for vnodes during execve(2) * Mellanox Drivers Update * NFSv4.2 client/server implementation for FreeBSD * NUMA awareness in the FreeBSD kernel Architectures * Broadcom ARM64 SoC support * NXP ARM64 SoC support Third-Party Projects * Aberdeen Hackathon * Bring more Security Intelligence to FreeBSD * libvdsk - QCOW2 implementation * nsysctl 1.0 __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. Continuous Integration Links FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org/ FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins freebsd-testing Mailing List URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing freebsd-ci Repository URL: https://github.com/freebsd/freebsd-ci Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI FreeBSD CI weekly report URL: https://hackfoldr.org/freebsd-ci-report/ Contact: Jenkins Admin Contact: Li-Wen Hsu The FreeBSD CI team maintains continuous integration system and related tasks for the FreeBSD project. The CI system regularly checks the committed changes can be successfully built, then performs various tests and analysis of the results. The results from build jobs are archived in an artifact server, for the further testing and debugging needs. The CI team members examine the failing builds and unstable tests, and work with the experts in that area to fix the code or adjust test infrastructure. The details are of these efforts are available in the weekly CI reports. The FCP for CI policy is in "feedback" state, please provide any comments to freebsd-testing@ or other suitable lists. We had a testing working group in 201905 DevSummit Please see freebsd-testing@ related tickets for more information. Work in progress: * Fixing the failing test cases and builds * Adding drm ports building test against -CURRENT * Adding powerpc64 tests job: https://github.com/freebsd/freebsd-ci/pull/33 * Implementing automatic tests on bare metal hardware * Extending and publishing the embedded testbed * Planning for running ztest and network stack tests * Help more 3rd software get CI on FreeBSD through a hosted CI solution __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. * Core approved source commit bits for Doug Moore (dougm), Chuck Silvers (chs), Brandon Bergren (bdragon), and a vendor commit bit for Scott Phillips (scottph). * The annual developer survey closed on 2019-04-02. Of the 397 developers, 243 took the survey with an average completion time of 12 minutes. The public survey closed on 2019-05-13. It was taken by 3637 users and had a 79% completion rate. A presentation of the survey results took place at BSDCan 2019. * The core team voted to appoint a working group to explore transitioning our source code 'source of truth' from Subversion to Git. Core asked Ed Maste to chair the group as Ed has been researching this topic for some time. For example, Ed gave a MeetBSD 2018 talk on the topic. There is a variety of viewpoints within core regarding where and how to host a Git repository, however core feels that Git is the prudent path forward. * The project received many Season of Docs submissions and picked a top candidate. Google will announce the accepted technical writer projects on 2019-08-06. We are hoping for lots of new and refreshed man pages. __________________________________________________________________ FreeBSD Graphics Team status report Links Project GitHub page URL: https://github.com/FreeBSDDesktop Contact: FreeBSD Graphics Team Contact: Niclas Zeising The FreeBSD X11/Graphics team maintains the lower levels of the FreeBSD graphics stack. This includes graphics drivers, graphics libraries such as the MESA OpenGL implementation, the X.org xserver with related libraries and applications, and Wayland with related libraries and applications. In the last report, half a year ago, several updates and changes had been made to the FreeBSD graphics stack. To further improve the user experience, and to improve input device handling, evdev was enabled in the default configuration in late 2018. Building on that, we have enabled IBM/Lenovo trackpoints and elantech and synaptics touchpads by default as well. The input device library libinput has been updated as the last in a series of updates bringing the userland input stack up to date. This is work that was started in 2018. We have made several improvements to the drm kernel drivers. A long-standing memory leak in the Intel (i915) driver has been fixed, and several other updates and improvements have been made to the various drm kernel driver components. A port of the drm kernel drivers using the 5.0 Linux kernel sources has been created and committed to FreeBSD ports as graphics/drm-devel-kmod. This driver requires a recent Linux KPI and is only available on recent versions of FreeBSD CURRENT. This version of the driver contains several development improvements. The generic drm (drm.ko) driver as well as the i915 (i915kms.ko) driver can now be unloaded and reloaded to ease in development and testing. This causes issues with the virtual consoles, however, so an SSH connection is recommended. To aid debugging i915kms.ko use of debugfs has been improved, but there are still limitations preventing it from being fully functional. Since debugfs is based on pseudofs it is possible that this will prevent a fully functional debugfs in its current state, so we might have to look into adding the required functionality to pseudofs or use another framework. The new in-kernel drm driver for VirtualBox, vboxvideo.ko has been ported from Linux. Support is currently an experimental work in progress. For example the virtual console won't update after loading the driver, but X- and Wayland-based compositors are working. Mesa has been updated to 18.3.2 and switched from using devel/llvm60 to use the Ports default version of llvm, currently devel/llvm80. Several userland Xorg drivers, applications, and libraries have been updated, and other improvements to the various userland components that make up the Graphics Stack have been made. We have also continued our regularly scheduled bi-weekly meetings, although work remains in sending out timely meeting minutes afterwards. People who are interested in helping out can find us on the x11@FreeBSD.org mailing list, or on our gitter chat: https://gitter.im/FreeBSDDesktop/Lobby. We are also available in #freebsd-xorg on EFNet. We also have a team area on GitHub where our work repositories can be found: https://github.com/FreeBSDDesktop __________________________________________________________________ IRC Admin Contact: IRC Admin The FreeBSD IRC Admin team manages the FreeBSD Project's presence and activity on the freenode IRC network, looking after: * Registration and management of channels within the official namespace (#freebsd*) * Channel moderation * Liaising with freenode staff * Allocating freebsd/* hostmask cloaks for users * General user support relating to channel management While the FreeBSD Project does not currently endorse IRC as an official support channel (see here and here), as it has not been able to guarantee a consistent or positive user experience, IRC Admin has been working toward creating a high quality experience, by standardising channel administration and moderation expectations, and ensuring the projects ability to manage all channels within its namespace. In the last quarter, IRC Admin: * Cleaned up (deregistered) registrations for channels that were defunct, stale, out of date, or had founders that were inactive (not seen for > 1 year). Channels that were found to be otherwise active have been retained. FreeBSD now has ~40 channels registered from a previous total of over 150. * Documented baseline configuration settings in the Wiki for channels, including ChanServ settings, channel modes, registration policy, etc. * Established multiple documented methods for reporting user abuse or other channel issues to IRC Admin for resolution Upcoming changes: * Work with existing #freebsd* channels to standardise channel management, settings and access. * Migrate, forward and/or consolidate existing or duplicate #freebsd* channels to channels with a standard naming convention. * Work with unofficial ##freebsd* channels to migrate them to the official #freebsd* channels if suitable * Update existing IRC-related website and documentation sources the describe the official state of project managed IRC presence on freenode. Lastly, and to repeat a previous call, while the vast majority of the broader user community interacts on the freenode IRC network, the FreeBSD developer presence still needs to be significantly improved on freenode. There are many opportunities to be had by increasing the amount and quality of interaction between FreeBSD users and developers, both in terms of developers keeping their finger on the pulse of the community and in encouraging and cultivating greater contributions to the Project over the long term. It is critical to have a strong developer presence amongst users, and IRC Admin would like again to call on all developers to join the FreeBSD freenode channels to increase that presence. Users are invited to /join #freebsd-irc on the freenode IRC network if they have questions, ideas, constructive criticism, and feedback on how the FreeBSD Project can improve the service and experience it provides to the community on IRC. __________________________________________________________________ Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team: URL: https://www.freebsd.org/portmgr/index.html Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The following was done during the last quarter by portmgr to keep things in the Ports Tree going: During the last quarter the number of ports rose to just under 37,000. At the end of the quarter, there were 2146 open PRs and 7837 commits (excluding 499 on the quarterly branch) from 172 committers. This shows a slight decrease in activity compared to previous quarter. People come and go, last quarter we welcomed Pedro Giffuni (pfg@), Piotr Kubaj (pkubaj@) and Hans Petter Selasky (hselasky@). Pedro and Hans Petter were already active as src committers. We said goodbye to gordon@, kan@, tobez@, and wosch@. On the infrastructure side, a new USES=3Dcabal was introduced and various default versions were updated: MySQL to 5.7, Python to 3.6, Ruby to 2.5, Samba to 4.8 and Julia gained a default version of 1.0. The web browsers were also updated: Firefox to 68.0 and Chromium to 75.0.3770.100 During the last quarter, antoine@ ran a total of 41 exp-runs to test various package updates, bump the stack protector level to "strong", switch the default Python version to 3.6 as opposed to 2.7, remove sys/dir.h from base which has been deprecated for over 20 years, and convert all Go ports to USES=3Dgo. __________________________________________________________________ Release Engineering Team Links FreeBSD 11.3-RELEASE schedule URL: https://www.freebsd.org/releases/11.3R/schedule.html FreeBSD 11.3-RELEASE announcement URL: https://www.freebsd.org/releases/11.3R/announce.html FreeBSD 12.1-RELEASE schedule URL: https://www.freebsd.org/releases/12.1R/schedule.html FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the second quarter of 2019, the FreeBSD Release Engineering team started the 11.3-RELEASE cycle, with the code slush starting May 3rd. Throughout the cycle, there were three BETA builds and three RC builds, all of which in line with the originally-published schedule. The final RC build started June 28th, with the final release build targeted for July 5th. FreeBSD 11.3-RELEASE will be the fourth release from the stable/11 branch, building on the stability and reliability of 11.2-RELEASE. The FreeBSD Release Engineering Team also published the schedule for the 12.1-RELEASE, targeted to start September 6th. One important thing to note regarding the published schedule is it excludes a hard freeze on the stable/12 branch, as a test run for eliminating code freezes entirely during a release cycle. Commits to what will be the releng/12.1 branch will still require explicit approval from the Release Engineering Team, however. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Much of this work was sponsored by the FreeBSD Foundation and Rubicon Communications, LLC (Netgate). __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. bhyve - Live Migration Links Github wiki - How to Live and Warm Migrate a bhyve guest URL: https://github.com/FreeBSD-UPB/freebsd/wiki/Virtual-Machine-Migrat= ion-using-bhyve Github - Warm Migration branch URL: https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_migrati= on Github - Live Migration branch URL: https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_migrati= on_dev Contact: Elena Mihailescu Contact: Darius Mihai Contact: Mihai Carabas The Migration feature uses the Save/Restore feature to migrate a bhyve guest from a FreeBSD host to another FreeBSD host. To migrate a bhyve guest, one needs to start an empty guest on the destination host from a shared guest image using the bhyve tool with the -R option followed by the source host IP and the port to listen to migration request. On the source host, the migration is started by executing the bhyvectl command with the --migrate or --migrate-live option, followed by the destination host IP and the port to send to the messages. New features added: * Clear the dirty bit after each migration round * Extend live migration to highmem segment Future tasks: * Refactor live migration branch * Rebase live migration * Extend live migration to unwired memory This project was sponsored by Matthew Grooms. __________________________________________________________________ bhyve - Save/Restore Links Github repository for the snapshot feature for bhyve URL: https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_snapshot Github wiki - How to Save and Restore a bhyve guest URL: https://github.com/FreeBSD-UPB/freebsd/wiki/Save-and-Restore-a-virtual-m= achine-using-bhyve Github wiki - Suspend/resume test matrix URL: https://github.com/FreeBSD-UPB/freebsd/wiki/Suspend-Resume-test-ma= trix Phabricator review - bhyve Snapshot Save and Restore URL: https://reviews.freebsd.org/D19495 Contact: Elena Mihailescu Contact: Darius Mihai Contact: Mihai Carabas The Save/Restore for bhyve feature is a suspend and resume facility added to the FreeBSD/amd64's hypervisor, bhyve. The bhyvectl tool is used to save the guest state in three files (a file for the guest memory, a file for the states of various devices and the state of the CPU, and another one for some metadata that is used in the restore process). To suspend a bhyve guest, the bhyvectl tool must be run with the --suspend option followed by the guest name. To restore a bhyve guest from a checkpoint, one simply has to add the -r option followed by the main state file (the same file that was given to the --suspend option for bhyvectl) when starting the VM. New features added: * Open ticket on Phabricator * Apply feedback received from community Future tasks: * Add suspend/resume support for nvme * Add suspend/resume support for virtio-console * Add suspend/resume support for virtio-scsi * Add TSC offsetting for restore for AMD CPUs This project was sponsored by Matthew Grooms. __________________________________________________________________ BIO_DELETE support for the swap pager Contact: Doug Moore Contact: Alan Cox Contact: Mark Johnston An ongoing project aims to teach the swap pager to send SCSI UNMAP or ATA TRIM commands to the swap device when a block of swap space has been freed, for example when the application owning that block is exiting. SSDs have become commonplace and feature low latency for random I/O requests. This makes them appealing for use as swap devices, since lower latencies mean that applications spend less time blocked while waiting for a page-in from the swap device. To maximize write performance, some SSDs require the operating system to send a notification to the disk when a sector is no longer in use; this helps the disk optimize their usage of NAND flash cells. In FreeBSD such a notification is called a BIO_DELETE. FreeBSD's UFS and ZFS filesystems have for a long time been able to transmit BIO_DELETE requests to the devices backing the filesystem. For example, for UFS this support is enabled by specifying -t in newfs(8) or tunefs(8)'s parameters. However, FreeBSD has historically not had a corresponding implementation for swap devices. Thanks to Doug Moore, as of r349286 in -CURRENT and r349930 in stable/12 swapon(8) can send BIO_DELETE to all blocks on the specified device immediately prior to configuring it as a swap device. This is enabled by specifying -E in the swapon(8) parameters, or by adding the "trimonce" option to the swap device's /etc/fstab entry. Some in-progress work on the swap pager implements online block deletion, in which BIO_DELETE is transmitted for blocks as they are freed by applications; this will hopefully be implemented in FreeBSD 13.0. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Maciej Bielski Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. ENAv2 has been under development for FreeBSD, similar to Linux and DPDK. Since the last update internal review and improvements of the patches were done, followed by validation on various AWS instances. Completed since the last update: * Upstream of the ENAv2 patches - revisions r348383 - r348416 introduce a major driver upgrade to version v2.0.0. Along with various fixes and improvements, the most significant features are LLQ (Low Latency Queues) and independent queues reconfiguration using sysctl commands. * Implement NETMAP support for ENA Todo: * Internal review and upstream of NETMAP support This project was sponsored by Amazon.com Inc. __________________________________________________________________ FreeBSD SDIO and Broadcom FullMAC WiFi Support Links FreeBSD Wiki SDIO page URL: https://wiki.freebsd.org/SDIO Contact: Bjoern Zeeb SDIO is an interface designed as an extension to SD Cards to allow attachments of various other peripherals, e.g., WiFi or Bluetooth. Work has been ongoing by Ilya Bakulin on the MMCCAM stack to provide the infrastructure to be able to have SD cards and SDIO devices attached side-by-side facilitating FreeBSD's CAM framework. Based on this excellent work over the last years, SDIO support was finished earlier this year and committed to FreeBSD HEAD with the intention to merge to 12 at a later time. Facilitating the newly available SDIO bus, work started to port Broadcom's FullMAC WiFi driver. This work is still in progress and expected to complete later this year. With this WiFi support for the Raspberry Pi and other embedded boards will become available. Likewise drivers for other SDIO devices can be developed now. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ FUSE Contact: Alan Somers FUSE (File system in USErspace) allows a userspace program to implement a file system. It is widely used to support out-of-tree file systems like NTFS, as well as for exotic pseudo file systems like sshfs. FreeBSD's fuse driver was added as a GSoC project in 2012. Since that time, it has been largely neglected. The FUSE software is buggy and out-of-date. Our implementation is about 11 years behind. During Q2 I nearly finished the FUSE overhaul that I begain in Q1. I raised the protocol level from 7.8 to 7.23, fixed many bugs (see 199934, 216391, 233783, 234581, 235773, 235774, 235775, 236226, 236231, 236236, 239291, 236329, 236379, 236381, 236405, 236327, 236466, 236472, 236473, 236474, 236530, 236557, 236560, 236647, 236844, 237052, 237181, 237588, and 238565), and added the following features: * Optional kernel-side permissions checks (`-o default_permissions`) * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK * Allow interrupting FUSE operations * Support named pipes and unix-domain sockets in fusefs file systems * Forward UTIME_NOW during utimensat(2) to the daemon * kqueue support for /dev/fuse * Allow updating mounts with mount -u * Allow exporting fusefs file systems over NFS * Server-initiated invalidation of the name cache or data cache * Respect RLIMIT_FSIZE * Try to support servers as old as protocol 7.4 I also added the following performance enhancements: * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags * Cache file attributes * Cache lookup entries, both positive and negative * Server-selectable cache modes: writethrough, writeback, or uncached * Write clustering * Readahead * Use counter(9) for statistical reporting All that remains is to finish merging the branch, and deal with any newly introduced bugs. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Fuzzing FreeBSD with syzkaller Links syzkaller URL: https://github.com/google/syzkaller Contact: Mark Johnston Contact: Andrew Turner Contact: Michael Tuexen Contact: Ed Maste See the syzkaller entry in the 2019q1 quarterly report for an introduction to syzkaller. syzkaller continues to find FreeBSD kernel bugs. A number of such bugs have been fixed in the past quarter, and we continue to investigate and fix bug reports from syzkaller. Work to extend syzkaller's capabilites has progressed: Andrew Turner has implemented support for fuzzing the 32-bit compatibility layer in amd64 kernels, helping illuminate some of the darker corners of the kernel, and it is now possible to use bhyve as a VM backend to syzkaller, so it is now efficient and convenient to fuzz FreeBSD on FreeBSD. Some planned work includes: enabling the use of ZFS as the base filesystem for fuzzer VMs; extending the range of system calls and ioctls covered by syzkaller; enabling LLVM sanitizers in the kernel so as to catch more issues; and making use of netdump(4) to capture kernel dumps for panics found by syzkaller, making it much easier to diagnose bugs for which syzkaller was unable to find a reproducible test case. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Kernel ZLIB Update Links Review D19706 URL: https://reviews.freebsd.org/D19706 Contact: Yoshihiro Ota Kernel zlib upgrade is in progress. Xin (delphij@) and I have been working closely for zlib upgrade. We relocated contrib/zlib to sys/contrib/zlib in order for kernel code to access zlib in the tree. We also deleted dead code that depended on zlib and inflate - inflate is a fork of unzip to uncompress gzip files. We also renamed crc.h to avoid conflicts with zlib/crc.h. Next goal is to compile both old zlib and new zlib into the kernel allowing to switch each zlib user independently. __________________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala The project aims to improve the Linux compatibility layer, to make it more compatible with recent Linux releases, and also to lower the bar for potential developers who want to start contributing to it. The initial effort focused on tooling, to make it easier to debug problems and to prevent future regressions. The first part involved making it possible to use Linux strace(1) utility and providing it as linux-c7-strace package. The reason is that while FreeBSD truss(1) and ktrace(1) can trace Linux binaries, they cannot decode Linux-specific flags and structures. The second part involved providing Linux Test Project binaries as linux-ltp package. There is ongoing work to hook it up to the FreeBSD CI infrastructure http://ci.FreeBSD.org. There was also a number of improvements and fixes to bugs discovered in the process. One of them (not yet committed) fixes binaries linked against newer version of libc, effectively unbreaking binaries from recent Ubuntu releases. This project was sponsored by FreeBSD Foundation. __________________________________________________________________ Lock-less delayed invalidation for amd64 pmap Contact: Konstantin Belousov The Virtual Memory machine-dependent layer (pmap) on amd64 needs to track all mappings for the managed physical memory pages, to be able to either destroy all of them (for page-out), or change them from writeable to read-only (e.g. to sync the page content to file, without racing with modifications through user writes). The mappings are accounted by creating pv_entry which records the address space (implicitly, by linking the pv entry to pmap) and the virtual address of the mapping. Previous work split the lock protecting the pv entries lists from other VM locks into the pvh_global_lock lock, which was global for all address spaces. You can see it in i386 pmap.c still. Later, hashed per-page pv lists locks were introduced, which would reduce contention on pv lists maninulations for different pages, but unfortunately the pvh_global_lock was still needed to guarantee the safety of some operations. Problem arises because amd64 pmap uses pmap lock to protect page tables and TLB consistency, which is per-pmap locks different from pv lists locks. When updating page table entry, we never drop pmap lock until the necessary TLB invalidation is done globally, including signalling other CPUs with IPI. But pv list locks can be unlocked before the necessary invalidation is done. So for instance when pmap is asked to remove all mappings of the specific page (pmap_remove_all(9)), it checks pv list of the page to find the mappings. The list might appear empty despite other CPUs TLB were not yet invalidated. If such page is reused, other CPUs might change its content using cached TLB entries. Allowing that means allowing both silent data corruption and opening security hole. So the global pvh lock was held until all pmaps invalidated their TLBs. This mechanism has obvious scalability issues, and instead a generation-count based scheme for handling delayed invalidation (DI) was developed, where each thread that might remove entry from pv list acquired a generation number and marked the page with it, see pmap_delayed_invl_page(9). Then, on e.g. pmap_remove_all(9) or pmap_remove_write(9), pmap code waits for the maximum current thread's invalidation generation number to pass the page's generation, which guarantees that all required TLB invalidations are done. Original implementation of DI allowed to get rid of pvh_global_lock, and only used a private mutex to handle sequential queueing of the coming and leaving threads, protecting a bounded region. A problem with that appeared e.g. in scalability benchmarks which did massive parallel unmaps, causing most of the threads to contend on DI queueing. Current implementation of DI switched to lock-less queue algorithm using the approach proposed by T.L. Harris and relying on double-CAS to coalesce generation count and queueing. It uses ifuncs to select either previous locked DI or current lock-less implementation, only old AMD Athlons which did not implemented the CMPXCHG16B instruction falls to the locked implementation by default. Lock-less implementation still blocks the waiting thread on turnstile to avoid priority-inversion issues, but practically the wait occur very rare, typical parallel buildworld generates single-digit number of the events. The patch got a lot of testing from Peter Holm, continuous reviews by Mark Johnston while I worked out bugs and live-lock problems in the implementation, and additional testing by Mateusz Guzik who helped to identify a priority inversion bug with the wait. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Locking changes for vnodes during execve(2) Contact: Konstantin Belousov The execve(2) family of syscalls replaces the executing image in the current process. The file containing the program text, data, and arbitrary other pre-initialized segments for the newly activated image is usually called the text file. FreeBSD marks the text file as such, the mark is mutually exclusive with any opening of the file for write. In other words, file opened for write cannot be executed, and text file cannot be opened for write. During the execve(2) syscall processing, kernel needs to lock the text file' vnode. This is done both to satisfy the VFS calls protocol, and to ensure that there is no incompatible parallel changes occuring to the text vnode. A vnode can be locked either in exclusive mode, which is mutually incompatible with any other lock acquisition, or in shared mode, which is only incompatible with exclusive requests, but allows other shared owners. In principle, there is no reason why would execve(2) need an exclusive vnode lock, since it does not modify neither content nor metadata for the text vnode. The only exception is the marking of the vnode as text, which was done using VV_TEXT flag in v_vflag and protected by the vnode lock. Since we modify v_vflag, the vnode lock protecting the modification should be taken exclusive. The end result is that execve(2)'s of the same file are serialized. For instance, if user runs parallel build, which executes more than one job for compiling, all invocation of the compiler are serialized during execve(2). The count of opens for write is contained in other struct vnode member named v_writecount, which was protected by the vnode lock as well. Since text is mutually exclusive with an open for write, I reused v_writecount to indicate text references. Now, negative v_writecount counts the number of text references. The v_writecount content is literally protected by the vnode interlock, but normally all mutators also own vnode lock at least in the shared mode. This way, we no longer need to acquire exclusive text vnode lock during execve(2), removing the serializing point. Additional positive effect is that we started to account the precise number of text references on the vnode. Before, we cleared VV_TEXT on the last unmap of the text vnode, potentially allowing obscure DoS where mapping the text file while it is executed prevented writes until the mapping is destroyed. Now we mark the mappings for text explicitly in the vm_map_entry and dereference v_writecount by +1 when such entry is unmapped. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Mellanox Drivers Update Links Mellanox OFED for FreeBSD Documentation URL: http://www.mellanox.com/page/products_dyn?product_family=3D193&mta= g=3Dfreebsd_driver Contact: Slava Shwartsman Hans Petter Selasky Konstantin Belousov The mlx5 driver provides support for ConnectX-4 [Lx], ConnectX-5 [Ex] and ConnectX-6 [Dx] adapter cards. The mlx5en driver provides support for Ethernet adapter cards, whereas mlx5ib driver provides support for InfiniBand adapters and RDMA over Converged Ethernet (RoCE). Following updates done in mlx5 drivers: * 200Gb/s ConnectX-6 Ethernet: Added support for Mellanox Socket Direct Adapters which allows, among the rest of the capabilities, to run up to 200Gb/s on a PCIe Gen 3.0 on a LAG interface. * Support for "BlueField" - Multicore System On A Chip: Added support for RShim driver for BlueField Multicore System On A Chip(SOC). The RShim driver provides access to the RShim resources on the BlueField target accessible from an external host machine. The current RShim version provides device files for boot image push and virtual console access. It also creates virtual network interface to connect to the BlueField target and provides access to internal RShim registers. * Firmware Burning and Diagnostics Tools: Added MSTFLINT to ports, this package contains a burning and diagnostic tools for Mellanox NICs. This package contains following tools: mstflint - Tools which allows to query and burn firmware. mstconfig - This tool queries and sets non-volatile configurable options for Mellanox HCAs. mstregdump - This utility dumps hardware registers from Mellanox hardware. mstmcra - This debug utility reads/writes a to/from the device configuration register space. mstvpd - This utility dumps the on-card VPD. and more. * OFED-FreeBSD-v3.5.1 Upstream: Pushed upstream and MFCed OFED-FreeBSD-v3.5.1 driver - more details on the content of this update can be found in Mellanox OFED for FreeBSD documentation page. General updates: * Submitted papers for EuroBSDcon for a joint talk with Netflix titled "Kernel TLS and TLS Hardware Offload". The papers were accepted. * Mellanox is intensively working to improve its cooperation with the FreeBSD community. As part of this effort, FreeBSD users are invited to propose features and enhancements to further develop and enrich the end-user experience. In addition, Mellanox continues to identify and present the right solutions to meet customers' needs. This project was sponsored by Mellanox Technologies. __________________________________________________________________ NFSv4.2 client/server implementation for FreeBSD Links current sources URL: https://svnweb.freebsd.org/base/projects/nfsv42 Contact: Rick Macklem NFSv4.2 is a newer minor version of NFSv4, made up of a set of optional operations/features. A majority of these operations are related to the POSIX operations posix_fadvise(2), posix_fallocate(2) and lseek(2)'s support for SEEKHOLE/SEEKDATA. There is also a Copy operation that allows a byte range of a file to be copied to another file locally on the NFS server, avoiding data transfer over the wire in both directions. FreeBSD-current now has a Linux compatible copy_file_range(2) syscall that will invoke this Copy operation on NFSv4.2 mounts. There is also support for MAC labelling, but it requires changes to the RPCSEC_GSS implementation to add V3 support and, as such, may not happen soon. The implementation of NFSv4.2 (RFC-7862) is progressing nicely. At this time, the LayoutError, IOAdvise, Allocate and Copy operations have been implemented. There is still work to be done on Copy, to add asynchronous support, so that large copies do not result in a long delay for the RPC's reply. The major operation that will be implemented next is Seek, so that lseek(SEEKHOLE/SEEKDATA) will work for the NFSv4.2 mounts. It is hoped that this implementation will be ready for FreeBSD-current/head in time for the FreeBSD-13 release. Testing is always appreciated and can be done by downloading the modified kernel from the svn repository in base/rojects/nfsv42 and then building and testing it on a couple of recent FreeBSD-current systems. If anyone is conversant with Kerberos and wants to take on the challenge of adding RPCSEC_GSS_V3 support to the kernel RPC, a patch that does that would also be greatly appreciated. __________________________________________________________________ NUMA awareness in the FreeBSD kernel Contact: Jeff Roberson Contact: Andrew Gallatin Contact: Mark Johnston A set of patches to improve the state of NUMA awareness in the FreeBSD kernel are being developed and refined. This work also aims to generally improve the performance of FreeBSD's memory management subsystem on systems with many CPUs. FreeBSD 12.0 featured a number of large changes which improve its performance on systems with a non-uniform memory architecture. That is, systems in which memory access latency for a given address varies depending on the CPU. Another round of improvements is being developed and will soon be available in FreeBSD-CURRENT. Short descriptions of some of these patches follow; a few have already been committed to FreeBSD-CURRENT. In FreeBSD terminology, a memory page whose contents may not be evicted is referred to as "wired." Pages may be wired under different circumstances: for instance, all kernel memory is wired, and userland applications may request that ranges of memory be wired using the mlock(2) and mlockall(2) system calls. FreeBSD has historically defined a system-wide limit on the number of wired pages so as to avoid deadlocks that may arise when too much of a system's memory cannot be reclaimed to satisfy new memory allocations. This limit was applied only to userland wiring requests, but kernel wirings were counted against the limit, so a large source of kernel wirings could cause mlock(2) failures. This occurs frequently with a large ZFS ARC, for example. In FreeBSD-CURRENT this limit has been changed such that only userland wirings are counted against the limit; the kernel contains a number of mechanisms to apply back-pressure to kernel memory usage, so the use of a global limit on all wirings did not provide much benefit. This fixes a common problem on large ZFS systems, and helps enable some other architectural improvements to the code which manages page wirings. FreeBSD has historically maintained two separate reference counters in the structure which describes a single physical page of memory. These counters initially had quite different properties, but have over time become more and more similar. Some work to merge the two counters has landed in FreeBSD-CURRENT. This does not have any user-visible effects, but it simplifies the page management code and removes a large amount of code which existed solely to transform references of one type to the other. Such code also made use of heavily contended locks, so the simplification improved kernel scalability for some workloads and has enabled further scalability improvements. UMA is the slab allocator used in FreeBSD's kernel. It is the backend which services virtually all dynamic memory allocations performed in the kernel. The first round of NUMA improvements added NUMA awareness to the "keg" layer of UMA, which allocates and manages slabs. However, the frontend of UMA, which provides several layers of caching for objects, did not provide domain-aware caching, so over time the caches would become "polluted" with objects from different memory domains. However, this caching layer is being modified to ensure that objects from different memory domains are partitioned, helping ensure that consumers can perform domain-local allocations and frees efficiently. This will enable a global "first-touch" allocation policy for UMA-managed objects. During boot, the FreeBSD kernel allocates a number of static data structures to track physical memory. These structures have historically lived in the lowest available range of physical memory, so they many not inhabit the same NUMA domain as the memory that they track. This is suboptimal when one tries to affinitize a workload to a particular NUMA domain: if while executing the workload the kernel frequently accesses page structures for local memory, and the page structures themselves are not placed in local memory, the kernel will perform many remote memory accesses. Some in-progress work for the amd64 platform creates multiple arrays of page tracking structures, one per NUMA domain, and ensures that each array is local to its domain. This complicates the task of initializing kernel data structures during boot, but can substantially reduce the amount of cross-domain communication that occurs while the kernel is performing useful work. Similarly, some patches to affinitize per-CPU structures are being developed; while most per-CPU memory allocations already return CPU-local memory, some structures allocated during boot are not yet properly placed with respect to the accessing CPU's memory domain. This project was sponsored by Netflix. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Broadcom ARM64 SoC support Contact: Michal Stanek Contact: Kornel Duleba Contact: Marcin Wojtas The Semihalf team continued working on FreeBSD support for the Broadcom BCM5871X SoC series BCM5871X are quad-core 64-bit ARMv8 Cortex-A57 communication processors targeted for networking applications such as 10G routers, gateways, control plane processing and NAS. Completed since the last update: * iProc PCIe root complex (internal and external buses): fixes and improvements, including adding a BCM58712 quirk to GICv2m driver * BNXT Ethernet support: sys/dev/bnxt.c driver has been extended to support the BCM58700 variant, and the iflib was made to work without IO cache coherency In progress: * Crypto engine acceleration for IPsec offloading. Todo: * Upstreaming of work. This work is expected to be submitted/merged to HEAD in the second half of 2019. This project was sponsored by Juniper Networks, Inc. __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Already completed: * Platform base support (ramp-up multi-user SMP operation with UART) * SATA 3.0 In progress: * USB3.0 * SD/MMC * I2C Todo: * Ethernet support * GPIO * QSPI * Upstreaming of developed features. This work is expected to be submitted/merged to HEAD in the Q4 of 2019. This project was sponsored by Alstom Group. __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Aberdeen Hackathon At BSDCam in Cambridge last year we had a discussion to create a template Hackathon in the same way we have a template for Devsummits. To test out the idea I was convinced (I swear tricked is the correct word) to host a Hackathon in Aberdeen. As a project I think we benefit a lot from hackathons, but they do take a little organisation. The worst part of this is dealing with getting money from attendees so you can pay for events. I spoke with Deb Goodkin from the foundation at BSDCam and we arranged to use their new EventBrite based system to handle ticketing. Overall this system made it straight forward for attendees to register and get me their details and requirements. After the event the expenses were then recouped from the foundation. This was much easier than me putting together a custom system or even setting up and using EventBrite myself. The hackathon went well, you can read in Benedict and Kristof's reports that follow, but it was less well attended than I originally expected. For hackers planning future hackathons remember to take heed of common national holidays (we could have planned the event to not land at Easter) and expect major geopolitical events to make things unpredictable (we knew Brexit would do something, but not when). I need to thank the University of Aberdeen for providing the location for the Hackathon and to encourage you to run a hackathon where you are. The next one should be in your home town. Benedict Reuschling The hackathon in Aberdeen was happening in the week of Easter at the University of Aberdeen. Although only Kristof Provost (kp@) and myself joined our host Tom Jones, I still consider it a productive week for us. The overall theme of the hackathon was networking and each of us provided something towards that goal (be it PRs, submitting unfinished work, or other bits and pieces). We got together the night of Tuesday, April 16 over dinner and talked about what our plans were for the week. Kristof and I had talked at AsiaBSDcon when I took his tutorial about Testing in FreeBSD that we should add a chapter about it in the developers handbook. We also used our first meeting to synchronize each other about the latest news in FreeBSD from our developers viewpoint. The next day, we met up at the Frazer Noble building where the hackathon was taking place. It was one of the newer buildings on campus, nicely integrated into the older houses of the city. Since we were only a handful, we sat in Tom's office for the hackathon, which had plenty of room. He also showed us the room where we are supposed to be having the hackathon if we were more people and Tom gave us a little tour. Working in a university myself, I'm always interested in how other education organizations are structured and the rooms and equipment they provide for learning. Overall, my impression was that there is a good amount of space and equipment available, which we could have used in the hackathon. After returning, we decided to use a special tag in the commits we would be doing to identify them as coming from this hackathon. We chose "Event:" for it as it is a general enough term to be used at other events like conferences, too. The "Sponsored by:" line we used in the past is more for companies or individuals sponsoring certain features, so I created a review to add this line to the committers guide. Kristof had a couple of changes to the pf chapter in the FreeBSD handbook for me, so I started going through those. I created a review for him and the commit was made there and then, making use of the short feedback cycle. Originally, we thought about bringing in people via hangouts, but then resolved to contact people via our usual IRC channel if we needed their input. Kristof and Tom worked on some network specific stuff, whereas I started work on creating an initial draft for the testing chapter. We would occasionally start talking about something and then return to our work in silence. If we needed to coordinate or had questions, we simply asked and could continue once we got our answer. This provided a nice atmosphere to work in. I tackled some doc PRs while Kristof found a bug in pf and fixed it. The afternoons were spent at different locations within walking distance. Tom made sure we got a good impression on how it is to be a student and that there is both taste and variety of food available. In the evenings, Tom drove us into town to have dinner at various restaurants over the week. Aberdeen has a lot to offer as a city. Starting from the second day, Kristof and I would meet up at my hotel, which was close to the Aberdeen beach and walk along it to the University. According to Tom, it is possible to see Dolphins when the weather is right and the gulf stream provides the city with enough warmth that the winters aren't as bad as you'd think this far up north. Tom also gave us a tour of the zoological department of the university, which offered a beautiful garden with various plants and trees, as well as a museum with zoological specimen. This offered a great spot for photographs and to unwind a bit from the technical discussions we've had. Tom also had t-shirts made for the event, which are already rare collectors items. I had to return on Sunday, so Tom took us on a tour of the Scottish highlands in his car the day before. We stopped at a couple of places to take pictures and Tom would explain at lot to us having lived there all his life. We came to Stonehaven and had fish and chips there from a take-out restaurant that had a lot of awards for sustainable fishing. This was certainly a highlight for the week and even then, we couldn't stop talking about FreeBSD and networking. Although more people would maybe have produced more output, the three of us were certainly productive as a small group. It also made planning and coordination easier and more flexible. Tom Jones had done a lot of preparation and was an excellent guide. I would encourage him to host another such hackathon in the future and hope that next time, more people will take a trip to Aberdeen to spend some time hacking on FreeBSD Kristof Provost While I'd been to Scotland before I'd never seen Aberdeen. It's a charming city, and I enthusiastically recommend visiting. I arrived a little while after Benedict, but made it to my hotel easily, and turned up in time to join Benedict and Tom for dinner. Despite being small (or perhaps because of it), the hackathon was remarkably productive. Benedict and I went through the pf documentation in the handbook, so that Benedict could rework and improve it. (Benedict's doing the work, but I'm going to take credit anyway.) Tom and I looked at the GSoC proposals and tried to find potential mentors for two promising proposals. Both of us are candidate mentors as well. We should know soon if our students are awarded slots. Tom also proposed a patch to eliminate RFC 2675 IPv6 Jumbograms. It has my enthusiastic support. I managed to look at a couple of open pf issues: * pfctl's interface_group() function checks if a name is an interface or an interface group. It still thought that interface names always ended with a number, but this assumption has been wrong for several years now. That's fixed in r346370. * The DIOCRSETTFLAGS ioctl() misused copyin() (It held a lock calling it), which could result in panics. * That previous issue was actually discovered by my local instance of syzcaller, which I'd set up to add pf support to it. That support has now been merged, so we may see more issues detected by syzcaller soon. * Also for the DIOCRSETTFLAGS problem I extended the pf tests to check for this issue. * The pf tests will now fail if the pft_set_rules call fails to set the rules. That didn't actually cause issues yet, but it'll make debugging tests slightly easier, and they may catch more problems now. On Saturday Tom took us out to discover some of the pretty bits of Scotland. It turns out there are a lot of them. I can't really do it justice, but Tom has a promising career at the Scottish tourism board when this computers fad blows over. On my way home I passed through Oslo, and took the opportunity to meet with (have lunch with) two of the EuroBSDCon local organisers. EuroBSDCon is filling up fast, make sure to register now to secure your place! __________________________________________________________________ Bring more Security Intelligence to FreeBSD Links Maltrail - distributed Malware detection URL: https://github.com/stamparm/maltrail Wazuh - thread detection and incident response URL: https://wazuh.com/ Contact: Michael Muenz To bring more Security Intelligence we maintain the FreeBSD port of zmaltail. This open source project based on Python can act as a sensor and/or as a central server. It listens in defined ports or protocols and compares IP addresses and domains against static and dynamic feeds, contributed by the community. As you can install this piece of software on multiple firewalls and let them send to a central server, you are able to detect attacks and compromises very fast. Within Q2 we updated the port to the latest version and are constantly in contact with the core developer (also co-author of SQLmap) to bring out new features. The second project we are currently trying to add as a port is Wazuh. Wazuh is a fork of Ossec which is already in the ports tree. Compared to Ossec, Wazuh has some intelligent addition like full ELK-Stack integration with own apps and dashboards. With Wazuh installed on your webserver, or even on your windows desktop you can monitor file integrity or log files for most kind of attacks. Active response features let you e.g. send API calls to your firewalls to dynamically block this offender. As Wazuh offers a complete ELK-Stack you can use it also as a central logging solution for better security insights into your network. This project was sponsored by m.a.x. Informationstechnologie AG. __________________________________________________________________ libvdsk - QCOW2 implementation Links Github - libvdsk repo URL: https://github.com/xcllnt/libvdsk Contact: Sergiu Weisz Contact: Marcel Molenaar Contact: Marcelo Araujo Contact: Mihai Carabas Add support for using QCOW in bhyve using the libvdsk library. Libvdsk was used to substitute the regular disk operations from bhyve with a call to libvdsk which will in turn call the disk-specific handler for the operation. To use this feature one has to install the libvdsk-enabled bhyve version along with libvdsk from the libvdsk repo linked above. New features added: * Extend libvdsk to make it easier to implement new formats * Improve read/write performance and stability * Add support for Copy-On-Write Future tasks: * Integrate libvdsk in bhyve Matthew Grooms __________________________________________________________________ nsysctl 1.0 Links gitlab.com/alfix/nsysctl URL: https://gitlab.com/alfix/nsysctl sysutils/nsysctl port URL: https://www.freshports.org/sysutils/nsysctl/ Tutorial URL: https://alfix.gitlab.io/bsd/2019/02/19/nsysctl-tutorial.html Contact: Alfonso Sabato Siciliano The nsysctl utility is a /sbin/sysctl clone, to get or set the kernel state, supporting libxo and extra options. nsysctl [--libxo=3Dopts [-r tagname]] [-DdFGgIilmNpqTt[V|v[h[b|o|x]]]Wy] [-e sep] [-B ] [-f filename] name[=3Dvalue[,value]] ... nsysctl [--libxo=3Dopts [-r tagname]] [-DdFGgIlmNpqTt[V|v[h[b|o|x]]]Wy] [-e sep] [-B ] -A|a|X You could use nsysctl to explore the sysctl MIB showing the value and the info of an object. The output is explicitly indicated by the options and is printed via libxo in human and machine readable formats, moreover some value is parsed to display it in a structured mode (e.g., vm.phys_free). The support for efi_map_header was added but it is untested, someone could help by trying it via machdep.efi_map. Please refer to the tutorial for a more thorough description. __________________________________________________________________ --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGmBAEBCgCQFiEEbvjBe1hu6u1NeinjJCKD+Vwk/7oFAl1ifcRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZF RjhDMTdCNTg2RUVBRUQ0RDdBMjlFMzI0MjI4M0Y5NUMyNEZGQkESHHRyYXN6QGZy ZWVic2Qub3JnAAoJECQig/lcJP+68WQH+wQOBid2IwHXPyS+vxpl2YevaP+7yjmh ivNM3we+xwB5E8ETufE4ZkQvzDPXbQQ1mQp+SUbmAmoNT53XU35RPDTUH4Ine5+X mwu7arfgOU2vpr5ej0Q4rzzD9ZSYwvz4cqWeU3qqKDXwGh1rIU67hXdu2cq6nWd0 h8pR/k9CGsCt0HqbSSaBr1YSKxONASz0fhUyNykxoKCVcKhpN7ordY3kUawm1M9m fWBmIsnuRAAoBGk+mOb4H3qELTBLxI7sFoKFqNCzw15l9Cyw2nfDvtzeqB8/6CEO YylUTQ0qW/th24ODNNiZpU/6VvajPyC4Wl7Rs9uvRc8H3ebwUrrccQI= =bo0Y -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-stable@freebsd.org Mon Aug 26 09:01:05 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B1B2DD51B3 for ; Mon, 26 Aug 2019 09:01:05 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (enterprise.ximalas.info [IPv6:2001:700:1100:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ximalas.info", Issuer "Hostmaster ximalas.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46H5Zm4R7Kz46td; Mon, 26 Aug 2019 09:01:04 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (Ximalas@localhost [127.0.0.1]) by enterprise.ximalas.info (8.15.2/8.15.2) with ESMTPS id x7Q90qXR053168 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 26 Aug 2019 11:00:52 +0200 (CEST) (envelope-from trond.endrestol@ximalas.info) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ximalas.info; s=default; t=1566810052; bh=zL6wpMb9m4fI2VRr53z0KamUBEE/TYU4UJyF6sJ5OC8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=q46SRGpsVnh68ZSnR0dmcw/BaGo3qROQPHidPPenRlag+U9cKtC2Z4f5KlUGwzVYQ YSBrVSR68WxP79HDSg58ivJtEYeN4fml0vCfbZyeAm2hZZNBLsQv3wEVxzJRB4P8wT X41+pH3e3k9enonvfNICilyJzJiYU+bYiLEdDU2t5w5SvPMv8vvxfQtikk1odN979h T1rk9iLP/NCMaopr/e+334r5XJszlRU0sMUpsn1tAO04iWT/33sth1/iyjn6rGg1JT Oev202AOr+5YqEfD5+TH900916/ZrV8tvx3QGiDyBmPn8tQW/6QKLarShLQABtMykO 4Di9ANez13u5Q== Received: from localhost (trond@localhost) by enterprise.ximalas.info (8.15.2/8.15.2/Submit) with ESMTP id x7Q90q8h053160; Mon, 26 Aug 2019 11:00:52 +0200 (CEST) (envelope-from trond.endrestol@ximalas.info) X-Authentication-Warning: enterprise.ximalas.info: trond owned process doing -bs Date: Mon, 26 Aug 2019 11:00:52 +0200 (CEST) From: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Sender: Trond.Endrestol@ximalas.info To: Konstantin Belousov cc: freebsd-stable@freebsd.org, emaste@freebsd.org Subject: Re: ntpd doesn't like ASLR on stable/12 post-r350672 In-Reply-To: <20190825120342.GN71821@kib.kiev.ua> Message-ID: References: <20190824204114.GG71821@kib.kiev.ua> <20190824222817.GJ71821@kib.kiev.ua> <20190825120342.GN71821@kib.kiev.ua> User-Agent: Alpine 2.21.99999 (BSF 352 2019-06-22) OpenPGP: url=http://ximalas.info/about/tronds-openpgp-public-key MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on enterprise.ximalas.info X-Rspamd-Queue-Id: 46H5Zm4R7Kz46td X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ximalas.info header.s=default header.b=q46SRGps; dmarc=pass (policy=none) header.from=ximalas.info; spf=pass (mx1.freebsd.org: domain of trond.endrestol@ximalas.info designates 2001:700:1100:1::8 as permitted sender) smtp.mailfrom=trond.endrestol@ximalas.info X-Spamd-Result: default: False [-4.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ximalas.info:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_XAW(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ximalas.info:+]; CTYPE_MIXED_BOGUS(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[ximalas.info,none]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:224, ipnet:2001:700::/32, country:NO]; IP_SCORE(-1.71)[ip: (-7.57), ipnet: 2001:700::/32(-0.57), asn: 224(-0.41), country: NO(-0.01)] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 09:01:05 -0000 On Sun, 25 Aug 2019 15:03+0300, Konstantin Belousov wrote: > On Sun, Aug 25, 2019 at 12:40:22AM +0200, Trond Endrestøl wrote: > > On Sun, 25 Aug 2019 01:28+0300, Konstantin Belousov wrote: > > > > > On Sun, Aug 25, 2019 at 12:19:43AM +0200, Trond Endrestøl wrote: > > > > On Sat, 24 Aug 2019 23:41+0300, Konstantin Belousov wrote: > > > > > > I tried changing command="/usr/sbin/${name}" to > > > > > > command="/usr/bin/proccontrol -m aslr -s disable /usr/sbin/${name}" in > > > > > > /etc/rc.d/ntpd, but that didn't go well. > > > > > > > > > > If you set kern.elf64.aslr.stack_gap to zero, does it help ? > > > > > > > > That helped. Thank you again. > > > > > > Can you verify is ntpd sets new rlimit(RLIMIT_STACK) for the main thread, > > > and if yes, what this new limit is ? > > > > (gdb) > > 5265 if (-1 == setrlimit(RLIMIT_STACK, &rl)) { > > (gdb) print rl > > $1 = {rlim_cur = 204800, rlim_max = 536870912} > > So they set the stack limit to 200K, am I right ? I suspect they do > that because ntpd wires entire process address space, so 512M blows off > all limits on wiring. Yes, around line 1001 of contrib/ntp/ntpd/ntpd.c: /* Setup stack size in preparation for locking pages in memory. */ # if defined(HAVE_MLOCKALL) # ifdef HAVE_SETRLIMIT ntp_rlimit(RLIMIT_STACK, DFLT_RLIMIT_STACK * 4096, 4096, "4k"); > I do not have a good idea how to make this behaviour compatible with > the gap. Might be we can change the gap sizing parameter to KBs instead > of percentage, and set the defaults in 64KB range. > > > > aslr.stack_gap is the percentage for the gap on that stack, and since > > > default size of the main stack limit is quite large 512M, even 3% > > > (default gap upper limit) are whole 15M. If the new limit is less than > > > 15M, there is a likely probability that only the gap is left after the > > > rlimit(2) call, leaving no space for the program frames. > > > > > > At least this looks like a nice theory. -- Trond. From owner-freebsd-stable@freebsd.org Mon Aug 26 16:56:30 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D4FADFFD7 for ; Mon, 26 Aug 2019 16:56:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HJ7K6nnqz4dyQ for ; Mon, 26 Aug 2019 16:56:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id E4815DFFD3; Mon, 26 Aug 2019 16:56:29 +0000 (UTC) Delivered-To: stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E3B33DFFD0; Mon, 26 Aug 2019 16:56:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HJ7K0c6Fz4dyM; Mon, 26 Aug 2019 16:56:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f44.google.com with SMTP id z3so39033573iog.0; Mon, 26 Aug 2019 09:56:28 -0700 (PDT) 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:content-transfer-encoding; bh=VanxT31TJS4nyEq2cRp13k5h7f6TmBbfy+MzqPZxmHQ=; b=LzCz8ku6ZU2t0/YROLGh3ykP41AAZecFN5R/OTHNnNLwh3sY4Szv/hRliEBkeF09zr 59+wJmNfTlaK0uu+l3tgg4rLjRXJId9gA9NpNcT+G/Lg337xTpmJVMbJzcZwEZU1OwyT MJYKlCyvFVXOt31urCKbUsV5OldbAIilASk7MoEhl5eHww9cDJ1dbMoGm6uETbz77vCO /iJuGZp1uQH2mvtCE6r0o7ymeZtGsqMEIbw38u10sjV/4s+mWRuQR8lEzKevx6mlIbv3 6pEycXSDbU05zYc2LjeWBjY3FSsLFoFyHMT9Hsra1l3YPVjY3OwLJtgKNZxNlV5FIlHi H16g== X-Gm-Message-State: APjAAAWZ4CvFnck0l7EgvVPDUzJUw3vU2vn1uCEOTtQNhtJcyUB8j8tz kMMj2jTf4DzcJpvFt+xJZaMctTwqnV4zOFI0YSHzN4a5 X-Google-Smtp-Source: APXvYqz5U9xXJSCKmRARMhTKS+fsQpNeZppY2a/xFa0pH0JPJIPxtqJBzECPNQnYAMfFqGksZS0GZsJuwglHlQtElG0= X-Received: by 2002:a6b:ea16:: with SMTP id m22mr24349319ioc.115.1566838586619; Mon, 26 Aug 2019 09:56:26 -0700 (PDT) MIME-Version: 1.0 References: <20190825122332.GA16293@v2> In-Reply-To: <20190825122332.GA16293@v2> From: Ed Maste Date: Mon, 26 Aug 2019 12:56:07 -0400 Message-ID: Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2019 To: hackers@freebsd.org, current , stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 46HJ7K0c6Fz4dyM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.44 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-5.02 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.03)[ip: (-4.41), ipnet: 209.85.128.0/17(-3.35), asn: 15169(-2.33), country: US(-0.05)]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; RCVD_IN_DNSWL_NONE(0.00)[44.166.85.209.list.dnswl.org : 127.0.5.0]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 16:56:30 -0000 On Sun, 25 Aug 2019 at 08:24, Edward Tomasz Napiera=C5=82a wrote: > > FreeBSD Project Quarterly Status Report - 2nd Quarter 2019 Due to an oversight the FreeBSD Foundation's quartery status entry was omitted from this report. Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: We held our annual board meeting in Ottawa on May 14. Board Director and Officer elections take place each year at this meeting. Justin Gibbs was elected as the new President of the Board of Directors. The new FreeBSD Foundation Board of Directors includes President and Founder Justin T. Gibbs, Vice President Benedict Reuschling, Secretary Philip Paeps, Treasurer Marshall Kirk McKusick, and Directors Hiroki Sato, George Neville-Neil and Robert N. M. Watson. You can read more about the elections at: . After the elections, our management team gave updates to the board on their respective areas. We then discussed the key areas of the Project that need help, and where we can step in to fill those holes. We reviewed and updated our 12 month goals, and identified projects we should support. We then discussed conferences we are likely to attend, and went over the latest on our fundraising efforts. We followed that up with a discussion on how to get more users to contribute back to the Project. While discussing how to increase the number of users and contributors, we talked about methods for making for more training material available. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. In Q2, Ed Maste and Deb Goodkin met with a few commercial users in Germany. It=E2=80=99s not only beneficial for the above, but it also helps us understand some of the applications where FreeBSD is used. Because BSDCan brings in a high number of commercial users, we have an excellent opportunity to have similar discussions about their needs during the four-day FreeBSD Summit and BSDCan. Fundraising Efforts Our work is 100% funded by your donations. We are grateful for the generous donations from Intel, NetApp, VMware and Stormshield last quarter. We are working hard to get more commercial users to give back to help us continue our work supporting FreeBSD. More importantly, we=E2=80=99d like to thank our individual donors, for making $10-$1,000 donations last quarter, for a total of $16,000! Please consider making a donation to help us continue and increase our support for FreeBSD: https://www.FreeBSDfoundation.org/donate/. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements The Foundation improves the FreeBSD operating system by employing our technical staff to maintain and improve critical kernel subsystems, add features and functionality, and fix problems. The Foundation also provides grants to fund individual projects. There were 243 commits to the FreeBSD base system repository sponsored by the Foundation during the quarter. These include improvements to the tmpfs in-memory, MSDOS, and UFS filesystems, device driver and hardware compatibility fixes, virtual memory (VM), tool chain, documentation, and testing and continuous integration improvements. We fixed a number of race conditions and security issues found by Syzkaller, Google=E2=80=99s code-coverage-guided system call fuzzer. Alan Somers=E2=80=99 work on updating FreeBSD=E2=80=99s support for FUSE (u= serspace filesystems) continued during the quarter; the full details are elsewhere in this quarterly report. At this point most of the work has been committed to the project branch but some bug fixes and improvements have been committed directly to the FreeBSD development branch. Edward Napierala=E2=80=99s Linuxulator project continued through the quarte= r, resulting in a number of improvements to the Linuxulator and linux-specific functionality such as linsysfs. This work is part of the path to supporting the Linux strace debugging tool in order to facilitate debugging failures of other Linux binaries under the Linuxulator. Mateusz Guzik continued with scalability and performance improvements during the quarter, and Bjoern Zeeb integrated the SDIO stack (with details elsewhere in the quarterly report). Progress was made on the online RAID-Z expansion project over the quarter. Matt Ahrens posted an alpha preview of the feature for further experimentation and review, and the FreeBSD Foundation will make an alpha release image available for testing in the near future. Foundation staff contributed to nine FreeBSD security advisories and errata updates over the quarter, including CPU vulnerability workarounds. Related work included improving Intel microcode update loading. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving our automated testing, continuous integration, and overall quality assurance efforts. During the second quarter of 2019, Foundation staff continued to improve the project's CI infrastructure, worked with contributors to fix the failing build and test cases, and worked with other teams in the Project for their testing needs. We hosted a CI-focused working group at BSDcan and continue to publish the CI weekly report at freebsd-testing@ mailing list. See the FreeBSD CI section of this report for more information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. Check out some of the advocacy and education work we did last quarter: - Represented FreeBSD at LinuxFest Northwest In Bellingham, Washington - Sponsored and helped organize the FreeBSD Developers Summit at BSDCan, in Ottawa, Canada - Sponsored and attended BSDCan 2019 - Set up registration and attended the Vienna FreeBSD Security Hackathon in Vienna, Austria - Represented FreeBSD at HKOSCON - Attended the Berlin FreeBSD Developers Summit - Presented at 2019 Comcast Labs Connect Open Source Conference Sponsored, presented and represented FreeBSD at RootConf 2019 in Bangalore, India - Committed to attend OSCON, and All Things Open - Committed to sponsor and help organize a Bay Area Developers Summit - Provided FreeBSD advocacy material - Provided travel grants to FreeBSD contributors to attend many of the above events We continued producing FreeBSD advocacy material to help people promote FreeBSD around the world. Read more about our conference adventures in the conference recaps and trip reports in our monthly newsletters: https://www.freebsdfoundation.org/news-and-events/newsletter/ We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https://www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https://www.FreeBSDfoundation.org/news-and-events/. We have continued our work with a new website developer to help us improve our website. Work has begun to make it easier for community members to find information more easily and to make the site more efficient. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to http://www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you! From owner-freebsd-stable@freebsd.org Mon Aug 26 20:59:14 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 278E2E519B for ; Mon, 26 Aug 2019 20:59:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca (unknown [IPv6:2607:f3e0:0:3::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HPWN6hYbz3QRv; Mon, 26 Aug 2019 20:59:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:ccaa:bb1d:a627:21f9] ([IPv6:2607:f3e0:0:4:ccaa:bb1d:a627:21f9]) by pyroxene.sentex.ca (8.15.2/8.15.2) with ESMTPS id x7QKx9tR052041 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Aug 2019 16:59:10 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: svn commit: r351246 - in stable: 11/sys/opencrypto 12/sys/opencrypto To: John Baldwin , freebsd-stable@freebsd.org References: <201908200130.x7K1UajV079446@repo.freebsd.org> <3101bd14-316a-baaa-6269-297903c45f23@FreeBSD.org> From: mike tancsa Message-ID: <39c6d016-fecb-306e-32f2-7fdabad32122@sentex.net> Date: Mon, 26 Aug 2019 16:59:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 46HPWN6hYbz3QRv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::18 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-1.48 / 15.00]; ARC_NA(0.00)[]; RDNS_NONE(1.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.72)[ipnet: 2607:f3e0::/32(-4.94), asn: 11647(-3.56), country: CA(-0.09)]; NEURAL_HAM_SHORT(-0.97)[-0.965,0]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 20:59:14 -0000 On 8/22/2019 6:51 PM, John Baldwin wrote: > On 8/21/19 5:47 PM, Mike Tancsa wrote: >> On 8/21/2019 6:38 PM, John Baldwin wrote: >>> On 8/21/19 9:08 AM, mike tancsa wrote: >>>> On 8/21/2019 12:00 PM, John Baldwin wrote: >>>>> dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count()' >>>> Thanks, I am not familiar with dtrace at all. This command gives a >>>> syntax error >>>> >>>> 0(cage)# dtrace -n 'fbt::_gone_in:entry { >>>> @counts[curthread->td_proc->p_comm] = count()' >>>> dtrace: invalid probe specifier fbt::_gone_in:entry { >>>> @counts[curthread->td_proc->p_comm] = count(): syntax error near end of >>>> input >>>> 1(cage)# >>> Oops, I forgot the closing }. First, do "dtrace -l | grep _gone_in" to make >>> sure dtrace is loaded. You should see something like this: >>> >>> # dtrace -l | grep _gone_in >>> 87003 fbt kernel _gone_in entry >>> 87004 fbt kernel _gone_in return >>> 98682 fbt kernel _gone_in_dev entry >>> 98683 fbt kernel _gone_in_dev return >>> >>> Then this should work: >>> >>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count() }' >>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >>> >> Thanks! >> >> #  dtrace -l | grep _gone_in >> 15632        fbt            kernel                          _gone_in entry >> 22693        fbt            kernel                      _gone_in_dev entry >> >> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = >> count() }' >> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >> >> However, It doesnt show anything after that even as I get the >> deprecation messages in dmesg > Can you hit Ctrl-C after seeing some of the messages? This trace won't > show any results until you exit dtrace. Hi,     I am still having problems tracking it down via dtrace, but I am able to create the problem on demand on sshd.  Whats odd is that if I restrict the list of ciphers in sshd and even specify something like aes-128 on the client, I still get warnings on the server. e.g from a client, % ssh -c aes128-cbc console1 uptime  4:53PM  up  1:02, 3 users, load averages: 0.04, 0.08, 0.08 The server shows Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): ARC4 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): 3DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): Blowfish cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): CAST128 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): ARC4 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): 3DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): Blowfish cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): CAST128 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): ARC4 cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): 3DES cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): Blowfish cipher via /dev/crypto Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in FreeBSD 13): CAST128 cipher via /dev/crypto Despite having Ciphers        aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com in /etc/ssh/sshd_config Doing ssh -v from the client doesnt show any of the warning ciphers being used or proposed at all. Just wondering what the value of the warnings are if there is no way to really deal with them or even track down where the issues are ?  Rather than filling up the logs, would it be possible to have kern.cryptodev_warn_interval=0 to disable ?     ---Mike From owner-freebsd-stable@freebsd.org Tue Aug 27 00:25:30 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2AD19C12F9 for ; Tue, 27 Aug 2019 00:25:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HV5Q0JHsz4582; Tue, 27 Aug 2019 00:25:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 8642D1F85F; Tue, 27 Aug 2019 00:25:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r351246 - in stable: 11/sys/opencrypto 12/sys/opencrypto To: mike tancsa , freebsd-stable@freebsd.org References: <201908200130.x7K1UajV079446@repo.freebsd.org> <3101bd14-316a-baaa-6269-297903c45f23@FreeBSD.org> <39c6d016-fecb-306e-32f2-7fdabad32122@sentex.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <75b07433-91a2-0dbd-0dc2-0880e20df659@FreeBSD.org> Date: Mon, 26 Aug 2019 17:25:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <39c6d016-fecb-306e-32f2-7fdabad32122@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 00:25:30 -0000 On 8/26/19 1:59 PM, mike tancsa wrote: > On 8/22/2019 6:51 PM, John Baldwin wrote: >> On 8/21/19 5:47 PM, Mike Tancsa wrote: >>> On 8/21/2019 6:38 PM, John Baldwin wrote: >>>> On 8/21/19 9:08 AM, mike tancsa wrote: >>>>> On 8/21/2019 12:00 PM, John Baldwin wrote: >>>>>> dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count()' >>>>> Thanks, I am not familiar with dtrace at all. This command gives a >>>>> syntax error >>>>> >>>>> 0(cage)# dtrace -n 'fbt::_gone_in:entry { >>>>> @counts[curthread->td_proc->p_comm] = count()' >>>>> dtrace: invalid probe specifier fbt::_gone_in:entry { >>>>> @counts[curthread->td_proc->p_comm] = count(): syntax error near end of >>>>> input >>>>> 1(cage)# >>>> Oops, I forgot the closing }. First, do "dtrace -l | grep _gone_in" to make >>>> sure dtrace is loaded. You should see something like this: >>>> >>>> # dtrace -l | grep _gone_in >>>> 87003 fbt kernel _gone_in entry >>>> 87004 fbt kernel _gone_in return >>>> 98682 fbt kernel _gone_in_dev entry >>>> 98683 fbt kernel _gone_in_dev return >>>> >>>> Then this should work: >>>> >>>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count() }' >>>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >>>> >>> Thanks! >>> >>> #  dtrace -l | grep _gone_in >>> 15632        fbt            kernel                          _gone_in entry >>> 22693        fbt            kernel                      _gone_in_dev entry >>> >>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = >>> count() }' >>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >>> >>> However, It doesnt show anything after that even as I get the >>> deprecation messages in dmesg >> Can you hit Ctrl-C after seeing some of the messages? This trace won't >> show any results until you exit dtrace. > > Hi, > >     I am still having problems tracking it down via dtrace, but I am > able to create the problem on demand on sshd.  Whats odd is that if I > restrict the list of ciphers in sshd and even specify something like > aes-128 on the client, I still get warnings on the server. > > e.g from a client, > > % ssh -c aes128-cbc console1 uptime >  4:53PM  up  1:02, 3 users, load averages: 0.04, 0.08, 0.08 > > The server shows Ok, I was able to reproduce this on an 11.x VM. It appears to only be something that the crypto engine in OpenSSL 1.0.x does (1.1.1 used in 12.0 and later has a rewritten /dev/crypto engine). I'll see if I can find a way to tone down the warning. Maybe if sshd is only creating sessions and not using them I can restrict it to warning the first time a session tries to perform an operation using a deprecated algorithm. (There are separate ioctls for creating a sessions vs doing actual crypto ops and the warning is in the session creation currently.) > kern.cryptodev_warn_interval=0 I'll try to get this tracked down this week, but this should be a suitable workaround for now. -- John Baldwin From owner-freebsd-stable@freebsd.org Tue Aug 27 05:45:15 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CED1DCADE5 for ; Tue, 27 Aug 2019 05:45:15 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 46HdBL1vgTz4QdS for ; Tue, 27 Aug 2019 05:45:13 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp14-2-85-52.adl-apt-pir-bras31.tpg.internode.on.net (HELO midget.dons.net.au) ([14.2.85.52]) by ipmail06.adl6.internode.on.net with ESMTP; 27 Aug 2019 14:01:11 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x7R4V3UA020071 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 27 Aug 2019 14:01:04 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x7R4G2BH009054 for ; Tue, 27 Aug 2019 13:46:02 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [203.31.81.177] ([203.31.81.177]) by ppp14-2-85-52.adl-apt-pir-bras31.tpg.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id x7R4Fv06009052; Tue, 27 Aug 2019 13:46:02 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: FreeBSD 12 Xorg vs X11SSH-F / AST From: "O'Connor, Daniel" In-Reply-To: <7AC86383-2C8E-427D-88BD-48B91FE9ECBC@dons.net.au> Date: Tue, 27 Aug 2019 13:45:56 +0930 Cc: freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: <2EB91070-54F2-4046-BB5A-86FBE41FFBE1@dons.net.au> References: <2EDB82D8-9EC5-4988-AD1C-21305E712E46@dons.net.au> <4dbdbf1e-b823-20e4-8516-55bb9fdfab88@nomadlogic.org> <7AC86383-2C8E-427D-88BD-48B91FE9ECBC@dons.net.au> To: Pete Wright X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Score: 1.5 (*) No, score=1.5 required=5.0 tests=HELO_MISC_IP, RDNS_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 46HdBL1vgTz4QdS X-Spamd-Bar: +++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of darius@dons.net.au has no SPF policy when checking 150.101.137.145) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [7.35 / 15.00]; ARC_NA(0.00)[]; GREYLIST(0.00)[pass,body]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_SPAM_SHORT(0.95)[0.948,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; HAS_XAW(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[dons.net.au]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996,0]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[0.998,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(3.01)[ip: (9.85), ipnet: 150.101.0.0/16(3.58), asn: 4739(1.62), country: AU(0.01)]; RCVD_IN_DNSWL_LOW(-0.10)[145.137.101.150.list.dnswl.org : 127.0.5.1] X-Spam: Yes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 05:45:15 -0000 > On 24 Aug 2019, at 10:07, O'Connor, Daniel wrote: >> On 24 Aug 2019, at 02:23, Pete Wright wrote: >> On 8/23/19 7:30 AM, O'Connor, Daniel wrote: >>> Hi, >>> We have a Supermicro X11SSH-F motherboard which has a ASPEED AST2400 = video chipset with FreeBSD 12.0-RELEASE r341666 GENERIC amd64 on it. >>> Unfortunately I am unable to get X working with it properly, I have = the xf86-video-ast package (version 1.1.5_2) installed, however X seems = to hang when started. >>=20 >> would you be able to share the Xorg.log from when it hangs? >=20 > Ah yes of course :) >=20 > I also see that xinit is stuck in 'pause' then goes to 'select': > xauth: file /root/.serverauth.4556 does not exist I tried the binary driver from = http://upload.aspeedtech.com/BIOS/v10902_linux_freebsd_solaris.zip (the = xorg78_5 one) and while it works I would claim it's any faster = (certainly not smooth). I built the source version from = http://upload.aspeedtech.com/BIOS/v11001_linux.zip which was a slightly = newer version by replacing the source in the usual port, but it behaved = the same as the binary version. I also had an idea to try a last ditch hail Mary and set write combining = with memcontrol like the good old days of PCI VESA cards but.. [chumphon 4:05] ~> dmesg|grep vgapci vgapci0: port 0xc000-0xc07f mem = 0xde000000-0xdeffffff,0xdf000000-0xdf01ffff irq 18 at device 0.0 on pci4 vgapci0: Boot video device [chumphon 4:06] ~> sudo memcontrol set -b 0xde000000 -l 0x1000000 -o vga = write-through write-combine memcontrol: can't set range: Invalid argument Although I could set uncacheable (no difference). Next stop will be obscure BIOS settings I suppose. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-stable@freebsd.org Tue Aug 27 09:01:20 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 05C15D0965 for ; Tue, 27 Aug 2019 09:01:20 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id 46HjXY2JYVz4d98 for ; Tue, 27 Aug 2019 09:01:15 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp14-2-85-52.adl-apt-pir-bras31.tpg.internode.on.net (HELO midget.dons.net.au) ([14.2.85.52]) by ipmail03.adl6.internode.on.net with ESMTP; 27 Aug 2019 18:31:10 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x7R913vf014923 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 27 Aug 2019 18:31:03 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x7R8eXBA000335 for ; Tue, 27 Aug 2019 18:10:33 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [172.20.10.4] ([120.20.39.122]) by ppp14-2-85-52.adl-apt-pir-bras31.tpg.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id x7R8eRI9098341; Tue, 27 Aug 2019 18:10:33 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: FreeBSD 12 Xorg vs X11SSH-F / AST From: "O'Connor, Daniel" In-Reply-To: <2EB91070-54F2-4046-BB5A-86FBE41FFBE1@dons.net.au> Date: Tue, 27 Aug 2019 18:10:21 +0930 Cc: freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: <2B354C0E-8F94-412B-B6B5-DCF681DAE5C8@dons.net.au> References: <2EDB82D8-9EC5-4988-AD1C-21305E712E46@dons.net.au> <4dbdbf1e-b823-20e4-8516-55bb9fdfab88@nomadlogic.org> <7AC86383-2C8E-427D-88BD-48B91FE9ECBC@dons.net.au> <2EB91070-54F2-4046-BB5A-86FBE41FFBE1@dons.net.au> To: Pete Wright X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Score: 5.1 (*****) Yes, score=5.1 required=5.0 tests=HELO_MISC_IP, RCVD_IN_PBL, RDNS_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Status: yes X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 46HjXY2JYVz4d98 X-Spamd-Bar: ++++++++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of darius@dons.net.au has no SPF policy when checking 150.101.137.143) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [12.21 / 15.00]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[122.39.20.120.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[143.137.101.150.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; SPAM_FLAG(5.00)[]; IP_SCORE(2.81)[ip: (8.86), ipnet: 150.101.0.0/16(3.58), asn: 4739(1.62), country: AU(0.01)]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.997,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; DMARC_NA(0.00)[dons.net.au]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; R_SPF_NA(0.00)[]; GREYLIST(0.00)[pass,meta] X-Spam: Yes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 09:01:20 -0000 > On 27 Aug 2019, at 13:45, O'Connor, Daniel wrote: >=20 > Although I could set uncacheable (no difference). >=20 > Next stop will be obscure BIOS settings I suppose. I couldn't find anything useful there. I realised that my scfb failure was because I am booting BIOS rather = than UEFI but I will have to reinstall before I can fix that. There was a thread about a performance regression in Linux = (https://ubuntuforums.org/showthread.php?t=3D2399941) but that applies = to KMS.. I checked the drm-kmod port but there is no ASPEED driver = there. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-stable@freebsd.org Tue Aug 27 21:30:24 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 375F8C84BE for ; Tue, 27 Aug 2019 21:30:24 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46J28w0hY9z4Mx9; Tue, 27 Aug 2019 21:30:24 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 99D6E9358; Tue, 27 Aug 2019 21:30:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r351246 - in stable: 11/sys/opencrypto 12/sys/opencrypto From: John Baldwin To: mike tancsa , freebsd-stable@freebsd.org References: <201908200130.x7K1UajV079446@repo.freebsd.org> <3101bd14-316a-baaa-6269-297903c45f23@FreeBSD.org> <39c6d016-fecb-306e-32f2-7fdabad32122@sentex.net> <75b07433-91a2-0dbd-0dc2-0880e20df659@FreeBSD.org> Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <2a11d260-7d74-a819-a4f3-31ba00f46789@FreeBSD.org> Date: Tue, 27 Aug 2019 14:30:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <75b07433-91a2-0dbd-0dc2-0880e20df659@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:30:24 -0000 On 8/26/19 5:25 PM, John Baldwin wrote: > On 8/26/19 1:59 PM, mike tancsa wrote: >> On 8/22/2019 6:51 PM, John Baldwin wrote: >>> On 8/21/19 5:47 PM, Mike Tancsa wrote: >>>> On 8/21/2019 6:38 PM, John Baldwin wrote: >>>>> On 8/21/19 9:08 AM, mike tancsa wrote: >>>>>> On 8/21/2019 12:00 PM, John Baldwin wrote: >>>>>>> dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count()' >>>>>> Thanks, I am not familiar with dtrace at all. This command gives a >>>>>> syntax error >>>>>> >>>>>> 0(cage)# dtrace -n 'fbt::_gone_in:entry { >>>>>> @counts[curthread->td_proc->p_comm] = count()' >>>>>> dtrace: invalid probe specifier fbt::_gone_in:entry { >>>>>> @counts[curthread->td_proc->p_comm] = count(): syntax error near end of >>>>>> input >>>>>> 1(cage)# >>>>> Oops, I forgot the closing }. First, do "dtrace -l | grep _gone_in" to make >>>>> sure dtrace is loaded. You should see something like this: >>>>> >>>>> # dtrace -l | grep _gone_in >>>>> 87003 fbt kernel _gone_in entry >>>>> 87004 fbt kernel _gone_in return >>>>> 98682 fbt kernel _gone_in_dev entry >>>>> 98683 fbt kernel _gone_in_dev return >>>>> >>>>> Then this should work: >>>>> >>>>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = count() }' >>>>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >>>>> >>>> Thanks! >>>> >>>> #  dtrace -l | grep _gone_in >>>> 15632        fbt            kernel                          _gone_in entry >>>> 22693        fbt            kernel                      _gone_in_dev entry >>>> >>>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] = >>>> count() }' >>>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe >>>> >>>> However, It doesnt show anything after that even as I get the >>>> deprecation messages in dmesg >>> Can you hit Ctrl-C after seeing some of the messages? This trace won't >>> show any results until you exit dtrace. >> >> Hi, >> >>     I am still having problems tracking it down via dtrace, but I am >> able to create the problem on demand on sshd.  Whats odd is that if I >> restrict the list of ciphers in sshd and even specify something like >> aes-128 on the client, I still get warnings on the server. >> >> e.g from a client, >> >> % ssh -c aes128-cbc console1 uptime >>  4:53PM  up  1:02, 3 users, load averages: 0.04, 0.08, 0.08 >> >> The server shows > > Ok, I was able to reproduce this on an 11.x VM. It appears to only > be something that the crypto engine in OpenSSL 1.0.x does (1.1.1 used > in 12.0 and later has a rewritten /dev/crypto engine). > > I'll see if I can find a way to tone down the warning. Maybe if > sshd is only creating sessions and not using them I can restrict > it to warning the first time a session tries to perform an operation > using a deprecated algorithm. (There are separate ioctls for > creating a sessions vs doing actual crypto ops and the warning is > in the session creation currently.) I've committed a fix to head and will MFC it in a few days. Thanks for tracking this down! -- John Baldwin From owner-freebsd-stable@freebsd.org Wed Aug 28 04:11:55 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3328DD0068; Wed, 28 Aug 2019 04:11:55 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46JC4C0W15z3CZs; Wed, 28 Aug 2019 04:11:55 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 006F419C63; Wed, 28 Aug 2019 04:11:54 +0000 (UTC) Date: Wed, 28 Aug 2019 04:11:54 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2019-08-25 Message-ID: <20190828041154.GA27858@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 04:11:55 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-08-25 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-08-19 to 2019-08-25. During this period, we have: * 2262 builds (83% (-10.3) passed, 17% (+10.3) failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 403 test runs (45.2% (-18.1) passed, 48.8% (+14.1) unstable, 6% (+4) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 38 doc builds (100% (0) passed) Test case status (on 2019-08-25 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | ---------- | ---------- | ------- | -------- | | head/amd64 | 7533 (+22) | 7463 (+17) | 0 (-2) | 70 (+7) | | head/i386 | 7531 (+22) | 7455 (+18) | 0 (-2) | 74 (+4) | | 12-STABLE/amd64 | 7392 (0) | 7345 (+4) | 0 (-2) | 47 (-2) | | 12-STABLE/i386 | 7390 (0) | 7336 (+4) | 0 (-2) | 54 (-2) | | 11-STABLE/amd64 | 6845 (0) | 6801 (+7) | 0 (0) | 44 (-7) | | 11-STABLE/i386 | 6843 (0) | 6763 (+7) | 34 (0) | 46 (-7) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/s/HkcTCgnVB and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## News * [FCP 20190401-ci_policy: CI policy ](https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md) is in "feedback" state, please check and provide comments. * Per imp@ suggested [timeline of gcc 4.2.1 removal](https://lists.freebsd.org/pipermail/freebsd-arch/2019-August/019674.html): * -Werror has been turned off for gcc 4.2.1 in [r351429](https://svnweb.freebsd.org/changeset/base/351429) and [r351430](https://svnweb.freebsd.org/changeset/base/351430) * power*-build has been fixed in [r351485](https://svnweb.freebsd.org/changeset/base/351485) * amd64-gcc build still need fix, patch is being discussed in https://reviews.freebsd.org/D21418 * Some pf tests failing on i386 which may be related to bpf, need more help: * https://lists.freebsd.org/pipermail/freebsd-testing/2019-June/001933.html * https://lists.freebsd.org/pipermail/freebsd-testing/2019-June/001934.html ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/12237/ * https://ci.freebsd.org/job/FreeBSD-head-i386-test/6383/ * sys.acl.00.main * sys.acl.02.main Fixed by update package to perl5.30 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.icmp.cve_2019_5598 Due to [r351212](https://svnweb.freebsd.org/changeset/base/351212) changed options of ping6(8), fixed in [r351391](https://svnweb.freebsd.org/changeset/base/351391) ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * usr.bin.procstat.procstat_test.command_loogle.com/ine_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.netpfil.pf.forward.v4 (i386 only) * sys.netpfil.pf.forward.v6 (i386 only) * sys.netpfil.pf.set_tos.v4 (i386 only) https://bugs.freebsd.org/239380 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 ## Issues ### New * Bug 240085 - Failing test: sys.netpfil.common.forward.pf_v4 on i386 * Bug 240086 - Failing test: sys.netpfil.common.tos.pf_tos on i386 ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s * https://bugs.freebsd.org/238828 Possible build race: lib/libsysdecode/tables.h:948: error: 'IPV6_MIN_MEMBERSHIPS' undeclared A fix is committed: https://svnweb.freebsd.org/changeset/base/351151 ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/237657 sys.kern.pdeathsig.signal_delivered_ptrace timing out periodically on i386 Fixed are committed: https://svnweb.freebsd.org/changeset/base/351210 https://svnweb.freebsd.org/changeset/base/351211 * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239380 sys.netpfil.pf.forward.{v4,v6} and sys.netpfil.pf.set_tos.v4 fail on i386 * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-stable@freebsd.org Wed Aug 28 14:36:03 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D8734DE688 for ; Wed, 28 Aug 2019 14:36:03 +0000 (UTC) (envelope-from dianne.beasley@newpromediadatabasesol.com) Received: from n1nlsmtp03.shr.prod.ams1.secureserver.net (n1nlsmtp03.shr.prod.ams1.secureserver.net [188.121.43.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay-hosting.secureserver.net", Issuer "Starfield Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46JSwL64tXz4Hrq for ; Wed, 28 Aug 2019 14:36:01 +0000 (UTC) (envelope-from dianne.beasley@newpromediadatabasesol.com) Received: from n3plcpnl0052.prod.ams3.secureserver.net ([160.153.153.11]) by : HOSTING RELAY : with ESMTP id 2z2IiCd1DOZQF2z2IiNyLL; Wed, 28 Aug 2019 07:34:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=newpromediadatabasesol.com; s=default; h=Content-Type:MIME-Version: Message-ID:Date:Subject:To:From:Reply-To:Sender:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oi9rQVGd4nxQa2VW2IAZiYEZuI2B4UFXfo/2t4QKQck=; b=CN6dfxiPWr10FBs7JzzbPSaQf SjK5jSdQDCriBJ4L0oPJOVl+QAFBpqcDH3mwJ5SjZXLZdTwkhMf3tAfjRaKrbpjMWlKEXVkKAVIyJ 2Orrhuy/9IN05APeQQ2cyrEsXE/OHhIiUQCim/nUIP+s2Yo5X/Uudsbgfc7ejhoM4U+FhQeUbF/pF 3jjuRk1X24jFxFlaHv/+7dbGnFyfO83QbJcNIxdYmhT+XwIwWGeRRMhGypQ5WTSAr5CWf4Gdz7uxZ N8FFtgw60n2Sd8n4ZiG3rJqRYl7iRc+G8eMREo+DsVN45SmXEvIRC5PJKcTjXSD+Z1gxBEpyeFeFj lglC2AsZA==; Received: from [89.187.168.72] (port=63899 helo=WS52) by n3plcpnl0052.prod.ams3.secureserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i2z2I-00Eyau-Bn for freebsd-stable@freebsd.org; Wed, 28 Aug 2019 07:34:58 -0700 Reply-To: From: "Dianne Beasley" To: Subject: Red Hat Potential Business Contacts Date: Wed, 28 Aug 2019 07:34:40 -0700 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdVdrbW6JyUmSx9mT92CRjxRHm/IVQ== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - n3plcpnl0052.prod.ams3.secureserver.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newpromediadatabasesol.com X-Get-Message-Sender-Via: n3plcpnl0052.prod.ams3.secureserver.net: authenticated_id: dianne.beasley@newpromediadatabasesol.com X-Authenticated-Sender: n3plcpnl0052.prod.ams3.secureserver.net: dianne.beasley@newpromediadatabasesol.com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfCnHx84UU28E/fZQU5aRp7j/hrxpklilha+bI1L9HZKKpx1SXph6mzPpvqmK8xhS5kIJmfkDhS85+94H1anm67whXMAJplrxH/dO+XFAvt6YgGHZtm/0 TNaBh2ABx3l/wEC5MVlB73QeeHtl1ZOvno+xKIX/enq6B+rmFWK/p6Dx+4WmFt+AtnYcC5ltnwDHqhF03M8WvTDUC8yoglaA7si1TI2Shc5YI6/xm4F6bwSV IpXSCa2VMtZxxUcaWtSHJA== X-Rspamd-Queue-Id: 46JSwL64tXz4Hrq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=newpromediadatabasesol.com header.s=default header.b=CN6dfxiP; dmarc=none; spf=none (mx1.freebsd.org: domain of dianne.beasley@newpromediadatabasesol.com has no SPF policy when checking 188.121.43.193) smtp.mailfrom=dianne.beasley@newpromediadatabasesol.com X-Spamd-Result: default: False [-2.72 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[dianne.beasley@newpromediadatabasesol.com]; HAS_X_SOURCE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[newpromediadatabasesol.com:~]; NEURAL_HAM_SHORT(-0.75)[-0.748,0]; HAS_X_ANTIABUSE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.10)[ip: (0.17), ipnet: 188.121.40.0/22(0.19), asn: 26496(0.18), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:26496, ipnet:188.121.40.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[dianne.beasley@newpromediadatabasesol.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.979,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[newpromediadatabasesol.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[193.43.121.188.list.dnswl.org : 127.0.5.0]; HAS_X_GMSV(0.00)[dianne.beasley@newpromediadatabasesol.com]; R_DKIM_PERMFAIL(0.00)[newpromediadatabasesol.com:s=default]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 14:36:03 -0000 Hi, I wanted to check if you'd be interested in acquiring Red Hat Users List for your sales and marketing initiatives. We also have related technology users like: Fedora, CentOS, Debian, Linux, VMware, MemberClicks and many more... Let me know if you are interested and I will get back to you with the Counts and Pricing for your review. Thanks and I look forward to hearing from you soon! Regards, Dianne Beasley Sr. Marketing Manager If you are not interested in receiving our mails reply in subject line leave out or remove. From owner-freebsd-stable@freebsd.org Wed Aug 28 21:41:04 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 94340E70A7 for ; Wed, 28 Aug 2019 21:41:04 +0000 (UTC) (envelope-from agosto2019@inter-pymes.com) Received: from babyboom.inter-pymes.com (babyboom.inter-pymes.com [178.60.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 46JfLl3Znxz3GgZ for ; Wed, 28 Aug 2019 21:41:03 +0000 (UTC) (envelope-from agosto2019@inter-pymes.com) Received: by babyboom.inter-pymes.com (Postfix, from userid 0) id B4A722414A3; Wed, 28 Aug 2019 23:41:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inter-pymes.com; s=default; t=1567028463; bh=gnR/oDUCniPZ6/ZJN5NNrYDp5yI9qhXwhuFzJgCdryw=; h=Date:From:To:Subject:Reply-To; b=h6K4+pBnVg/ctDNQyCpYE7YOIwyUvy2nIMDV0+ndn3SI1RhAuICS0j1yajhaABXbz PdxZ6AdFe4WRr7Uf0nXJL/khX4fRFc5neWOpNtdvOWM4y9mr+jB76mcanDPrtaAgiO wekQYeGBXwMS+tZh6ZRBqIKfpA6j9eOUmH9HgoF4= User-Agent: CodeIgniter Date: Wed, 28 Aug 2019 23:41:02 +0200 From: "Carina" To: freebsd-stable@freebsd.org Subject: =?utf-8?Q?L=c3=adneas_Enisa_2019?= Reply-To: "agosto2019@inter-pymes.com" X-Sender: agosto2019@inter-pymes.com X-Mailer: CodeIgniter X-Priority: 3 (Normal) Message-ID: <5d66f4ef97144@inter-pymes.com> Mime-Version: 1.0 X-Rspamd-Queue-Id: 46JfLl3Znxz3GgZ X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=inter-pymes.com header.s=default header.b=h6K4+pBn; dmarc=none; spf=pass (mx1.freebsd.org: domain of agosto2019@inter-pymes.com designates 178.60.30.106 as permitted sender) smtp.mailfrom=agosto2019@inter-pymes.com X-Spamd-Result: default: False [6.48 / 15.00]; HAS_REPLYTO(0.00)[agosto2019@inter-pymes.com]; XM_UA_NO_VERSION(0.01)[]; R_SPF_ALLOW(-0.20)[+ip4:178.60.30.0/24:c]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; URI_COUNT_ODD(1.00)[9]; DKIM_TRACE(0.00)[inter-pymes.com:+]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(0.70)[ipnet: 178.60.0.0/18(1.05), asn: 12334(2.42), country: ES(0.04)]; ASN(0.00)[asn:12334, ipnet:178.60.0.0/18, country:ES]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[inter-pymes.com:s=default]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.72)[0.723,0]; R_BAD_CTE_7BIT(1.05)[quoted-printable,utf8]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[inter-pymes.com]; HTML_SHORT_LINK_IMG_2(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[0.999,0]; NEURAL_SPAM_LONG(1.00)[1.000,0] X-Spam: Yes Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 21:41:04 -0000 Líneas Enisa para pymes 1. Enisa crecimiento -Entre 25mil y 1,5M de euros. -Vencimiento máximo a 9 años con un máximo de 7 de carencia del principal. -Para pymes con proyectos de consolidación, crecimiento e internacionalización. Quiero saber más 2. Enisa emprendedores -Entre 25mil y 300mil euros. -Vencimiento máximo de 7 años con un máximo de 5 años de carencia del principal. -Para empresas de menos de 2 años. Quiero saber más 3. Enisa jóvenes emprendedores -Entre 25mil y 75mil euros. -Vencimiento máximo de 7 años con 5 de carencia del principal. -Para empresas de menos de 2 años con socios mayoritarios menores de 40 años. Quiero saber más Somos expertos en gestionar estas líneas.Podemos conseguir la tuya. Quiero saber más   Si lo prefieres puedes llamarnos al 981 90 49 49(de lunes a viernes de 9 a 16 horas) Deseamos que esta comunicación haya resultado de su agrado. No obstante, si prefiere no recibir más comunicaciones de este tipo, siga este enlace. Tenga en cuenta que esta comunicación está dirigida a: freebsd-stable@freebsd.org. De conformidad con lo establecido en la Ley 34/2002 Lssice le comunicamos que este escrito procede de Search Task, s.l.u con cif B70296009 y domicilio en Calle Benito Blanco Rajoy 7-9, 1º, 15006, A Coruña, con finalidad publicitaria. Search Task cumple estrictamente la normativa vigente en el ámbito de protección de sus datos en Internet. Según dispone la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, le recordamos que tiene derecho legal de acceso, rectificación, cancelación u oposición escribiendo a searchtaskmail@gmail.com. De conformidad con lo dispuesto en dicha jurisprudencia, Search Task le comunica que los datos que nos proporcione formarán parte de un fichero automatizado de datos de carácter personal, responsabilidad de dicha entidad, con la finalidad de gestionar las comunicaciones con la misma. El contenido del presente comunicado es confidencial y únicamente está dirigida y autorizada su lectura al consignatario original, quedando prohibidos cualquier comunicación, o difusión, tanto del comunicado como de su contenido.