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.