Virtualized COW / PI?

This week on the show, we’ve got all sorts of goodies to discuss. Starting with, vmm, vkernels, raspberry pi and much more! Some iX folks are visiting from out of

This episode was brought to you by

href="http://www.digitalocean.com/" title="DigitalOcean"> href="http://www.tarsnap.com/bsdnow" title="Tarsnap">

Headlines

vmm enabled

• VMM, the OpenBSD hypervisor, has been imported into current
• It has similar hardware requirements to bhyve, a Intel Nehalem or newer CPU with the hardware virtualization features enabled in the BIOS
• AMD support has not been started yet
• OpenBSD is the only supported guest
• It would be interesting to hear from viewers that have tried it, and hear how it does, and what still needs more work ***

vkernels go COW

• The DragonflyBSD feature, vkernels, has gained a new Copy-On-Write functionality
• Disk images can now be mounted RO or RW, but changes will not be written back to the image file
• This allows multiple vkernels to share the same disk image
• “Note that when the vkernel operates on an image in this mode, modifications will eat up system memory and swap, so the user should be cognizant of the use-case. Still, the flexibility of being able to mount the image R+W should not be underestimated.”
• This is another feature we’d love to hear from viewers that have tried it out. ***

Basic support for the RPI3 has landed in FreeBSD-CURRENT

• The long awaited bits to allow FreeBSD to boot on the Raspberry Pi 3 have landed
• There is still a bit of work to be done, some of the as mentioned in Oleksandr’s blog post:
• Raspberry Pi support in HEAD

“Raspberry Pi 3 limited support was committed to HEAD. Most of drivers should work with upstream dtb, RNG requires attention because callout mode seems to be broken and there is no IRQ in upstream device tree file. SMP is work in progress. There are some compatibility issue with VCHIQ driver due to some assumptions that are true only for ARM platform. “

• This is exciting work. No HDMI support (yet), so if you plan on trying this out make sure you have your USB->Serial adapter cables ready to go.
• Full Instructions to get started with your RPI 3 can be found on the FreeBSD Wiki
• Relatively soon, I imagine there will be a RaspBSD build for the RPI3 to make it easier to get started
• Eventually there will be official FreeBSD images as well ***

OpenBSD switches softraid crypto from PKCS5 PBKDF2 to bcrypt PBKDF.

• After the discussion a few weeks ago when a user wrote a tool to brute force their forgotten OpenBSD Full Disk Encryption password (from a password list of possible variations of their password), it was discovered that OpenBSD defaulted to using just 8192 iterations of PKCSv5 for the key derivation function with a SHA1-HMAC
• The number of iterations can be manually controlled by the user when creating the softraid volume
• By comparison, FreeBSDs GELI full disk encryption used a benchmark to pick a number of iterations that would take more than 2 seconds to complete, generally resulting in a number of iterations over 1 million on most modern hardware. The algorithm is based on a SHA512-HMAC
• However, inefficiency in the implementation of PKCSv5 in GELI resulted in the implementation being 50% slower than some other implementations, meaning the effective security was only about 1 second per attempt, rather than the intended 2 seconds. The improved PKCSv5 implementation is out for review currently.
• This commit to OpenBSD changes the default key derivation function to be based on bcrypt and a SHA512-HMAC instead.
• OpenBSD also now uses a benchmark to pick a number of of iterations that will take approximately 1 second per attempt
• “One weakness of PBKDF2 is that while its number of iterations can be adjusted to make it take an arbitrarily large amount of computing time, it can be implemented with a small circuit and very little RAM, which makes brute-force attacks using application-specific integrated circuits or graphics processing units relatively cheap. The bcrypt key derivation function requires a larger amount of RAM (but still not tunable separately, i. e. fixed for a given amount of CPU time) and is slightly stronger against such attacks, while the more modern scrypt key derivation function can use arbitrarily large amounts of memory and is therefore more resistant to ASIC and GPU attacks.”
• The upgrade to the bcrypt, which has proven to be quite resistant to cracking by GPUs is a significant enhancement to OpenBSDs encrypted softraid feature ***

Interview - Josh Paetzel - email@email / @bsdunix4ever

• MeetBSD
• ZFS Panel
• FreeNAS - graceful network reload
• Pxeboot ***

News Roundup

EC2's most dangerous feature

