Talks speakers

Because of so many glaring problems in the existing spell(1) and for the lack
of a reusable library interface for other applications to add spell checking
functionality, I started work on writing a new implementation of spell(1)
with the goal of overcoming these problems and also building a library
to add spell checking feature to apropos(1) in NetBSD.

In this presentation I will talk about:

• current implementation of spell(1) and demonstrate its short comings
• spell correction algorithms – Levenshtein distance, metaphone and n-grams
• work done to implement these techniques resulting in a new spell(1) with a
  library interface
• performance comparison of the new implementation against against one of the
  most popular open source spell checker – GNU Aspell
• Demonstrate integration of the library interface with other applications such
  as apropos(1) and sh(1) to do spell correction and context sensitive text
  auto-completion

Unfortunately traditional BSD syslog protocol is based on datagram
sockets and UDP messages. Both may fail unnoticed. The new system
call sendmessage(2) makes local logging work in harsh conditions
and also provides a single point from where errors can be reported.
Overflow of dmesg(8) buffer is detected and reported. For remote
logging TCP and TLS transport have been implemented together with
counters of lost messages due to buffer exhaustion.

The talk will explain these mechanisms together with more new
features in OpenBSD syslogd(8).

• developer bluhm@openbsd.org since 2007
• working for genua GmbH, a company which builds OpenBSD based firewalls

We shall try and hit where it hurts when that makes sense. Obviously, both
speakers have their own personal and subjective preferences and will explain
why. Showing some of the weaknesses may encourage people to contribute in some
areas.

This is the Act I of a totally biased talk from two different perspectives.

We shall try and hit where it hurts when that makes sense. Obviously, both
speakers have their own personal and subjective preferences and will explain
why. Showing some of the weaknesses may encourage people to contribute in some
areas.

This is the Act II of a totally biased talk from two different perspectives.

The current implementation of uvm(9) uses a static array to “manage”
memory segments. The uvm hotplug(9) API enables dynamically “managed”
memory segments allowing for the possibility of hot plugging and unplugging of
memory. During the process of implementing uvm hotplug(9) we used a Test
Driven Development methodology and Pair Programming to achieve our goal.

This talk focuses on how to re-organize the code for testing, test design
strategy for correctness and performance evaluation and the possibilities of
testing kernel code in userspace, specifically code pertaining to uvm(9). The
talk will also cover the methodology we used to achieve TDD on an existing
code base which lacked any prior formal written tests. In addition to the
above there will also be a small section on how tests(7) was used as a tool
to measure performance by load testing.

Later he turned his attention to minor OF tweaks to the ibook G3 he
owned.

His serious contributions to NetBSD came after an internship with what
was then Xensource in the U.Cambridge startup scene. He committed SMP
support for NetBSD/Xen in 2011, the Xen memory ballooning driver for
NetBSD and the uvm hotplug interface.

Cherry also got FreeBSD to boot single user to Xen in its
Paravirtualised avatar – however this project was made redundant by the
excellent PVHVM support by royger@

Cherry likes to play with kernel code, electronics, walk up mountains,
travel footloose and hang out with the locals, pretend to cook, do a
bit of gardening / small scale farming, teach, take things apart, and
generally pretend that he is an intelligent sort.

https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_builds

and it will have more detailed examples of the toolchain, build,
and application changes that every OS needs to make to achieve
reprodicibility.

I will also discuss the meaning of timestamps and other “build-specific”
information that needs to become predictable for fully reproducible
builds, and if it is worth faking in the first place to achieve
identical built artifacts at the media level.

Topic to cover will include:

• overview of Bacula: client, storage, director
• Jobs
• Pools
• FileSets
• running a job
• restoring a job
• copy/migrate jobs from one media to another

• You can safely run programs that you don’t trust at all, as long as
  you don’t provide it access to file descriptors of resources that
  should remain off-limits. This makes it a very useful building block
  for a multi-tenant cloud/cluster computing service.
• By having Capsicum always enabled, we can remove all of the features
  that conflict with Capsicum. This allows you to modify applications to
  work well with sandboxing a lot more easily. It is easy to make an
  inventory of which modification need to be made, simply by looking at
  compiler errors generated by the absence of the incompatible features.
• Software becomes easier to test and manage. This effectively brings
  the principle of Dependency Injection from object oriented programming
  to full-scale programs.

In this talk, I’m going to discuss how I’ve added support for running
CloudABI-based applications directly on top of Kubernetes, an Open
Source cluster management suite. An interesting aspect of this is that
it effectively removes the dependency on Docker and makes Kubernetes
work on FreeBSD. After giving a crash course on Kubernetes, I will
present the software that I have developed to make this work.

