One of my popular articles shortly after I joined OSNews in 2001 proved to be "the big *BSD interview" and so it is only appropriate to end my serving at OSNews with a similar theme. Today we are very happy to host a Q&A with well-known FreeBSD developers John Baldwin, Robert Watson and Scott Long. We discuss about FreeBSD 6 and its new features, the competition, TrustedBSD, Darwin etc.

1. Tell us more about SMPVFS and its significance.

John Baldwin: The SMPVFS work is a task to add fine-grained locking to the VFS layer of the
kernel as well as the UFS and nullfs filesystems. The VFS layer provides the
abstractions in the kernel that describe file objects. Each filesystem
provides a VFS "driver" to manage the files on a disk device according to the
design of that filesystem. Adding fine-grained locking to VFS and the UFS
filesystem allows more concurrency in the kernel, especially with workloads
that include disk I/O.

Robert N M Watson: One of the other nice benefits to the SMPVFS work is that with our fully
preemptive 6.x kernel, not holding the Giant lock over the file system
code lets the file system code not only preempt lower precedence kernel
threads, such as background crypto operations or file system operations,
but be preempted by more timing critical code, such as sound card
interrupts, network I/O, and so on. So this isn't just a win for SMP, but
a win for UP also. The SMP wins are impressive though -- Kris Kennaway
has recently been benchmarking package builds, a very VFS-intensive
workload, on 12-CPU sparc systems, and all the scalability we'd hoped for
is there.

Scott Long: SMPVFS also reduces contention for storage drivers that are still under the Giant lock and increases the possible parallelism between these drivers and the filesystems above them. Kris' tests are a very good example of this; even though the SCSI subsystem and most of the ESP driver are still under the Giant lock, performance still scaled well.

2. We recently read that the fix for the Hyper-Threading vulnerability is considered non-trivial. Why is that?

John Baldwin: The issue found with HT is that the two logical CPUs on a single core share
the same caches and as a result there are ways for one logical CPU to spy on
the activities of the other CPU in the same core. The proposed fixes involve
ways of guaranteeing that all of threads on a single core are all allowed to
spy on each other. For example, one policy is that only threads with the
same user ID should be allowed to run together no the same core. The problem
is that right now FreeBSD treats logical CPUs as separate CPUs and schedules
available threads on the first CPU that becomes available. It would be a bit
of work to make the scheduler more aware of logical CPUs and to schedule
threads with respect to UIDs, etc.

Robert N M Watson: It's worth observing that this is a serious vulnerability across a range
of operating systems, not just FreeBSD. If you allow untrusted users on
the same system as an SSH daemon, you're at risk, which affects everyone
from desktop users, to ISPs, to military end-users. It's also a very hard
problem to solve -- we're looking at it from the perspective of improving
the scheduler, bringing in OpenSSL updates to limit timing attacks, and
obviously we're hoping that CPU vendors take this opportunity to explore
how to harden CPU architectures against this sort of attack. Because this
vulnerability isn't just about scheduling, crypto, or hyper-threading, a
lot of hard work will have to into a long term solutions.

3. Why is TrustedBSD an important piece of the upcoming FreeBSD 6? How does it compare to SE-Linux or OpenBSD?

John Baldwin: Robert is probably the best to answer this. From my understanding, TrustedBSD
is a superset of SE-Linux as it includes things like ACLs for files as well
as the MAC framework that allows for arbitrary MAC policies to be hooked into
the kernel. One such policy being developed is a port of SE-Linux called
SE-BSD. There are also other policies available for the MAC framework
besides SE-BSD.

Robert N M Watson: TrustedBSD elements have now appeared in 4.x, 5.x, and 6.x. 5.x brought
in many of our most significant features -- some were infrastructure to
support our goals, and others were security features we've been targetting
as primary goals. Supporting TrustedBSD features included OpenPAM, GEOM,
UFS2 with extended attributes, and a lot of kernel and user space cleanup
for access control. It turns out that our extensive SMP work in 5.x was
also very important, as the mature kernel synchronization architecture of
5.x allows us to generate access control decisions in many code paths that
would not easily have supported it in 4.x, such as in software interrupt
paths in the network stack.

The direct feature set in 5.x included the TrustedBSD MAC Framework, which
allows compile-time and run-time extension of the FreeBSD security model,
a set of sample system policy modules, such as Multi-Level Security, Biba
Integrity, and a variey of hardening policies, and also support for Access
Control Lists (ACLs). So the TrustedBSD work was really key to the 5.x
release line, especially if you include the supporting features I listed
above.

In 6.x, many of the experimental features from 5.x are considered
production quality, and extended in a variety of ways. Two of the biggest
"new" projects are SEBSD, a port of NSA's FLASK/TE implementation from
SELinux and its predecessors (DTOS, FLUX), and support for CAPP security
event audit, which is derived from OpenBSM, which is in turn derived from
Apple's CAPP Audit implementation. SEBSD will be an add-on distribution
on top of FreeBSD 6.x, and allow the authoring of fine-grained Type
Enforcement (TE) policies similar to those in SELinux. OpenBSM provides
us with a implementation of both kernel event auditing, as well as a
BSD-licensed user space audit library implementing Sun's BSM audit file
format and service API. Adding support for Audit really fleshes out our
trusted operating system feature set, and NSA's FLASK/TE provides a
powerful policy language to for tuning system security for specific
applications and configurations.

These are security features that our network appliance, security,
financial, and military consumers will appreciate greatly. They're also
features that end users will be able to use to customize and monitor
security operation of their systems in a manner currently unsupported by
any other open or closed source operating system.