• Colin Percival, FreeBSD’s unofficial EC2 maintainer, has published a blog post about “EC2's most dangerous feature”
• “As a FreeBSD developer — and someone who writes in C — I believe strongly in the idea of "tools, not policy". If you want to shoot yourself in the foot, I'll help you deliver the bullet to your foot as efficiently and reliably as possible. UNIX has always been built around the idea that systems administrators are better equipped to figure out what they want than the developers of the OS, and it's almost impossible to prevent foot-shooting without also limiting useful functionality. The most powerful tools are inevitably dangerous, and often the best solution is to simply ensure that they come with sufficient warning labels attached; but occasionally I see tools which not only lack important warning labels, but are also designed in a way which makes them far more dangerous than necessary. Such a case is IAM Roles for Amazon EC2.”
• “A review for readers unfamiliar with this feature: Amazon IAM (Identity and Access Management) is a service which allows for the creation of access credentials which are limited in scope; for example, you can have keys which can read objects from Amazon S3 but cannot write any objects. IAM Roles for EC2 are a mechanism for automatically creating such credentials and distributing them to EC2 instances; you specify a policy and launch an EC2 instance with that Role attached, and magic happens making time-limited credentials available via the EC2 instance metadata. This simplifies the task of creating and distributing credentials and is very convenient; I use it in my FreeBSD AMI Builder AMI, for example. Despite being convenient, there are two rather scary problems with this feature which severely limit the situations where I'd recommend using it.”
• “The first problem is one of configuration: The language used to specify IAM Policies is not sufficient to allow for EC2 instances to be properly limited in their powers. For example, suppose you want to allow EC2 instances to create, attach, detach, and delete Elastic Block Store volumes automatically — useful if you want to have filesystems automatically scaling up and down depending on the amount of data which they contain. The obvious way to do this is would be to "tag" the volumes belonging to an EC2 instance and provide a Role which can only act on volumes tagged to the instance where the Role was provided; while the second part of this (limiting actions to tagged volumes) seems to be possible, there is no way to require specific API call parameters on all permitted CreateVolume calls, as would be necessary to require that a tag is applied to any new volumes being created by the instance.”
• “As problematic as the configuration is, a far larger problem with IAM Roles for Amazon EC2 is access control — or, to be more precise, the lack thereof. As I mentioned earlier, IAM Role credentials are exposed to EC2 instances via the EC2 instance metadata system: In other words, they're available from http://169.254.169.254/. (I presume that the "EC2ws" HTTP server which responds is running in another Xen domain on the same physical hardware, but that implementation detail is unimportant.) This makes the credentials easy for programs to obtain... unfortunately, too easy for programs to obtain. UNIX is designed as a multi-user operating system, with multiple users and groups and permission flags and often even more sophisticated ACLs — but there are very few systems which control the ability to make outgoing HTTP requests. We write software which relies on privilege separation to reduce the likelihood that a bug will result in a full system compromise; but if a process which is running as user nobody and chrooted into /var/empty is still able to fetch AWS keys which can read every one of the objects you have stored in S3, do you really have any meaningful privilege separation? To borrow a phrase from Ted Unangst, the way that IAM Roles expose credentials to EC2 instances makes them a very effective exploit mitigation mitigation technique.”
• “To make it worse, exposing credentials — and other metadata, for that matter — via HTTP is completely unnecessary. EC2 runs on Xen, which already has a perfectly good key-value data store for conveying metadata between the host and guest instances. It would be absolutely trivial for Amazon to place EC2 metadata, including IAM credentials, into XenStore; and almost as trivial for EC2 instances to expose XenStore as a filesystem to which standard UNIX permissions could be applied, providing IAM Role credentials with the full range of access control functionality which UNIX affords to files stored on disk. Of course, there is a lot of code out there which relies on fetching EC2 instance metadata over HTTP, and trivial or not it would still take time to write code for pushing EC2 metadata into XenStore and exposing it via a filesystem inside instances; so even if someone at AWS reads this blog post and immediately says "hey, we should fix this", I'm sure we'll be stuck with the problems in IAM Roles for years to come.”
• “So consider this a warning label: IAM Roles for EC2 may seem like a gun which you can use to efficiently and reliably shoot yourself in the foot; but in fact it's more like a gun which is difficult to aim and might be fired by someone on the other side of the room snapping his fingers. Handle with care!” ***

Open-source storage that doesn't suck? Our man tries to break TrueNAS