About DragonFly

• Unix-like operating system, BSD descendant
• Started from FreeBSD 4.x in 2003
• High-performance, unique approach to MP operation
• Unique features: HAMMER filesystem, swapcache

I have been trying to make DragonFly more useful by benchmarking its
performance, making it able to use some common technologies and porting
various pieces of software.

In particular, I have been working since 2012 on porting drm/kms graphic
drivers to DragonFly. I am also generally involved in various
discussions about graphics in the DragonFly community.

• Independent consultant, sysadmin
• X11 and BSD user since the 1990s
• DragonFly developer since 2011
• Has ported drm/i915 and drm/radeon kernel drivers to DragonFly

For more than a year we have been using DTrace as one of the three core
components of a security research project, CADETS. Unlike earlier users
of DTrace, which were focused on occasional, deep debugging sessions,
the CADETS project uses DTrace to bring total system transparency to
both the operating system and the applications that are running on top
of it. The use of “always-on tracing” pushes the DTrace system up to,
and often, past its limits and shows how some of the original design
tradeoffs need to be revisited to address the needs of our project. Our
talk covers our current efforts to extend and improve the DTrace
framework in FreeBSD, including performance and programming improvements
to address the needs of always-on tracing as well as integration with
FreeBSD’s audit subsystem and the addition of machine-readable output
for use by creators of downstream security-analysis tools.

Started using Linux in 1996.

Started experimenting with BSD and fell in love with OpenBSD in 1999.

Joined the OpenBSD madhouse as a commiter sometime in 2007.

Imported the OpenSMTPD daemon late 2008.

My college and OpenBSD developer bluhm@ has used this infrastructure to
run the OpenBSD regression tests. Results for those tests have been
available at http://bluhm.genua.de/regress/results/regress.html for over
a year now.

The test infrastructure is mostly made of old hardware that had
accumulated in our company for years. So it should be quite easy and
inexpensive to replicate a similar infrastructure for your testing
needs.

The talk will explain the infrastructure in detail, include live-demos
that show how easy it can be used and share some ideas on how the system
could be improved further.

The road towards a fully working DTrace-like implementation is long and a lot
of that depends on having binaries annotated with CTF.

CTF is a converted subset of DWARF that can be embedded in all a wide range of
binaries, including the kernel.

Throughout this presentation I will discuss the dynamic profiling part that has
been developed by Martin Pieuchot and I will go into the work that went into
adding support for inspecting kernel CTF-data with DDB. Lastly the status quo
will be reviewed as well as what pieces are still missing from the puzzle.

Nicolas David. Prior to joining AWS, Nicolas evolved for 15 years
in information technology industry at major French and European
actors of the Software Edition, Bank and Insurance businesses in a
variety of roles. Today, Nicolas uses his experience to support AWS
customers transforming their way to think IT using the cloud
computing. While delivering a broad range of sessions from introductory
level (AWSome Days, AWS Technical Essentials, AWS Business Essentials),
to advanced courses (Architecting/Advanced Architecting Concepts
on AWS, System Operations on AWS, Security Operations on AWS, DevOps
Engineering on AWS, Big Data on AWS); Nicolas contributes to
Presentations, Hands-on Labs and the material used in and around
AWS Training Sessions, like events, meetups and public talks.

And things keep accreting. The only reason such a program may stop
evolving is because it’s dead, drowned in its own misfeatures.

This talk will look at ways we managed complexity in the past, successes and
failures at keeping enough compatibility for migrations to be less painful.

And also, a roadmap to the future, how we set priorities for what we want
while still keeping the pkg tools in working condition, the current challenge
being to get things faster while still keeping them mostly bug-free.

When he’s not coding, he’s also a teacher and researcher at Epita’s
Systems and security Lab, trying to teach young pups how to write code that
isn’t complete crap.

Research

With a growing number of sandboxed applications we also recognized
new kinds of problems. Some of them we’ve already managed to solve. The
FreeBSD community was able to sandbox around 22 new applications re-
cently, but it’s still long way from sandboxing all of them.

One of the thing we noticed during that process is a large chunk of code
which we needed to rewrite multiple times in different programs. To simplify
the use of this framework we introduced Capsicum helpers, a small C header
of few inline functions which allows to reduce repeating parts of codes. One
of very common thing is to limit standard output and input descriptors,
this forces us to copy paste around 15 lines of code. Thanks to simple API
1we are able to limit it to 2 lines of code. The header
provides us also more grainy API for every descriptor:

• caph_limit_stdio
• caph_limit_stdout
• caph_limit_stdin
• caph_limit_stderr

