FreeBSD Quarterly Status Report - Second Quarter 2019

2019-08-25 Thread Edward Tomasz Napierała
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 

Re: ntpd doesn't like ASLR on stable/12 post-r350672

2019-08-25 Thread Konstantin Belousov
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)
> 5265if (-1 == setrlimit(RLIMIT_STACK, )) {
> (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.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"