• The storage reviewer over at TheRegister got their hands on a TrueNAS and gave it a try
• “Data storage is difficult, and ZFS-based storage doubly so. There's a lot of money to be made if you can do storage right, so it's uncommon to see a storage company with an open-source model deliver storage that doesn't suck.”
• “To become TrueNAS, FreeNAS's code is feature-frozen and tested rigorously. Bleeding-edge development continues with FreeNAS, and FreeNAS comes with far fewer guarantees than does TrueNAS.”
• “iXsystems provided a Z20 hybrid storage array. The Z20 is a dual-controller, SAS-based, high-availability, hybrid storage array. The testing unit came with a 2x 10GbE NIC per controller and retails around US$24k. The unit shipped with 10x 300GB 10k RPM magnetic hard drives, an 8GB ZIL SSD and a 200GB L2ARC SSD. 50GiB of RAM was dedicated to the ARC by the system's autotune feature.”
• The review tests the performance of the TrueNAS, which they found acceptable for spinning rust, but they also tested the HA features
• While the look of the UI didn’t impress them, the functionality and built in help did
• “The UI contains truly excellent mouseover tooltips that provide detailed information and rationale for almost every setting. An experienced sysadmin will be able to navigate the TrueNAS UI with ease. An experienced storage admin who knows what all the terms mean won't have to refer to a wiki or the more traditional help manual, but the same can't be said for the uninitiated.”
• “After a lot of testing, I'd trust my data to the TrueNAS. I am convinced that it will ensure the availability of my data to within any reasonable test, and do so as a high availability solution. That's more than I can say for a lot of storage out there.”
• “iXsystems produce a storage array that is decent enough to entice away some existing users of the likes of EMC, NetApp, Dell or HP. Honestly, that's not something I thought possible going into this review. It's a nice surprise.” ***

OpenBSD now officially on GitHub

• Got a couple of new OpenBSD items to bring to your attention today.
• First up, for those who didn’t know, OpenBSD development has (always?) taken place in CVS, similar to NetBSD and previously FreeBSD.
• However today, Git fans can rejoice, since there is now an “official” read-only github mirror of their sources for public consumption.
• Since this is read-only, I will assume (unless told otherwise) that pull-requests and whatnot aren’t taken. But this will come in handy for the “git-enabled” among us who need an easier way to checkout OpenBSD sources.
• There is also not yet a guarantee about the stability of the exporter. If you base a fork on the github branch, and something goes wrong with the exporter, the data may be reexported with different hashes, making it difficult to rebase your fork.

How to install LibertyBSD or OpenBSD on a libreboot system

• For the second part of our OpenBSD stories, we have a pretty detailed document posted over at LibreBoot.org with details on how to boot-strap OpenBSD (Or LibertyBSD) using their open-source bios replacement.
• We’ve covered blog posts and other tidbits about this process in the past, but this seems to be the definitive version (so far) to reference.
• Some of the niceties include instructions on getting the USB image formatted not just on OpenBSD, but also FreeBSD, Linux and NetBSD.
• Instructions on how to boot without full-disk-encryption are provided, with a mention that so far Libreboot + Grub does not support FDE (yet). I would imagine somebody will need to port over the openBSD FDE crypto support to GRUB, as was done with GELI at some point.
• Lastly some instructions on how to configure grub, and troubleshoot if something goes wrong will help round-out this story. Give it a whirl, let us know if you run into issues.
• Editorial Aside - Personally I find the libreboot stuff fascinating. It really is one of the last areas that we don’t have full control of our systems with open-source. With the growth of EFI, it seems we rely on a closed-source binary / mini-OS of sorts just to boot our Open Source solutions, which needs to be addressed. Hats off to the LibreBoot folks for taking on this important challenge. ***

FreeNAS 9.10 – LAGG & VLAN Overview

• A video tutorial on FreeNAS’s official YouTube Channel
• Covers the advanced networking features, Link Aggregation and VLANs
• Covers what the features do, and in the case of LAGG, how each of the modes work and when you might want to use it ***

Beastie Bits

• Remote BSD Developer Position is up for grabs

• Isilon is hiring for a FreeBSD Security position

• Google has ported the Networked real-time multi-player BSD game

• A bunch of OpenBSD Tips

• The last OpenBSD 6.0 Limited Edition CD has sold

• Dan spots George Neville-Neil on TV at the Airport

• gnn on CNN

• SoloBSD releases v 6.0 built upon OpenBSD

• Upcoming KnoxBug looks at PacBSD - Oct 25th

Feedback/Questions

• Morgan - Ports and Packages
• Mat - ZFS Memory
• Thomas - FreeBSD Path Length
• Cy - OpenBSD and NetHogs
• Lars - Editors ***