As well as generic function caph_limit_stream which can limit any descriptor
provided. All those function are limiting descriptor to the most common ioctl
and capability rights.

Capsicum helpers also provides a few functions which allows to cache some
common used data. For example localtime need to read once /etc/localtime.
If localtime function is called after entering sandbox then function will get bad
time. The caph_cache_tzdata function was introduced to cache time zones
files. One of the reasons of collecting such functions is also documenting for
developers which things need to be cached before entering Capsicum.
A very common problem of Capsicum is silent failures. When sandbox
is added to an application, a developer cannot notice some conditions of
program. For example if an application is using a library and this library
is using random number generator by opening /dev/random if possible and
otherwise use some insecure random generator. If a developer will not no-
tice this behavior by analyzing the code this can lead to introducing new
bugs while snadboxing application. One way is to use ktrace infrastructure
but this also can be unnoticed by developer. Due to the new debugging
feature for Capsicum which was implemented by Konstantin Belousov un-
der FreeBSD foundation sponsorship. Enabling procctl(PROC_TRAPCAP)
(per-process) or sysctl kern.trap_enocap (globally in the system) kernel will
issue SIGTRAP to generate a core dump or enter the debugger incited of
returning ENOTCAPABLE or ECAPMODE.

Some sandboxed applications had very interesting stories, like dd. One
of the problem we encountered was that dd is a build tool. Another one was
the problem which overrating stderr descriptor. Case studies of sandboxing
applications like that can be very educational for future developers.

Summary

Last year was crucial for the Capsicum community. My presentation
will focus on the past year of development of Capsicum framework. We
introduced a few interesting features (like Capsicum helper or new debugging
infrastructure). FreeBSD got a few new sandboxed applications, some of
them, like dd, has a very interesting history that are worth presenting.

Mariusz’s main ares of interest are OS security and low-level
programming. At Wheel Systems, Mariusz is developing a solution to
monitor, record and control traffic in an IT infrastructure.

He has been involved in the development of Capsicum and Casper since
Google Summer of Code 2013, which he successfully passed under
the mentorship of Paweł Jakub Dawidek.

Mariusz has been a FreeBSD project commiter since 2015.

This talk presents the analysis and fixes for a performance regression
introduced in Firefox 40.0 on OpenBSD. A debug story from X to libpthread
with a detour in the scheduler all of that without DTrace.

This talk will cover:

• setting up web sites
• administering chroots for web apps
• Lua patterns
• OpenBSD’s ACME client
• OCSP stapling
• multi-server clusters
• load balancer clusters

Seven years later not only has hardware become incredibly more powerful. Customers
and software developing colleagues alike expect more agile management, provisioning
and deployment of resources to meet their applications’ demands.

I’d like to present how we employ jails and ZFS to manage a large number of “virtual”
environments while we kept some of the concepts learned from successful use of NanoBSD
as far as software provisioning, updates and general management of production environments
are concerned.

This talk will illustrate how pkgsrc can be used to attempt to enforce
hardening features on every package at once, and whenever possible also
to detect when these features are effectively enabled or failed to
function. The methodology, current status, and ideas for future work in
this direction will be gathered in the talk.

• ASUS KGPE-D16,
• ASUS F2A85-M,
• ASRock E350M1,
• Lenovo ThinkPad X200,
• Lenovo ThinkPad X230,
• PC-Engines APU2.

We did tests on FreeBSD, OpenBSD and NetBSD and it turns out that some have
great compatibility, while others not so much.

Katarzyna Kubaj is a web developer, graphic designer, SEO specialist and
occassionally a book translator from Gdańsk, Poland. After hours spent with
websites, she turns into electronics enthusiast. She likes to open some hardware
and reassemble it completely. She made the Core/Libreboot flashing experiments
possible, soldering and pinning what’s neccessary, and keeping Piotr away from
mobos.

The new solution is based on OpenBSD, IPSEC, OSPF, RDomains and Ansible.
Our main focus was to reduce maintenance burden with automation.

In the presentation I would discuss the following topics:
• Choice of a routing protocol: we did PoCs with OSPF and BGP
• Integration into the existing Network
• Redundancy: connect each branch router to a VPN gateway cluster and
  possibly to a 2nd cluster in another data center.
• Why we need routing domains for the branch router configuration.
• Automated setup of vpn gateways with OpenBSD autoinstall and Ansible.

Since 2009 I work for Netcetera as a System and Network Engineer. I
introduced
various things from Puppet for Linux servers to OpenBSD clusters for
firewalls. Currently I mostly work on networking topics.